ну и чудо макросы :)

Лакос приводит пример, когда код #include <iostream.h> #include "wildthing.h" компилится в то время как #include "wildthing.h" #include <iostream.h> нет

Тут как не крути, будет плохо. Во втором случае, ты сможешь потерять #include <iostream>, но продолжить пользоваться его содержимым занесенным через "wildthing" в данную единицу трансляции.

А как можно на примере хорошего кода показать, как делать НЕ надо и как работать НЕ будет?

не совсем понял, чего ты хочешь :)

Третий день идет дискуссия, что порядок - это вопрос стиля

четвертые сутки пылают станицы )

Что порядок может либо ускорить момент обнаружения пропущенного заголовка, либо замедлить. Но в любом случае полагаться на порядок - ошибка.

@narical вчера же об уже поговорили.

Читаю Лакоса. Цитирую: Major design rule: The . c file of every component should include its own . h file as the first substantive line of code. "Говностатья из интернета" тоже называет это "правилом №1". Может, не такая уж она и говностатья?

Ээээ... Видишь ли, не все так однозначно, правил нет. Статью я глянул по диагонали, явно не нашел там ничего стоящего, ты же процитировал не самое важное правило, уцепился в него, и пытаешься на этом основании меня в чем-то обвинят ь. Ещё раз, правил нет. Ты можешь конечно читать книги и статьи и изобретать свои правила, которые может даже и будут "правельными" и будут помогать тебе. Но ещё раз, правил нет.

Я вас услышал

По сути есть только два принципа, это не нарушение ODR и своевременное объявление и определение используемых сущностей

Даже пресловутое разделение компоненты на заголовок и исходник не обязательно

Привет всем. Нужна подсказка. В проекте используется сторонняя dll собранная в конфигурации release(с crt линкуется динамиччески). Если я эту release использую в своём проекте с конфигурацией debug, это же не должно привести к каким то проблемам?

Привет всем. Нужна подсказка. В проекте используется сторонняя dll собранная в конфигурации release(с crt линкуется динамиччески). Если я эту release использую в своём проекте с конфигурацией debug, это же не должно привести к каким то проблемам?

Должно. Не 100% но, но должно

Должно. Не 100% но, но должно

а почему? можно в 2х словах. То что так со статическими делать нельзя, я знаю, а почему динамические нельзя?

а почему? можно в 2х словах. То что так со статическими делать нельзя, я знаю, а почему динамические нельзя?

В 2 х не получится.

будут две разные кучи, если в либе нет своих аллок/фри то будут краши

буду благодарен за какую то ссылку

google.com

а почему? можно в 2х словах. То что так со статическими делать нельзя, я знаю, а почему динамические нельзя?

С динамическими нельзя по ровно той же причине

Окей, пошел гуглить, спасибо

а почему? можно в 2х словах. То что так со статическими делать нельзя, я знаю, а почему динамические нельзя?

Расскажи, почему нельзя со статическими.

а вот автор книги Large-scale C++ software design считает иначе и показывает это на примере

он описывает один совершенно конкретный кейс проектирование LARGE SCALE SOFTWARE SYSTEMS

а почему? можно в 2х словах. То что так со статическими делать нельзя, я знаю, а почему динамические нельзя?

И ещё раз, правило не жесткое, иногда такое может работать

понятно что в проекте до 10,000 файлов можно делать как угодно

И ещё раз, правило не жесткое, иногда такое может работать

ну если каждый модуль выделяет и освобождает память только в своей куче то и ладно

а вот передать пойнтер из одного в другое и там освободить - будет красивый фейрверк

Сделать на сфинае, принимая любой контейнер с фиксированным value_type

спасибо, остановился именно на этом решении

Расскажи, почему нельзя со статическими.

