Читаю Дейтела. Вот уже какой раз встречаю, что в примерах кода встречаются странные моменты. Сразу думал, что типа описался переводчик или ещё что-то типа того. Но по-скольку данный момент встречается постоянно, то я всё-таки решил задать вопрос. Т.к. у меня самое последнее издание, которого на просторах интернета я не встречал, то приведу подобный пример с другого издания данного автора.
Имеется интерфейс класса String, который находится в включаемом файле string2.h
Имеется реализация класса, String, в котором объявлены и описаны всё функции-элементы и элементы-данные класса String. Файл реализации находится в string2.cpp
Проверка класса происходит в коде Fig8_5.cpp. В данном коде разумеется присуствует функция main() и всё в плане компановки кода понятно и логично. Но странно одно. Почему в данный код, где проверяется класс включается только файл интерфейс класса ? Ведь он не знает о реализации данного класса?
Горы кода не привожу, т.к. там пришлось бы делать скриншоты длиннющие. Но надеюсь и так всё понятно. Суть я объяснил.
Я б сделал иначе. По логике файл-интерфейс класса можно включать в компилируемый файл реализации класса. А класс уже импортировать в сам код ( с функцией main() ). Неужели это не логичнее?

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

hoz, наверное Вы работаете в какой-нибудь IDE?
Если так, то рекомендую сначала научиться работать с компилятором из командной строки. 
Также важно прочитать о процессе создания исполняемого файла. Этапов в этом процессе много.

Итак, есть три файла. Все в одном каталоге.

program.cpp


myclass.h


myclass.cpp


У меня компилятор g++, а линковщик ld ( вызывается компилятором автоматически ) . Пробую создать исполняемый файл с помощью следующей команды.

На что получаю интересный ответ.



Так вот видно - линковщик ld написал мне об ошибке. Он понятия не имеет где реализация конструктора myClass::myClass() 
Так откуда же линковщик узнает где реализация конструктора myClass()?

А от меня же и узнает. Я ему сам об этом напишу.


Вот теперь все в порядке и у меня появился исполняемый файл. Запущу его для проверки.


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


Это сообщение отредактировал(а) BlackSpace - 21.4.2014, 03:39

hoz, почитай что такое "единица трансляции", внутреннее и внешнее связывание. Это должно прояснить каритну.

Получается что так. С командной строкой сталкивался только при работе в некоторых случаях в операционных системах с открытых кодом. Но задачи были другие. Я так понял, если классов несколько, то при компиляции придётся дописывать каждый класс для линковки... Странный подход. Проще вроде как было б, включить класс в файл реализации... а получившееся уже добавлять в программу.. Не так ли?
Интересно зачем было городить такое..



Сегодня же и почитаю.

hoz, я сам люблю некоторые IDE. Удобно в них мне. Много вкусностей. Рефакторинг, подсветка, автодополнение, автоформатирование и другие.
Но запросто пользуюсь простым текстовым редактором ( любимый vim  ) и общаюсь с компилятором через командную строку. 

Так как более опытные люди в прошлом мне изначально советовали оставить все IDE и учиться работать с командной строкой. Этот опыт дает понимание что хочет от тебя компилятор и что тебе дает на выходе. Когда сложностей уже не возникает и проект чуть больше чем маленький, то вполне можно удобно рабоать в IDE. Я около года вообще не открывал IDE и все проекты писал в vim и общался с компилятором только через командную строку. Чего и Вам советую сделать.


Не совсем так. N классов могут быть определены в одном заголовочном файле .h и реализация их методов может быть в другом одном файле .cpp
Тогда в опциях компилятору ( кроме файла с функцией main() ) надо будет передать лишь один файл .cpp

BlackSpace, я с редактором Vim сталкивался ещё когда изучал FreeBSD. Но цели были другие. Редактор, несомненно, очень крутой. Тока вот ситуация такая, что у меня уклон чутка иной. Я занимаюсь реализацией некоторых стратегий торговых экпертов для торговли на различных торговых инструментах.
 Изначально писалось всё на mt4. Потом я понял, что на нём далеко не уедешь.. Ещё тогда ничего не знал ни о классах, ни о инкапсуляции.. Вообще даже не слышал много, что сейчас вот изучаю активно. Но пришёл момент, когда я застрял на месте, и немало времени прошло пока смог понять, что мне нужно. Причина была в том, что не было желания объявлять те же элементы и, вообще узлы кода, как таковые по несколько раз. 
Понимаю, что то что стало из mt4 это С++ - подобное нечто, но не совсем то. Да, со временем можно и даже нужно будет всё-таки реализацию основных функций-элементов перекинуть в dll вообще, да и вообще чисто на C++. Но, на данный момент, скрестить mt4 и С++ я не совсем представляю как. Потому приходится как-то крутится в том IDE, который предоставляет их платформа.
 Vim на винде не используется, на сколько я слышал. Да и то, что я пишу, на Vim'е не написать. Потому, научиться этому, конечно, можно. Но писать без IDE, как Вы, навряд ли выйдет.

Это сообщение отредактировал(а) hoz - 21.4.2014, 18:37

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

Нагородили, потому что не проектировали. С++ родился в ходе тяп-ляпничества одного господина, чьё имя мы  здесь не будем произносить.  Жалкие потуги исправить жуткие огрехи в дизайне языка мы наблюдаем уже какой десяток лет. Но фундаментальнейший изъян в виде отсутствия модулей, видимо, устранен так и не будет.

