Сообщение Re: Стадии сборки проекта - почему это важно (на примере) от 10.07.2023 6:20
Изменено 10.07.2023 6:35 rg45
Re: Стадии сборки проекта - почему это важно (на примере)
Здравствуйте, Shmj, Вы писали:
S>C C++, как оказалось, это критически важно и без этого даже не поймешь почему не работает прога. Думал хватит понимания что есть 3 стадии:
S>1. Препроцессор — раскрывает #include, #define, #if и пр.
S>2. Сам компилятор для каждого файла создает o-файл.
S>3. Линкер собирает все в единую библиотеку или exe-файл.
S>Оказалось что этого не достаточно, что видно из примера. Сейчас привожу максимально упрощенный пример, он из 3 файлов:
S>Вопрос: почему если раскомментировать контруктор по умолчанию //BaseClass() {} — оно перестает компилироваться? Оказывается без понимания стадий сборки не поймешь этого. Тут чел. приводил стадии трансляции, возможно с этим тоже связано.
S>Честно сказать, даже доведя до мин. примера (общими силами), я не до конца понимаю почему возникает ошибка компиляции при явном консрукторе. Примерно так — если сборщик видит явный конструктор, то он уже не ищет реализацию класса DerivedClass а просто сразу отрабатывает assert. А вот если конструктор не указать явно, то почему assert не отрабатывает?
S>Вот положа руку на сердце — вы понимаете логику сбоки в этом случае?
А что тут понимать, тут просто все как угол двери. Но сначала мне бы хотелось увидеть твои комментарии по поводу "Оказалось что этого не достаточно, что видно из примера". Что именно тебе видно, что оказалось и почему знаний о трех фазах трансляции не достаточно?
S>C C++, как оказалось, это критически важно и без этого даже не поймешь почему не работает прога. Думал хватит понимания что есть 3 стадии:
S>1. Препроцессор — раскрывает #include, #define, #if и пр.
S>2. Сам компилятор для каждого файла создает o-файл.
S>3. Линкер собирает все в единую библиотеку или exe-файл.
S>Оказалось что этого не достаточно, что видно из примера. Сейчас привожу максимально упрощенный пример, он из 3 файлов:
S>Вопрос: почему если раскомментировать контруктор по умолчанию //BaseClass() {} — оно перестает компилироваться? Оказывается без понимания стадий сборки не поймешь этого. Тут чел. приводил стадии трансляции, возможно с этим тоже связано.
S>Честно сказать, даже доведя до мин. примера (общими силами), я не до конца понимаю почему возникает ошибка компиляции при явном консрукторе. Примерно так — если сборщик видит явный конструктор, то он уже не ищет реализацию класса DerivedClass а просто сразу отрабатывает assert. А вот если конструктор не указать явно, то почему assert не отрабатывает?
S>Вот положа руку на сердце — вы понимаете логику сбоки в этом случае?
А что тут понимать, тут просто все как угол двери. Но сначала мне бы хотелось увидеть твои комментарии по поводу "Оказалось что этого не достаточно, что видно из примера". Что именно тебе видно, что оказалось и почему знаний о трех фазах трансляции не достаточно?
Re: Стадии сборки проекта - почему это важно (на примере)
Здравствуйте, Shmj, Вы писали:
S>C C++, как оказалось, это критически важно и без этого даже не поймешь почему не работает прога. Думал хватит понимания что есть 3 стадии:
S>1. Препроцессор — раскрывает #include, #define, #if и пр.
S>2. Сам компилятор для каждого файла создает o-файл.
S>3. Линкер собирает все в единую библиотеку или exe-файл.
S>Оказалось что этого не достаточно, что видно из примера. Сейчас привожу максимально упрощенный пример, он из 3 файлов:
S>Вопрос: почему если раскомментировать контруктор по умолчанию //BaseClass() {} — оно перестает компилироваться? Оказывается без понимания стадий сборки не поймешь этого. Тут чел. приводил стадии трансляции, возможно с этим тоже связано.
S>Честно сказать, даже доведя до мин. примера (общими силами), я не до конца понимаю почему возникает ошибка компиляции при явном консрукторе. Примерно так — если сборщик видит явный конструктор, то он уже не ищет реализацию класса DerivedClass а просто сразу отрабатывает assert. А вот если конструктор не указать явно, то почему assert не отрабатывает?
S>Вот положа руку на сердце — вы понимаете логику сбоки в этом случае?
А что тут понимать, тут просто все как угол двери. Но сначала мне бы хотелось увидеть твои комментарии по поводу "Оказалось что этого не достаточно, что видно из примера". Почему знаний о трех фазах трансляции не достаточно и каким образом пример это демонстрирует?
S>C C++, как оказалось, это критически важно и без этого даже не поймешь почему не работает прога. Думал хватит понимания что есть 3 стадии:
S>1. Препроцессор — раскрывает #include, #define, #if и пр.
S>2. Сам компилятор для каждого файла создает o-файл.
S>3. Линкер собирает все в единую библиотеку или exe-файл.
S>Оказалось что этого не достаточно, что видно из примера. Сейчас привожу максимально упрощенный пример, он из 3 файлов:
S>Вопрос: почему если раскомментировать контруктор по умолчанию //BaseClass() {} — оно перестает компилироваться? Оказывается без понимания стадий сборки не поймешь этого. Тут чел. приводил стадии трансляции, возможно с этим тоже связано.
S>Честно сказать, даже доведя до мин. примера (общими силами), я не до конца понимаю почему возникает ошибка компиляции при явном консрукторе. Примерно так — если сборщик видит явный конструктор, то он уже не ищет реализацию класса DerivedClass а просто сразу отрабатывает assert. А вот если конструктор не указать явно, то почему assert не отрабатывает?
S>Вот положа руку на сердце — вы понимаете логику сбоки в этом случае?
А что тут понимать, тут просто все как угол двери. Но сначала мне бы хотелось увидеть твои комментарии по поводу "Оказалось что этого не достаточно, что видно из примера". Почему знаний о трех фазах трансляции не достаточно и каким образом пример это демонстрирует?