Jump to content

    

Kabdim

Свой
  • Content Count

    710
  • Joined

Community Reputation

0 Обычный

1 Follower

About Kabdim

  • Rank
    Знающий

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

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