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

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

Цитата D_KEY @ 16.02.11, 19:52

В любом случае, все выделения/освобождения памяти для полей этого объекта будет происходить там, где и должно - в конструкторе и деструкторе соответственно. Этого не достаточно?

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

А, так у вас они не вызываются автоматически?

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

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

Цитата D_KEY @ 16.02.11, 19:40

Какая память? Какие экземпляры?
У вас принято настолько активно использовать глобальные переменные?

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

unit GenericString;
 
interface
 
function genstr (prefix :string = "#:") :string;
 
implementation
 
var id :Integer;
 
function genstr (prefix :string) :string;
begin
  Result := prefix + IntToStr(id);
  Inc(id);
end;
 
initialization
 
id := 0;
 
end.

в данном случае конечно можно было обойтись

var id :Integer = 0;

и не писать секцию инициализации

Именно. А если можно не писать и обойтись более лаконичным и логичным способом, то к чему был твой пример?

Цитата

Цитата D_KEY @ 16.02.11, 19:52

В любом случае, все выделения/освобождения памяти для полей этого объекта будет происходить там, где и должно - в конструкторе и деструкторе соответственно. Этого не достаточно?

это ООП головного мозга -- заводить новый тип(класс) на каждый чих... =)

Ты контекст-то не тереяй. Было сказано, что класс уже есть.

Цитата

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

это ООП головного мозга -- заводить новый тип(класс) на каждый чих... =)

не, если б в С++ были как в Яве/C# только классы и их члены, без возможности объявить "простые" переменные и функции, не относящиеся ни к какому классу, вопросов бы не было. а так получается, что язык вроде и позволяет писать без классов, но никаких гарантий модульности не предоставляет.

Я пятый раз повторяю, что модульность - это разбиение системы на элементы, т.е. модуль - логическая единица системы, а не контейнер(для этого есть пространства имен, пакеты и "кластеры").
И классы в С++ нужны не только для ООП, сколько можно повторять?

Добавлено 17.02.11, 06:52

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

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

если уж очень хочется пощеголять ключевыми словами

расскажи про explicit, ага =)

А что предлагаешь ты? Я бы, конечно, хотел, чтобы explicit был по умолчанию, но от ключевого слова ты тут не избавишься, если не хочешь ограничить пользователей языка.

Добавлено 17.02.11, 06:57

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

зачем нужно namespace, если по словам D_KEY классы в С++ покрывают все необходимости? =)

Не в С++, а в ООП. И не "покрывают все необходимости", а обеспечивают модульность.
Повторю еще раз, специально для тебя, что модуль - это не свалка, а логическая единица декомпозиции системы. В ООП декомпозиция строится вокруг типов(классов), соответственно, классы и обеспечивают модульность. Подробности у Мейра, например. (тебе понравится, он критикует С++, выступает за ссылочные типы и т.д. и т.п.).

Добавлено 17.02.11, 06:59

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

что мне мешает подключить genstr.c вместо genstr.h?

Мозг?

Добавлено 17.02.11, 07:00

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

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

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

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

Потому, что class не является расширяемым, в отличие от пространств имен.

Добавлено 17.02.11, 07:01

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

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

Добавлено 17.02.11, 07:04

Цитата korvin @ 16.02.11, 23:10

замени слово "класс" на "модуль" и все поймешь, только модуль еще зависимости разруливает и гарантированно инициализируется только один раз. гарантированно перед функцией main

Зачем это нужно при использовании ОО-декомпозиции?

Добавлено 17.02.11, 07:05

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

последний раз: разговор не о том, на чем написана ОС, а о самой архитектуре ОС. в этой архитектуре ядро -- глобальная переменная.

Цитата

напиши ОС, где ядро -- локальная переменная, например на каждый сискол создается новое ядро.

Ядро вообще не переменная. Можешь пойдешь полистаешь Таненбаума?

Добавлено 17.02.11, 07:09

Цитата korvin @ 16.02.11, 23:59

Цитата KILLER @ 16.02.11, 23:56

где там С++, и классы в упор не вижу... иди кури книжки

если для тебя ООП -- это C++ и классы, то тебе стоит не курить книжки, а почитать.

