Вопросы по C от ламера, В книжках ответа чёта не нахожу Опции

[Guest_Скопидор_*]

Зачем вообще нужно ключевое слово «auto»?
Ведь классификатор(или квалификатор? как это слово точно называется?) памяти «auto» никак не используется ( по крайней мере в исходниках разных разработчиков я его не видел).
Т.к. глобальные переменные не могут быть « auto», а локальные и так по умолчанию «auto».

Сообщение отредактировал Скопидор - Apr 10 2009, 11:19

[SysRq]

Почему после того, как я вместо iostream.h стал юзать iostream объём экзешника вырос с 0.2МБ до почти о.5МБ?

wcin, wcout...

А обязательно ли в препроцессорной директиве #include использовать файлы с расширением .h ?

Нет. Часто применяется, к примеру, .hpp. Аналогия C -- .c, C++ -- .cpp.

...когда выгодно использовать эту директиву в середине, или даже в конце основного файла?

Когда выгодно! Скажем, изменить макрос какой-нить, используемый в исходнике, вставив .h-файл с ifdef-undef-define этого макроса в середину исходника, и пусть враги догадываются почему мой спёртый ими исходник у них не работает.

Использование #include подразумевает экспортирование ресурсов из .h-файла. А бывают ли случаи, когда наоборот...

Неверное понятие сути, нет там экспортирования никакого. Это паззл, если хотите

Если main – функция, то можно ли её рекурсивно вызвать внутри её самой?

Зависит от того, как она определена, от атрибутов ее. Сохранение контекста и прочее...

Как избежать в своей программе непреднамеренного «экранирования» идентификаторов из стандартной библиотеки?

Читать документацию на используемые бибилиотеки.

[Guest_Скопидор_*]

Неверное понятие сути, нет там экспортирования никакого. Это паззл, если хотите

Ну как же. Например, я могу описать в h-файле прототип функции f1 и юзать его внутри тела функции f2, которая определена в h-файле. А вот конкретная реализация f1 будет содержаться в файле, в который будет вложен h-файл, т.е. как бы будет импортироваться из основного файла. Т.е. получается, что реализация f2 будет зависеть от того, куда будет вложен h-файл.

Зависит от того, как она определена, от атрибутов ее. Сохранение контекста и прочее...

Т.е. в принципе возможно юзать вызовы main внутри тела main?

Читать документацию на используемые бибилиотеки.

И больше никак? Т.е. я при выборе каждого идентификатора в своей проге должен смотреть: «а нет ли точно такого же идентификатора в стандартной библиотеке». Так?


А насчёт перепрыгивания участка восстановления контекста из стека что скажете?

[SysRq]

Ну как же.

Срочно читать как из .cpp получается .exe.

Т.е. в принципе возможно юзать вызовы main внутри тела main?

Можно. Поищите еще "точка входа".

Т.е. я при выборе каждого идентификатора в своей проге должен..

Вы какой язык изучать собрались? C++? Инкапсуляция, наследование, и т.п. -- туда читайте. Вопрос отпадет. О глобальных переменных флудить не будем, тема уже была, ищите на форуме.
Как правило хорошего тона afaik не следует использовать _такие и __такие вот идентификаторы в прикладной программе.

А насчёт перепрыгивания...

За goto - секирбашка. Особенно в C++. Флудить не будем, тема уже была тоже.

[Guest_Скопидор_*]

Срочно читать как из .cpp получается .exe.

В 2 этапа: сначала по отдельности компилируем все файлы (получаем OBJ-файлы), потом линкуем. Правильно?

Вы какой язык изучать собрались? C++? Инкапсуляция, наследование, и т.п. -- туда читайте. Вопрос отпадет. О глобальных переменных флудить не будем, тема уже была, ищите на форуме.

Т.е. если «очень постараться» ( ) (ну не внимательно подойти к выбору идентификаторов в своей программе), то всё же есть вероятность «наступить на грабли» и случайно экранировать идентификаторы из стандартной библиотеки в своей проге? Я не говорю сейчас о своих идентификаторах, начинающихся на _, __ или заканчивающихся на _t.
Допустим, к примеру, я такой дуб, что не знал, что в библиотеке уже юзаются cin и cout. И взял, и переопределил их в своей проге. Может такое быть?

За goto - секирбашка. Особенно в C++. Флудить не будем, тема уже была тоже.

Да я не собираюсь флудить, нужен или не нужен goto. Просто хотел узнать как это реализуется: осуществляется «прыжок» за пределы блока и при этом, КАК-ТО, восстанавливается контекст, сохранённый на входе в блок.

P.S. Прошу прощения, если мои вопросы кажутся глупыми, я ж говорю, я ламер.

[ReAl]

Допустим, к примеру, я такой дуб,
...
Может такое быть?

Запросто.
Но достаточно либо

определить свои cin/cout в своём пространстве имён oak и квалифицировать при использовании oak::cin

либо

не переносить сущности стандартной библиолтеки в глобальное пространство имён, что происходит при использовании

Код

#include <iostream.h>

вместо

Код

#include <iostream>

или при совсем глобальном переносе

Код

using namespace std;

В этом случае к "стандартно-библиотечным" придётся обращаться как к std::cin, но они тоже не пересекутся с новоявленными.

А вообще поломать можно что угодно.

[andrew_b]

Код

#include <iostream.h>

Так это давным-давно deprecated.

Ну когда мы делаем "add File to Project"

Ну и при чём тут компилятор.

мы же хидеры добваляем в категорию "Header". И после того как файл проекта (dsn по-моему) сформирован, компилятор знает, какие *.h файлы юзать при сборке. Разве не так?

Компилятор про проект ничего не знает.

[Guest_Скопидор_*]

Ну и при чём тут компилятор.
Компилятор про проект ничего не знает.

А для кого тогда создаётся DSN-файл?
.....................................
.....................................
.....................................
ReAl!!

Спасибо за столь развёрнутый и подробный ответ. Я его весь пока не асисилил, но работаю над этим

Т.е. как я понял, компилятор выделяет память под все локальные переменные любого уровня вложенности блоков на входе в функцию? Т.е. если в функции описана переменная i, а во вложенном в функцию блоке – переменная j, то память в стеке и под i и под j будет выделена на входе в функцию, а уничтожена на выходе по команде return?

Сообщение отредактировал Скопидор - Apr 15 2009, 08:42