Jump to content

    

Kabdim

Свой
  • Content Count

    703
  • Joined

  • Last visited

Community Reputation

0 Обычный

1 Follower

About Kabdim

  • Rank
    Знающий

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Зеленоград

Recent Profile Visitors

4837 profile views
  1. анализатор проекта С++

    Взлом != анализ программы. Взлом == анализ системы защиты от копирования. Понятное дело что greep может хватить на всё, но интеллектуальный анализ AST всё же дает больше и быстрее.
  2. анализатор проекта С++

    Взлом не разработка. К чему это?
  3. анализатор проекта С++

    Ни один редактор не освободит от необходимости знания матчасти, хотя бы в общих чертах. r/SlickEdit/vim/ :D
  4. анализатор проекта С++

    call stack это функция в clion. Она много где есть, в студии, в эклипсе и т.д. В эклипсе есть её удобная сестра которая показывает всё что вызывает эта фунция кстати. Нужно лишь импортировать исходники в удобную IDE.
  5. анализатор проекта С++

    call stack - проще того что предлагает UnderStand C++ - показывает кто вызывает данную функцию. Но для меня это оказывается удобней развернутой портянки андерстенда.
  6. анализатор проекта С++

    Тыкал палачкой в UnderStand C++ . Во-первых падает регулярно. Во-вторых при всей крутости этих диаграмм, понимания на более менее крупном проекте с легаси кодом и тех долгом оно лично мне не прибавляет т.к. показывает свзязь всего со всем. Возможно оно было бы лучше на хорошо структурированом коде, но зачем такой агрегат на хорошем проекте - неясно. Как по мне он не отделяет важных связей от второстепенных, что приводит к мельтешению этих блоков и стрелочек. В итоге самым оптимальным для меня остается clion с call stack и интеллектуальным поиском. По частоте сталкивания мозг постепенно вычленяет для себя ключевые точки проекта, потом уже более целенаправлено произвожу исследование во все стороны от этих ключевых точек до мест которые собственно являются целью.
  7. Тем что его нельзя сломать, даже если захочется. Есть такое. Если бы load/store гарантировали что их нельзя сломать...
  8. Нет, там физически нельзя всунуть в середине обработки обращение к тем данным к которым происходит атомарный доступ.
  9. Жесть, насколько же x86 в этом аспекте прямолинейно правильней.
  10. Не совсем, компилятор может выбрать какой-то способ, по своей логике. В этом огромная разница между стандартом и практикой. На практике много чего работатет из того что не обязано работать. Проблема в том что оно работает здесь и сейчас, но может перестать работать потом, при изменении версии компилятора, портировании куда-то, просто потому что оптимизатору что-то показалось. И любой такой случай приводит к затратам времени на поиск проблемы. Постепенно убираю их из своих исходников в пользу дедовских сдвигов и битовых операций. Естетсвенно стараюсь обернуть это в разумные сервисные функции с логическим смыслом, без портянок в более высокоуровневом коде. Думал над темплейт-класс магией, но морально пока не созрел. Эээ т.е. если просто записать в тот же адрес STR'ом вся схема сломается?
  11. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf Отсюда Собственно вот из-за этого битовые поля c volatile - шляпа, которая не обязана работать так как ожидается. Т.е. никаких гарантий ни с тем как они выравнены, ни с тем что правильно будет работать атомарный доступ.
  12. Напомню что форум это просто место для обмена мнениями, ни у кого нет обязанностей по переубеждению конкретного человека. Да мне сложно представить вам доказательства конкретно моего случая, настолько сложно что я не хочу на это тратить свои ограниченные ресурсы. По-моему это нормально услышав чье-то мнение взять и проверить по томуже тексту стандарта и сделать выводы самому. Ссылки на что? На стандарт и на раздел в нем что ли? А если желание и правда есть, неужто в гугле найти черновик стандарта и по оглавлению нужный разде так сложо?
  13. Почему, если в соотвествующем разделе стандарта, всё отдано на откуп того как придумают авторы компилятора? Там не совсем прямолинейно с volatile было, когда сел разбираться всё становилось вполне логичным, а битовые поля всё меньше нравились. Это довольно сложно, мало того что нужно найти конкретный комит, найти соотсвующее железо - проверить, суметь его как-то миниммизировать причем это все равно оставит вопросы по раскрытию корптайны, так еще как-то понять точную версию gcc с которой это произошло (у нас их много, прошу не спрашивать зачем). Прошу прощения, понимаю ваше желание разобраться и с удовольствием бы поучаствовал бы в этом если бы эта ошибка была у меня здесь и сейчас. Тем не менее тратить время на настолько "остывшую" проблему смысла не вижу. И заметьте, я не говорю что все кто использует битовые поля делают что-то что обязательно приведет к проблемам, а лишь то что по стандарту никто ничего не должен гарантировать по реализции битовых полей. Тут вы конечно можете сказать что бремя доказательства лежит на утверждающем, а я в свою очередь кивну на куций раздел в стандарте. Который буквально говорит что каждый компилятор может делать что бог на душу положит. И мы конечно же будем правы, каждый на свой манер. :) Эти ребята наверное могут практически гарантировать что код будет компилироваться конкретным компилятором и начиня от какой-то конкретной версии. Так что владея такой убежденностью возможно они и правы. Конкретно у них с битовыми полями может и не быть проблем.
  14. Ну например если их использовать для регистров, то при некоторых условиях, gcc к примеру может использовать байтовые операции вместо 32битных или игнорировать volatile, что для регистров порой приводит к ошибкам шины. Это то как мне в ногу стреляло. Но вообще там все детали реализации - имплементейшн дефайнд. Что при необходимости писать предсказуемый по результату код является миной замедленного действия.
  15. Видимо вас еще не тролили битовые поля. :)