В очередной раз всё это разжёвывать уныло. Решение Ваших проблем лежит, по всей видимости, в другой плоскости. Вы выбрали неправильный инструмент для решения задачи. Вам С++ не подходит, потому что Вы не программист-профессионал (то есть не программист по профессии). Более того, он Вам и не нужен, так как не будучи программист-профессионалом, Вы преимуществ из его использования не извлечёте, а нагорожено там ой-ой-ой.
 

Вы бы хоть подробнее объяснили, что за задачу Вы пытаетесь решить? И что такое mt4? Потому что язык (и платформу) выбирают под задачу.

Это сообщение отредактировал(а) kemiisto - 21.4.2014, 19:11

kemiisto, учитывая, что C++ старше тебя, тебе не кажется, что ты несколько не понимаешь тех реалий? 

будет. Более того уже есть экспериментальная реализация, то ли в gcc, то ли в clang.

Это сообщение отредактировал(а) vinter - 21.4.2014, 19:15

О, нет. Я то как-раз понимаю. Как понимаю и то, что сейчас реалии совсем иные.


Как можно реализовать то, чего нет в стандарте? Вы не понимаете, видимо, про какую модульность я говорю.

hoz, а я Вас не склоняю именно к vim. Это дело вкуса, предпочтений, а vim я привел просто как пример редактора. Если решили изучать C++  потому что оно Вам надо, то сосредоточтесь на нем и забудьте пока про другое. Изучайте C++ по Вашим любимым учебникам, но не используя никаких IDE. Только простой редактор кода ( NotePad++, блокнот и т.д. ) и командная строка. Плюс изучение справочных материалов о Вашем компиляторе. 
А когда разберетесь на некотором уровне в C++, проработав несколько учебников - будет проще ответить на вопрос - для каких задач Вам лучше использовать C++.

Это сообщение отредактировал(а) BlackSpace - 21.4.2014, 19:47

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


И в какой же?



На данный момент, мне нужны некоторые пусть даже основы. Т.к. все выкрунтасы мне точно не к чему. Нужно понимать, хотя бы базу.


Вот это и есть mql4 под терминал МТ4. Там же и редактор кода имеется встроенный в платформу. Языки то бывают разные, и платформы тоже.. но я, на данный момент, пишу под эту по причине распространённости оной.


kemiisto, я выше писал, что "застрял" в один "прекрасный" момент над очередным творением и понял, что дальше так продолжаться не может. А причина в том, что я писал чисто блоками. Были только методы + глобальные переменные. Потом добавил инклюдники + библиотеки. Этого оказалось мало, т.к. когда библиотеки используют множество повторяющихся кодов и переменных, это есс-но не вариант. Вот пришлось думать...
 Т.к. mql4 - Си подобный язык. (изначально). А последняя версия больше С++ - подобный. Так вот я решил проштудировать С++, что научиться решать подобные задачи. Как Вы заметили, я не профессионал, а любитель, и, потому мне сложновато многие вещи понимать с ходу. Но по тиху въезжаю.
 После кропотливого выбора, я приобрёл пару книг: Дейтела "Как программировать на С (Седьмое издание)" и Стивена Прата "Язык программирования С++ (6-ое издание)". Начал с Дейтела.
 Решил освоить вещи, которые нужны. Классы, полиморфиз, виртуальные классы, инкапсуляцию.. Вот потиху читаю.
 Если я пишу на С++ - подобном языке, то у меня вариантов то нет. Получается мне нужен С++. Как же иначе?

Это сообщение отредактировал(а) hoz - 21.4.2014, 19:55

а стандарт по твоему ангелами с неба спускают? Всё обновление стандартной библиотеки последних редакций есть влияние буста. Другие фичи имеют больший потенциал быть принятыми в стнадарт, если уже есть реализация, на которой можно обкатать некоторые вещи. А не просто теорию мусолить. Так, например, concepts lite уже реализованы на какой-то ветке gcc. 

Что добавляет оптимизма, так это большое внимание уделяемое модулям. Это одна из очень важных фич, которую многие ждут. Глядишь и увидим её в 17-м.

Это сообщение отредактировал(а) vinter - 21.4.2014, 19:55

ТС такие перспективы врядли устроят.  

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

Потому реализацыя компилируется чаще всего отдельно. В объектный файл, с расшырением .o (на винде -- .obj). А затем отдельные объектные файлы склеиваются вместе в библиотеки объектных файлов -- изначально -- файлы с расшырением .a (archive), последние два десятка лет, когда эти библиотеки объектных файлов стали разделяемыми  -- в .so (shared object, разделяемый объектный файл) (в винде -- .dll, dynamic link library, библиотека с динамическим связыванием, по сути -- тожэ самое).

Отличие .so от обычных объектных файлов и их архивов -- что обычные объектные файлы при компиляцыи включаются в получающийся образ программы. А разделяемые -- нет, в образе программы на них имеются только ссылки. Эти ссылки связываются (обновляются) при запуске программы, что, с одной стороны, требует чтобы кроме файла с программой где-то в доступном месте лежали ещё и .so-библиотеки. С другой -- библиотеки лежат на диске один раз в одном месте, а не забивают каждый выполняемый файл, что позволяет их и быстрее грузить (меньшэ обращаться к диску, если библиотека ужэ в памяти), и проще обновлять (только сменить один файл, вместо того, чтобы перекомпилировать всё, что от неё зависит).

В общем, идея использовать только некоторый интэрфейс при компиляцыи, и не требовать реализацыи -- очень полезная, по факту.