Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата D_KEY @ 20.01.11, 21:05

А причем тут паскаль?
Что было-то? Файл проекта или это ты так странно ответил на мои вопросы про раздельную компиляцию?

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

uses
  Unit1 in "units/Unit1.pas";

и то может в паскале так тоже можно

а компилятор паскаля да, "сам отследит изменения и перекомпилит нужные модули" и зависимости разрулит.

Цитата D_KEY @ 20.01.11, 20:42

То есть все связи доступны по исходникам и без IDE(имея только компилятор языка Delphi), можно спокойно работать? И он сам отследит изменения и перекомпилит нужные модули?

А зачем тут IDE? Конечно все связи в исходниках указаны

Цитата D_KEY @ 20.01.11, 20:42

Кстати, а раздельная компиляция модулей как работает? Если один модуль зависит от другого, они могут компилироваться в произвольном порядке или модуль, от которого зависят, должен компилироваться раньше?

Если какой-то из модулей изменился, то он перекомпилируется. Если изменилась не только часть реализации (implementation), но и интерфейсная часть (interface) модуля, то перекомпилируются и модули, которые непосредственно от этой интерфейсной части зависят. Остальные модули перекомпилироваться не будут. Как-то так...

Цитата --Ins-- @ 20.01.11, 22:34

Если какой-то из модулей изменился, то он перекомпилируется. Если изменилась не только часть реализации (implementation), но и интерфейсная часть (interface) модуля, то перекомпилируются и модули, которые непосредственно от этой интерфейсной части зависят. Остальные модули перекомпилироваться не будут. Как-то так...

Может ли модуль быть скомпилирован до того, как будут скомпилированы те модули, от которых он зависит?
И реализуем ли opaque pointer (pimpl) и как?

Сообщение отредактировано: D_KEY - 20.01.11, 22:44

Цитата D_KEY @ 20.01.11, 22:41

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

Не знаю, по-моему нет

Цитата D_KEY @ 20.01.11, 22:41

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

Нет.
К слову, а в C++ есть подобие секций инициализации/финализации модулей?

Цитата D_KEY @ 20.01.11, 22:41

И реализуем ли opaque pointer (pimpl) и как?

По человечески, через интерфейсы (если правильно понял)

Цитата DesweR @ 21.01.11, 18:38

К слову, а в C++ есть подобие секций инициализации/финализации модулей?

Начнём стого, что в С++ нет модулей.

блин

Ага. Очередное полезнейшее нововведения форума.

Цитата DesweR @ 21.01.11, 18:38

Цитата D_KEY @ 20.01.11, 22:41

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

Нет.

Плохо...

Цитата

К слову, а в C++ есть подобие секций инициализации/финализации модулей?

В ООП класс полностью заменят понятие модуля.
На эту тему можно почитать что-нибудь из теории ООП, например, Бертрана Мейера.
Далее нужно только определиться с физическим размещением(файлы) и группированием(пакеты, неймспейсы).

Цитата

Цитата D_KEY @ 20.01.11, 22:41

И реализуем ли opaque pointer (pimpl) и как?

По человечески, через интерфейсы (если правильно понял)

Ну не совсем.
pimpl относится к реализации уже конкретного функционала. То есть он и не мешает интерфейсам и не заменяет их.

Цитата D_KEY @ 21.01.11, 19:34

В ООП класс полностью заменят понятие модуля.
На эту тему можно почитать что-нибудь из теории ООП, например, Бертрана Мейера.

Очень давно назад я говорил примерно то же. Модули в С/С++ не нужны по причине изначально наличествовавшей раздельной компиляции. В Turbo Pascal они были добавлены по причине очень большой полезности раздельной компиляции, и идея была слизана у Модулы, авторства того же Вирта. При переходе к Object Pascal изначальная концепция модулей стала избыточной, но пересмотрена не была. Получился винегрет из модулей и ООП.

Цитата D_KEY @ 21.01.11, 19:34

В ООП класс полностью заменят понятие модуля.
На эту тему можно почитать что-нибудь из теории ООП, например, Бертрана Мейера.
Далее нужно только определиться с физическим размещением(файлы) и группированием(пакеты, неймспейсы).

нет, ибо
1) модуль ортогонален _всем_ остальным особенностям языка, даже без ООП,
2) модуль загружается только один раз (хотя тут соответчтвие понятию синглтона)
3) имеет зависимости, которые _должен_ разрулить компилятор. (тут классы джавы еще что-то могут, но никак не С++)