If you have more than one DLL or EXE, then you may have more than one CRT, whether or not you are using different versions of Visual C++. For example, statically linking the CRT into multiple DLLs can present the same problem. Developers encountering this problem with static CRTs have been instructed to compile with /MD to use the CRT DLL. If your DLLs pass CRT resources across the DLL boundary, you may encounter issues with mismatched CRTs and need to recompile your project with Visual C++. это из msdn, если я правильно понял, то если с crt линкуемся как MD то проблем не должно быть, или я все понял не так?

И ещё раз, правило не жесткое, иногда такое может работать

Че-т звучит как фигня. Собираю проект RelWithDebInfo, лмнкуюсь с релизными либами из дерева. Проблем нет.

ну если каждый модуль выделяет и освобождает память только в своей куче то и ладно

и часто так делают?

Хм, а на линухе эта пробоема есть?

If you have more than one DLL or EXE, then you may have more than one CRT, whether or not you are using different versions of Visual C++. For example, statically linking the CRT into multiple DLLs can present the same problem. Developers encountering this problem with static CRTs have been instructed to compile with /MD to use the CRT DLL. If your DLLs pass CRT resources across the DLL boundary, you may encounter issues with mismatched CRTs and need to recompile your project with Visual C++. это из msdn, если я правильно понял, то если с crt линкуемся как MD то проблем не должно быть, или я все понял не так?

Вот всё то же самое верно и для случая использования библиотек в виде .dll

Че-т звучит как фигня. Собираю проект RelWithDebInfo, лмнкуюсь с релизными либами из дерева. Проблем нет.

Ты в курсе, что в средние века запор лечили питьём пациентом литра-другого жидкой ртути ? Тоже ИНОГДА проблем не было...

Хм, а на линухе эта пробоема есть?

Да

Хм, а на линухе эта пробоема есть?

везде есть, куча - это просто код, если два разных кода используются в двух разных частях программы то это тот самый сценарий

Ты в курсе, что в средние века запор лечили питьём пациентом литра-другого жидкой ртути ? Тоже ИНОГДА проблем не было...

ртуть в принципе проходит через организм если не застрянет )

Че-т звучит как фигня. Собираю проект RelWithDebInfo, лмнкуюсь с релизными либами из дерева. Проблем нет.

эээ а причем тут как ты собираешь? релиз + релиз, главное чтобы CRT был один и указатели не кросс-аллоцировались

ртуть в принципе проходит через организм если не застрянет )

Человек в принципе выжевет если не умрет

Человек в принципе выжевет если не умрет

неверно, человек всё равно умрёт

даже если выживет

Хм, а на линухе эта пробоема есть?

В линуксе чаще всего версия CRT зафиксирована глубоко в системе в одном экземпляре и не меняется. А когда что-то собирают, не собирают на одном линуксе под все остальные, хотя это возможно, а обычно под каждую систему делают отдельный пакет под конкретную CRT. В мире Win всё немного не так.

Я никогда проблем с длл/либ не ловил, но хотелось бы узнать о проблеме подробнее. Подскажите какую-то статью или книгу по выше оговоренному вопросу

Зачем тебе это? Простое правило запомни и соблюдай: Все библиотеки должны быть собраны в одной конфигурации.

Читаю и вообще не понимаю ничего

Зачем тебе это? Простое правило запомни и соблюдай: Все библиотеки должны быть собраны в одной конфигурации.

Я всё время так и делаю, но делать ссылаясь на то, что "так нужно" не очень круто

Прочитай про ODR.

Читаю и вообще не понимаю ничего

не переживай :)

Я всё время так и делаю, но делать ссылаясь на то, что "так нужно" не очень круто

Я хороших статей не знаю, а плохие искать не хочу.

Сложный язык у вас?

Сложный язык у вас?

Русский ?

Я никогда проблем с длл/либ не ловил, но хотелось бы узнать о проблеме подробнее. Подскажите какую-то статью или книгу по выше оговоренному вопросу

http://siomsystems.com/mixing-visual-studio-versions/ Вот вроде вполне вменяемая статья на эту тему. Но вполне может быть что не самая лучшая.

http://siomsystems.com/mixing-visual-studio-versions/ Вот вроде вполне вменяемая статья на эту тему. Но вполне может быть что не самая лучшая.

