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

Цитата Мяут-Настоящий @ 16.02.11, 21:36

namespace можно размазывать по библиотеке в 100 исходников.

че ж эту возможность не включили в классы, а то они и так почти "всесильны", а были б совсем универсальны =)

Добавлено 16.02.11, 21:44

Цитата Мяут-Настоящий @ 16.02.11, 21:42

1) Наличие мозга в черепной коробке?

2) Не паясничай

1) более весомые средства инкапсуляции есть?

2) не паясничаю, обычное требование к модулю =)

Цитата korvin @ 16.02.11, 21:42

че ж эту возможность не включили в классы, а то они и так почти "всесильны", а были б совсем универсальны =)

Да вообще выкинуть C++ и не париться с такой глупостью, как ключевые слова, брейнфак же есть!

вот про всесильность классов спаясничал, да, простите =)

Цитата korvin @ 16.02.11, 21:42

1) более весомые средства инкапсуляции есть?

В чистом C инкапсуляция - слово чуждое. В чистом C++ запиливаем нормальные решения.

Цитата korvin @ 16.02.11, 21:42

2) не паясничаю, обычное требование к модулю =)

Формализуй все нормальные требования к модулю в таком случае.

Цитата Мяут-Настоящий @ 16.02.11, 21:44

Да вообще выкинуть C++ и не париться с такой глупостью, как ключевые слова, брейнфак же есть!

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

Цитата korvin @ 16.02.11, 21:46

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

Интуитивно не возникает мысли, что управление пространствами имен - средство, лежащее над классами?

Добавлено 16.02.11, 21:49
Ты еще скажи, что class для организации циклов не годиться

Цитата Мяут-Настоящий @ 16.02.11, 21:45

Формализуй все нормальные требования к модулю в таком случае.

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

кстати в чистом Си инкапсуляция не меньше С++-ной -- все те же .c, компилируемые в .o, скрывающие реализацию и .h предоставляющие интерфейс. в C++ как раз менее инкапсулирован в виду того, что описание класса (а также часто шаблонов) полностью находится в .h/.hpp

Добавлено 16.02.11, 21:53

Цитата Мяут-Настоящий @ 16.02.11, 21:49

Интуитивно не возникает мысли, что управление пространствами имен - средство, лежащее над классами?

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

Цитата korvin @ 16.02.11, 21:51

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

Если рассматривать, что все блоки { } образуют пространства имен, то namespace и class представляется небольшим уточняющим дополнением =)

Цитата korvin @ 16.02.11, 21:51

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

Ну тогда причем весь сыр-бор из-за id?

Цитата Мяут-Настоящий @ 16.02.11, 21:57

1) Если рассматривать, что все блоки { } образуют пространства имен, то namespace и class представляется небольшим уточняющим дополнением =)

2) Ну тогда причем весь сыр-бор из-за id?

1) ну да, я уже показывал, что на одной лямбде можно далеко уехать =)

2) хз, я просто показал, что средства модульности в делфи ортогональны парадигмам, используемым в языке, можно хоть в ООП, в структурном программировании писать, свойство модульности не изменится

В C нету чистых модулей

Цитата Мяут-Настоящий @ 16.02.11, 22:03

В C нету чистых модулей

как и в C++, тем не менее .c -> .o -- реализация, .h -- интерфейс

korvin, это не модули, а средства раздельной компиляции.

offtop

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

Добавлено 16.02.11, 22:17

Цитата Мяут-Настоящий @ 16.02.11, 22:11

korvin, это не модули, а средства раздельной компиляции.

я и не говорил, что модули. это средство инкапсуляции =)

Цитата Alexander N @ 16.02.11, 18:15

Например в модуле описан класс и переменная этого класса. У последней поля надо инициализировать. А одно поле - указатель на динамическую память, которая нужена во время всей работы программы, а потом надо ее освободить. Как ты это реализуешь без initializatioт/fanalization секций? Через одно место если только...

В конструкторе и деструкторе этого класса, это же очевидно, даже Васе, который только начал изучать С++

Добавлено 16.02.11, 22:28

Цитата Alexander N @ 16.02.11, 20:01

Именно А они вызываются в секциях initialization и finalization

Да какая разница где они вызываюца, у тебя же это поле класса, как вы на делфи то пишете через жопу все... пипец просто...

Добавлено 16.02.11, 22:35

Цитата korvin @ 16.02.11, 20:02

инициализация локальных данных модуля, например:

Глобальных данных модуля, ты хотел сказать? ну так static в С++ никто не отменял пока, ежели чего, хотя я к таким данным отношусь с опаской, и у меня сразу же возникает желание, обернуть все это дело как минимум в какой нить синглтон, или же вообще уйти от глобальной переменной, потому как это первый признак плохого дизайна...

Добавлено 16.02.11, 22:37
Вернее, было бы сказать глобальной переменной в пределах видимости модуля.

Цитата KILLER @ 16.02.11, 22:26

Глобальных данных модуля, ты хотел сказать? ну так static в С++ никто не отменял пока, ежели чего, хотя я к таким данным отношусь с опаской, и у меня сразу же возникает желание, обернуть все это дело как минимум в какой нить синглтон, или же вообще уйти от глобальной переменной, потому как это первый признак плохого дизайна...

т.е. syslog, cron и прочие демоны по-твоему -- признак плохого дизайна? ядро ОС с его сервисами (планировщик, менеджер памяти и т.п.) -- тоже признак плохого дизайна? =)

(static тут не при чем кстати, просмотри мой код и мяута, там нет нигде static)

Сообщение отредактировано: korvin - 16.02.11, 22:41