Добавлено 21.01.11, 23:37

Цитата Qraizer @ 21.01.11, 23:21

Очень давно назад я говорил примерно то же. Модули в С/С++ не нужны по причине изначально наличествовавшей раздельной компиляции. В Turbo Pascal они были добавлены по причине очень большой полезности раздельной компиляции, и идея была слизана у Модулы, авторства того же Вирта. При переходе к Object Pascal изначальная концепция модулей стала избыточной, но пересмотрена не была. Получился винегрет из модулей и ООП.

очевидно, что Вы не понимаете модульность в принципе

Ага, таки нашёл.

Добавлено 21.01.11, 23:48
korvin, очень даже понимаю.

Цитата D_KEY @ 21.01.11, 19:34

Плохо...

А как ты себе иначе это представляешь?
Это равносильно тому, если бы модуль с ошибками можно было частично скомпилировать (т.е. с теми местами, где ошибок нет).

Цитата D_KEY @ 21.01.11, 19:34

pimpl относится к реализации уже конкретного функционала. То есть он и не мешает интерфейсам и не заменяет их.

По мне, так это хак чистой воды.

Цитата Qraizer @ 21.01.11, 23:47

korvin, очень даже понимаю.

Ну ну.
Процитирую TAPL:

Цитата

Еще одно важное достоинство использования систем типов при разработке программ — это поддержание дисциплины программирования. В частности, в контексте построения крупномасштабных программных систем, системы типов являются стержнем языков описания модулей (module languages), при помощи которых компоненты больших систем упаковываются и связываются воедино. Типы появляются в интерфейсах модулей (или близких по смыслу структур, таких, как классы); в сущности, сам интерфейс можно рассматривать как <<тип модуля>>, содержащий информацию о возможностях, которые модуль предоставляет — как своего рода частичное соглашение между разработчиками и пользователями.

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

Цитата D_KEY @ 21.01.11, 19:34

В ООП класс полностью заменят понятие модуля.
На эту тему можно почитать что-нибудь из теории ООП, например, Бертрана Мейера.

ага, в теории и чистых ОО-языках может быть, но на практике придумывают всякие модули (Ruby), неймспейсы(C++) и пакеты (Java).

Цитата D_KEY @ 21.01.11, 19:34

группированием(пакеты, неймспейсы).

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

Добавлено 22.01.11, 06:49

Цитата D_KEY @ 21.01.11, 19:34

Цитата DesweR @ 21.01.11, 18:38

Цитата D_KEY @ 20.01.11, 22:41

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

Нет.

Плохо...

как это "плохо"? а как вообще можно использовать сущности, которых нет? как можно скомпилировать со статической проверкой модуль, в котором используются например типы, экспортированные из другого модуля? даже динамически типизированный Racket проверяет связность имен при компиляции

Цитата DesweR @ 22.01.11, 06:19

По мне, так это хак чистой воды.

Упс. Но коммент. Оказывается, вся COM, без которой Delphi жить не может, один сплошной хак.

Цитата DesweR @ 22.01.11, 06:19

Ну ну.
Процитирую TAPL:...

А я в ответ снова (коль с первого раза не доходит):

Цитата Qraizer @ 21.01.11, 23:47

Ага, таки нашёл.

Цитата korvin @ 22.01.11, 06:46

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

Пока пространства имён не придумали, только их и использовали. Не всегда это было удобно, но всегда возможно. С пространствами имён зачастую удобнее, но опять же иногда удобнее классы.

Цитата korvin @ 22.01.11, 06:46

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

Знаешь, а ведь DLL существуют. Правда-правда, это не сказка. Это я про PImpl, pointer to implementation. Для проверки связности имён достаточно интерфейса, реализация потребуется линкеру, а то и ОСи. Ты просто не понял, о чём D_KEY, похоже.

Добавлено 22.01.11, 07:17
И в этом смысле D_KEY прав. Т.к. компилятор Дельфи хавает интерфейс из .DCU, то он должен быть откомпилен. Плюсы с Сями хавают интерфейсы из .h, так что порядок компиляции моду... тьфу ты, единиц трансляции нам пофигу. Мы вообще можем откомпилить половину, засунуть в библиотеку и потерять сырцы. Главное - интерфейсы, в которые в .h лежат.