О, спасибо

http://siomsystems.com/mixing-visual-studio-versions/ Вот вроде вполне вменяемая статья на эту тему. Но вполне может быть что не самая лучшая.

спасибо

Ну таких статей много, я уверен, могут быть и лучше.

Эта статья крутится в основном вокруг использования разных CRT в одном приложении. От Debug и от Release. На самом деле это могут быть также просто разные CRT, например, все Release, но разных версий. Или это могут быть экземпляры других общеиспользуемых библиотек.

Но как я понял, если за границу dll не передовать хендлеры и не удалять объекты созданные внутри такой dll за её границей то проблем быть не должно

Но как я понял, если за границу dll не передовать хендлеры и не удалять объекты созданные внутри такой dll за её границей то проблем быть не должно

что такое хендлеры в контексте С++?

Но как я понял, если за границу dll не передовать хендлеры и не удалять объекты созданные внутри такой dll за её границей то проблем быть не должно

Но всё равно это отнюдь не исчерпывающее правило.

я имел ввиду file handles, locales and environment variables

Ну как бы да, но там ещё дофига других есть глобальных или скрытых объектов. В CRT и в C++ RT теперь.

Я просто предлагаю вам не зацикливаться на каких-то правилах, а просто посмотреть на проблему шире, чтобы понять её глубинные причины.

да, либы еще таскают скрытый стейт в виде каких-нибудь статических переменных

согласен, так лучше и поступать, это логично линковать дебаг с дебагом, а релиз с релизом. Просто тут столкнулся в проекте с тем что на релизе работает, а если собрать проект с конфигурацией дебаг, не меняя либки, то результат с теми же входными параметрами не тот, который ожидал и вот решил получше разобраться что к чему

Привет всем. Нужна подсказка. В проекте используется сторонняя dll собранная в конфигурации release(с crt линкуется динамиччески). Если я эту release использую в своём проекте с конфигурацией debug, это же не должно привести к каким то проблемам?

Как бы если это твоя библиотека или поставляемая, тебе лучше всять (или собрать) её отладочную версию. Если взять неоткуда, ты можешь надеятся, что эта .dll написана так, что работает с любой CRT в любой конфигурации, (например, не использует CRT вообще). Такое тоже бывает.

ERROR: S client not available

Как бы если это твоя библиотека или поставляемая, тебе лучше всять (или собрать) её отладочную версию. Если взять неоткуда, ты можешь надеятся, что эта .dll написана так, что работает с любой CRT в любой конфигурации, (например, не использует CRT вообще). Такое тоже бывает.

Проект небольшой, если в Conan сейчас не найду её, быстрее на релизе отладиться

IDEA: A series of nonverbal algorithm assembly instructions (Score: 100+) Link: http://j.mp/2EyozRL Comments: http://j.mp/2Ezrlq7

.