того же Мейера например

И тебе туда же. Особое внимание обрати на то, что он пишет о модулях, типах, системах и декомпозиции

Добавлено 17.02.11, 07:09

Цитата korvin @ 16.02.11, 23:25

2) прочитаешь про AOP литературу, тогда поговорим =)

Что это?(в смысле какую литературу рекомендуешь).

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

Цитата D_KEY @ 17.02.11, 06:44

А, так у вас они не вызываются автоматически?

Я ж говорил, и не один раз. Автоматически конструкторы и деструкторы вызываются только для хиповых объектов. Благо что все классы только там и размещаются. Собственно, чем не объяснение, почему именно только там, интересное дизайнерское языковое решение. Какое по счёту?
По поводу модулей... не думал, что у кого-то ещё остаются какие-то сомнения в их нужности. Появились для обеспечения раздельной компиляции вместе с блоком BEGIN/END для инициализации, каковые с появлением в языке ООП оказались бы ненужным более анахронизмом, если бы не проблемы с конструированием глобальных объетов (вот нет, чтобы изначально ущербную концепцию сменить); оказались удобними для реализации DLL, но уже явно не стало хватать противоположной по смыслу секции; наконец-то развились в INITIALIZATION/FINALIZATION. Фух. Но никто так до сих пор и не научился их применять по назначению.
Некоторый смысл был интерпретировать модуль как средство реализации формы. Однако зачем там INITIALIZATION/FINALIZATION? Я б ещё понял, если INITIALIZATION для инициализации формы, куда б класс-визард мог поместить их состояния, однако у них для этого используются другие средства, в частности виртуальные конструкторы. В общем теперь они и сами не знают, зачем им модули. Придумывают всяко-разные причины, а мы пытаемся вникнуть в них, и не получается.

Цитата Shaggy @ 16.02.11, 18:32

о чём был этот пост, хоть убей не пойму

Я процитировал в посте, что комментипровал.

Добавлено 18.02.11, 00:40
KILLER, насчет переменных ты ошибаешься.
Если переменная описана без static, то она становится глобально видимой по своему имени. Extern нужен для объявления, что где-то существует названная переменная и объявить ее тип. Заодно можно проверить что объявление и определение совпадают. Как в C так и в C++.

Цитата Qraizer @ 17.02.11, 13:41

По поводу модулей... не думал, что у кого-то ещё остаются какие-то сомнения в их нужности. Появились для обеспечения раздельной компиляции вместе с блоком BEGIN/END для инициализации, каковые с появлением в языке ООП оказались бы ненужным более анахронизмом

И как это не удивительно, но Уолтер Брайт почему то вернулся обратно к этому архаизму, посчитав его более удобным и эффективным, нежели классы и неймспэйсы

Цитата Qraizer @ 17.02.11, 13:41

Фух. Но никто так до сих пор и не научился их применять по назначению.

Назначение у них одно, то что должно быть выполнено при инициализации/деинициализации модуля - будет выполнено в соответствующей секции модуля. Вообще, вы тут настаиваете, что классы с лихвой обеспечивают те возможности, что дают модули? А вот как это выглядит? На примере INITIALIZATION/FINALIZATION мы уже видели - отдельный класс-костыль. А в остальном как? В Delphi по крайней мере модули представляют ещё и грамотную логическую, относительно C++, организацию программы, отдельные секции в модуле играют свои отдельные роли, сами модули также разделяются на различные типы, которым отведены свои роли, такая "структурность" свойственна вообще всему языку. А что-же в C++? Если "нас" можно сравнить, к примеру, с офисом - отдельными помещением, разбитым на отделы, где группы сотрудников, не мешая друг другу, выполняют свои конкретные обязанности и где Начальнику не нужно каждый раз оббегать все углы в поисках нужного человека, ему и так известно где какие отделы располагаются и где находятся его сотрудники. Так что же в С++? Очень похоже на большое голое помещение, где все сотрудники, в независимости от обязанностей, располагаются вперемешку и в качестве стульев используют подручные материалы. Универсально? - возможно Да. Удобно - наверняка Нет.

