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

Цитата Qraizer @ 22.01.11, 07:10

Мы вообще можем откомпилить половину

[сарказм]... а потом узнать, что реализации-то нет оказывается, и линковать не с чем...[/сарказм]

Сообщение отредактировано: korvin - 22.01.11, 07:39

Цитата korvin @ 21.01.11, 23:36

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

1) В ООП модули на уровне логики вообще не нужны - класс полностью обеспечивает модульность. Остается физическое представление.
2) А класс сколько раз загружается ? Или путаем классы и объекты?
3) директивы вроде import никто не отменял. Смотри, например, на java. Модулей нет - есть классы, которые объединяются в пакеты.

Т.о. получается, что модули в современном С++ не нужны. Их, быть может, следовало когда ввести, но сейчас практически бессмысленно.

Добавлено 22.01.11, 12:14

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

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

Плохо...

А как ты себе иначе это представляешь?

Из модуля при импорте "читается" только часть интерфейса, сам он не компилируется. Далее модули могут компилироваться независимо друг от другу, если не менялись интерфейсные части.

Цитата

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

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

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

В чем хак? Мы полностью убираем всю лишнюю информацию из интерфейса, который видит клиент. Устраняем лишние зависимости интерфейса от других модулей(интерфейс может не зависит от тех модулей, от которых зависит реализация.

Цитата

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

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

Полностью согласен. Я очень рад, что TAPL идет в массы
Только в ООП языках модулем является класс. А для "физического" их размещения вполне достаточно файлов и концепции единиц трансляции.

Сообщение отредактировано: D_KEY - 22.01.11, 12:17

Цитата D_KEY @ 22.01.11, 12:09

Полностью согласен. Я очень рад, что TAPL идет в массы
Только в ООП языках модулем является класс. А для "физического" их размещения вполне достаточно файлов и концепции единиц трансляции.

1) это может быть верным только для чистых ОО-языков, к коим С++ не относится
2) задача класса -- описывать объекты, а не служить этаким универсальным комбайном

Цитата korvin @ 22.01.11, 13:00

Цитата D_KEY @ 22.01.11, 12:09

Полностью согласен. Я очень рад, что TAPL идет в массы
Только в ООП языках модулем является класс. А для "физического" их размещения вполне достаточно файлов и концепции единиц трансляции.

1) это может быть верным только для чистых ОО-языков, к коим С++ не относится
2) задача класса -- описывать объекты, а не служить этаким универсальным комбайном

1) Это может быть верно для любых языков, поддерживающих ООП
2) Да. Но тем не менее, класс полностью обеспечивает модульность.

Цитата D_KEY @ 22.01.11, 13:35

Это может быть верно для любых языков, поддерживающих ООП

нет, контрпример -- CL

Цитата korvin @ 22.01.11, 14:03

Цитата D_KEY @ 22.01.11, 13:35

Это может быть верно для любых языков, поддерживающих ООП

нет, контрпример -- CL

Там классы не обеспечивает модульность?

Цитата Qraizer @ 22.01.11, 07:10

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

Нет, интерфейсы соблюдают контракт.

Цитата Qraizer @ 22.01.11, 07:10

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

Это мысли вслух, они ничем не обоснованны.

Цитата Qraizer @ 22.01.11, 07:10

Мы вообще можем откомпилить половину, засунуть в библиотеку и потерять сырцы.

Ну мы тоже можем выкинуть все исходники и работать только с одними DCU.

Цитата D_KEY @ 22.01.11, 14:06

Там классы не обеспечивает модульность?

нет

Цитата DesweR @ 22.01.11, 15:12

Ну мы тоже можем выкинуть все исходники и работать только с одними DCU.

А интерфейсы где смотреть?

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

В ООП класс полностью заменят понятие модуля.

В некоторых языках это так, только не заменяет, а подменяет Причем в коммерческих (исключительно) целях

Цитата --Ins-- @ 22.01.11, 18:08

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

В ООП класс полностью заменят понятие модуля.

В некоторых языках это так, только не заменяет, а подменяет Причем в коммерческих (исключительно) целях

Что дают модули(не как единицы трансляции, а на уровне логики), чего не в состоянии обеспечить классы?

Цитата korvin @ 22.01.11, 13:00

2) задача класса -- описывать объекты, а не служить этаким универсальным комбайном

+1. Уже устал твердить на разных форумах, что классу просто приписали понятие пространство имен, кое к ООП никакого отношения не имеет. Но ведь иначе нельзя будет заявить что Java/C# - это 100% объектно ориентированные языки. А в этом случае реклама потерпит эпик фэйл и языки не продвинутся на рынок (за счет чего?). Так что это просто дешевая уловка на которую клюют недалекие программисты и менеджеры

Добавлено 22.01.11, 18:18

Цитата D_KEY @ 22.01.11, 18:12

Что дают модули(не как единицы трансляции, а на уровне логики), чего не в состоянии обеспечить классы?

Всё. Так как задачи у модулей и у классов - совершенно разные

Цитата --Ins-- @ 22.01.11, 18:14

Всё. Так как задачи у модулей и у классов - совершенно разные

Ты так и не ответил на вопрос!

Цитата D_KEY @ 22.01.11, 18:12

Что дают модули(не как единицы трансляции, а на уровне логики), чего не в состоянии обеспечить классы?

Цитата KILLER @ 22.01.11, 18:36

Ты так и не ответил на вопрос!

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

Цитата --Ins-- @ 22.01.11, 18:39

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

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