В supapro мне не ответили (

Подскажите, где можно почитать про юнит-тесты начиная с основ. Гуглил сам, не смог найти "точку входа" - вся найденная информация предполагает, что я уже что-то знаю

Подскажите, где можно почитать про юнит-тесты начиная с основ. Гуглил сам, не смог найти "точку входа" - вся найденная информация предполагает, что я уже что-то знаю

http://blog.byndyu.ru/2010/01/tdd.html https://habrahabr.ru/post/169381/ https://tproger.ru/translations/unit-tests-purposes/

http://blog.byndyu.ru/2010/01/tdd.html https://habrahabr.ru/post/169381/ https://tproger.ru/translations/unit-tests-purposes/

TDD - это когда нахуй писать код, давайте лучше еще ебанем тестов(с)

TDD - это когда нахуй писать код, давайте лучше еще ебанем тестов(с)

не нарушай процесс обучения

TDD - это когда нахуй писать код, давайте лучше еще ебанем тестов(с)

Ну вообще я абсолютно согласен. Первое (НУЛЕВОЕ!!) чему нужно обучать в TDD — это что тесты являются ВСПОМОГАТЕЛЬНЫМ СРЕДСТВОМ ДЛЯ СОЗДАНИЯ ПО. А не целью жизни разработчика.

TDD это хороший старт для проектирования API и обзора поляны use case. Возводить их в самоцель - да, зачем? но владеть этой техникой нужно.

всё хорошо в меру, как говорится

TDD - это когда нахуй писать код, давайте лучше еще ебанем тестов(с)

нет, это "нахуй писать лишний код, не имея никакого представления как он будет работать, давайте начнем с описания в тестах его интерфейса и ожидаемого поведения с точки зрения пользователя"

http://theiced.livejournal.com/254704.html

считаю, что тесты - это ок. Но тесты должны покрывать код, а не код писаться для подтверждения работы тестов.

главное, что этот тезис здесь никто не выдвигал

считаю, что тесты - это ок. Но тесты должны покрывать код, а не код писаться для подтверждения работы тестов.

прочитай то, что я написал, столько раз, сколько необходимо, пока не поймешь

во, накидали, спасибо!

прочитай то, что я написал, столько раз, сколько необходимо, пока не поймешь

дело вкуса.

дело вкуса.

нет, какого вкуса, прочитай еще раз

в тдд тесты позволяют тебе СОЗДАТЬ минимально необходимый и достаточный АПИ, потом его реализовать так, как его ожидает увидеть пользователь, ну и потом проверять что он продолжает работать, так как ожидает от него пользователь

Я еще раз повторяю - твой коммент - это дело исключительно твоего вкуса и тех приложений, которые ты разрабатывал. В моем случае это никогда а) не нужно и б) не подходит. Поэтому ешь свое tdd ложкой, но не пытайся меня этим кормить

вкус тут не при чём

Я еще раз повторяю - твой коммент - это дело исключительно твоего вкуса и тех приложений, которые ты разрабатывал. В моем случае это никогда а) не нужно и б) не подходит. Поэтому ешь свое tdd ложкой, но не пытайся меня этим кормить

мкей, понятно

Я еще раз повторяю - твой коммент - это дело исключительно твоего вкуса и тех приложений, которые ты разрабатывал. В моем случае это никогда а) не нужно и б) не подходит. Поэтому ешь свое tdd ложкой, но не пытайся меня этим кормить

если ты никогда не разрабатывал АПИ интерфейс для другой программы, то и понятно что а) и б)

Я еще раз повторяю - твой коммент - это дело исключительно твоего вкуса и тех приложений, которые ты разрабатывал. В моем случае это никогда а) не нужно и б) не подходит. Поэтому ешь свое tdd ложкой, но не пытайся меня этим кормить

ok, посоветуй тогда @narical с вершины своего опыта истинно верный путь. пока я не увидел от тебя, чтобы ты что-то предложил.

> истинно-верный путь. Программирование - это не церковь. Тут не единственно правильного решения

> истинно-верный путь. Программирование - это не церковь. Тут не единственно правильного решения

ну тогда ознакомление с TDD ни к чему плохому привести не может. напротив, откроет хороший подход к проектированию API. ну а дальше свой опыт уже введет свою шкалу мер и весов.

ну тогда ознакомление с TDD ни к чему плохому привести не может. напротив, откроет хороший подход к проектированию API. ну а дальше свой опыт уже введет свою шкалу мер и весов.

олегу лучше тебя знать, что полезно а что нет

Я сам разберусь, мне пока "предмет исследования" непонятен. Начиная с того, что делаю я свой проектик - имеет ли смысл делать тесты для него, и КАК ИМЕННО это делается.

Я сам разберусь, мне пока "предмет исследования" непонятен. Начиная с того, что делаю я свой проектик - имеет ли смысл делать тесты для него, и КАК ИМЕННО это делается.

смотря какой проектик, на определенных масштабах разные виды тестов бывают бессмысленными

Пока я регулярно собираю, запускаю и тыкаю всячески кнопочки. Иногда вдруг падает.