Цитата DesweR @ 18.02.11, 05:14

В Delphi по крайней мере модули представляют ещё и грамотную логическую, относительно C++, организацию программы, отдельные секции в модуле играют свои отдельные роли, сами модули также разделяются на различные типы, которым отведены свои роли, такая "структурность" свойственна вообще всему языку. А что-же в C++? Если "нас" можно сравнить, к примеру, с офисом - отдельными помещением, разбитым на отделы, где группы сотрудников, не мешая друг другу, выполняют свои конкретные обязанности и где Начальнику не нужно каждый раз оббегать все углы в поисках нужного человека, ему и так известно где какие отделы располагаются и где находятся его сотрудники. Так что же в С++? Очень похоже на большое голое помещение, где все сотрудники, в независимости от обязанностей, располагаются вперемешку и в качестве стульев используют подручные материалы.

т.е. ты утверждаешь, что в C++ программу нельзя разбивать на файлы так же, как в [объектном] паскале? Это такая уникальная возможность паскаля? А в чем же эта уникальность состоит? Я пишу на C++, при этом много ковырялся в исходниках VCL - никаких преимуществ и уникальностей не вижу.

Сообщение отредактировано: trainer - 18.02.11, 05:30

Цитата trainer @ 18.02.11, 05:24

т.е. ты утверждаешь, что в C++ программу нельзя разбивать на файлы

Вот именно, только на файлы, никакой внутренней организации нет.

Сообщение отредактировано: DesweR - 18.02.11, 05:37

Цитата DesweR @ 18.02.11, 05:14

Назначение у них одно, то что должно быть выполнено при инициализации/деинициализации модуля - будет выполнено в соответствующей секции модуля. Вообще, вы тут настаиваете, что классы с лихвой обеспечивают те возможности, что дают модули?

Вообще, лично я не настаиваю, что модули не нужны. Лично я настаиваю, что они часто вами используются не по назначению. И вот в этом самом непоназначенческом смысле инициализации/деинициализации модулей не требуется. Не требуется она также и в половине случаев, когда по назначению.

Цитата DesweR @ 18.02.11, 05:14

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

А в С++ Начальнику не нужен личный контакт с работниками. Он с ними контактирует с помощью современных средств связи. Поэтому каждый работник может работать там, где ему удобно располагаться. Как можно ближе к тесно связанным родственными задачами коллегам, и не мешая никому, кто занимается совсем иными задачами. Главное, чтобы работники не забыли интерфейсы к себе оставить. В С++ давно уже считается дурным тоном лично начальником контролировать каждого работника.

Цитата DesweR @ 18.02.11, 05:36

Вот именно, только на файлы, никакой внутренней организации нет.

Ну так выдай нам, на что там бьется программа в Delphi, что в этом такого уникального и неповторимого. А мы сравним, есть или нет. В том числе и с собственным опытом в Delphi.

Сообщение отредактировано: trainer - 18.02.11, 06:33

Цитата DesweR @ 18.02.11, 05:14

Вообще, вы тут настаиваете, что классы с лихвой обеспечивают те возможности, что дают модули?

При ООП декомпозиции модули в том виде, в котором они активно используются в структурном программировании, не нужны. Модульность же обеспечивается классами.
Конкретный язык тут не причем. Логика проста - при декомпозиции системы основными логическими единицами являются классы и объекты, а для группирования логически связанных классов("модулей") используются другие механизмы логического объединения - "пространства имен"/"пакеты"/"кластеры". "Физический" же уровень не так важен и зависит от языка. Это могут быть "единицы трансляции", файл<->класс и т.п.

Цитата

На примере INITIALIZATION/FINALIZATION мы уже видели - отдельный класс-костыль.

Костылем вообще является сама необходимость в таких секциях.
Если принять, что логическими единицой в ООП являются не модули, как в структурном, а классы и объекты, то никакой концептуальной разницы между INITIALIZATION/FINALIZATION и конструкторами/деструкторами нет.

Цитата

В Delphi по крайней мере модули представляют ещё и грамотную логическую, относительно C++, организацию программы, отдельные секции в модуле играют свои отдельные роли, сами модули также разделяются на различные типы, которым отведены свои роли, такая "структурность" свойственна вообще всему языку.

А в классе нет "отдельных секций" с "отдельными ролями"?

Цитата

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

Модули - средство декомпозиции системы, а не композиции

Цитата

Так что же в С++? ... Универсально? - возможно Да. Удобно - наверняка Нет.

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

Добавлено 18.02.11, 06:37

Цитата DesweR @ 18.02.11, 05:36

Цитата trainer @ 18.02.11, 05:24

т.е. ты утверждаешь, что в C++ программу нельзя разбивать на файлы

Вот именно, только на файлы, никакой внутренней организации нет.

А пространства имен? А классы?

Добавлено 18.02.11, 06:48

Цитата

Модуль (от лат. modulus — «маленькая мера») — составная часть, отделимая или хотя бы мысленно выделяемая из общего.

Кстати, таки нашел online-версию книги Б.Мейера.
Вот конкретная глава, относящаяся к теме модульности (сам читал давно, сейчас полистал - согласен не со всем):
Б.Мейер. "Основы ООП". 3. Модульность.

Во дают ребята... Можно до хрипоты спорить что модули не нужны и что "классы могут-классы могут все что угодно..." Но только работая долгое время с модулями и перейдя на их так сказать альтернативы и прочувствовав все то отвращение, которое почувствует человек вынужденный сесть за Запорожец после длительного вождения Мерседеса, можно понять, в чем разница и преимущество... То же, собственно, и относится и не только к модулям. Проверено на себе

--Ins--, опять путаешь теплое с мягким неудобство с непривычным

Цитата --Ins-- @ 19.02.11, 21:29

Во дают ребята... Можно до хрипоты спорить что модули не нужны и что "классы могут-классы могут все что угодно..."

Ты так и не понял, о чем я. Прочитай все-таки по той ссылке, что я привел. Кстати, если заглянешь в другие главы, найдешь много аргументов против С++, будет что обсудить, а то как-то вяло все. И вообще это классический труд по ООП.

Цитата

Но только работая долгое время с модулями и перейдя на их так сказать альтернативы и прочувствовав все то отвращение, которое почувствует человек вынужденный сесть за Запорожец после длительного вождения Мерседеса, можно понять, в чем разница и преимущество... То же, собственно, и относится и не только к модулям. Проверено на себе

"Проверено на себе" - в данном случае, аргумент нулевой, ибо человеку требуется значительное время, чтобы уйти от старых шаблонов при изучении новых концепций и идеологий(вот это точно проверено на себе - я над собой часто ставлю различные эксперементы такого рода, так что знаю, о чем говорю). --Ins--, я уже давно пытаюсь объяснить, что классы не заменяют модули напрямую. То есть использовать их точно также, как ты сейчас используешь модули - глупо. Просто как-нибудь постарайся при декомпозиции думать не о физическом разбиении и даже не о функциональном, а о типах данных(абстрактных типах и классах), которые в твоей системе присутствуют. И подумай, о каких "процедурных" модулях(как в Pascal/Delphi) в этом случае может идти речь и являются ли они на самом деле логическими единицами(=модулями) твоей системы?

Сообщение отредактировано: D_KEY - 19.02.11, 21:54

Цитата D_KEY @ 19.02.11, 21:53

при изучении новых концепций и идеологий

Если бы новых

Цитата --Ins-- @ 21.02.11, 21:22

Цитата D_KEY @ 19.02.11, 21:53

при изучении новых концепций и идеологий

Если бы новых

Это ты о чем уже сейчас ?
Можешь обосновать роль модулей в Delphi?
Они являются логическими единицами программы? А как же классы и ОО-декомпозиция?
Или же модули у вас как контейнеры? Но тогда какие же они тогда "модули"?

Цитата D_KEY @ 21.02.11, 21:25

Они являются логическими единицами программы? А как же классы и ОО-декомпозиция?

модули ортогональны каким-бы то ни было парадигмам. хочешь, юзай ООП, хочешь -- процедурное [, хочешь (если бы делфи позволяло) -- ФП. или там ЛП.]