Здравствуйте, prVovik, Вы писали:

V>Я уже писал, что без исключний теоретически можно обходиться, но это неудобно.

Удобно или не удобно это уже другой вопрос...


SYG>>Предлагаю Вам решить такую задачу:
SYG>>Вы являетесь автором одного динамически загружаемого модуля. Этот модуль создает объекты и отдает указатели на них другим динамически загружаемым модулям (другие модули написаны другими производителями, и у Вас есть/будут только их бинарники). На момент написания своего модуля Вы даже точно не знаете какие именно будут те самые другие модули. Как Вы будете принимать решение об уничтожении созданных в Вашем модуле объектов? Как Вы узнаете что созданный Вашим модулем объект больше никем не используется?

V>Да хотябы вот так вот: http://www.rsdn.ru/article/cpp/GCcpp.xml

Автор(ы): Михаил Чащин
Дата: 18.11.2002

Да ничего подобного! Вы дали ссылку на решение задачи для случая когда вся программа состоит всего из одного модуля (скомпилирована в один единственный огромный и монолитный exe-шник), а я все время говорю о модульных программах, то есть программах состоящих, быть может, из нескольких тысяч динамически загружаемых модулей. Давайте внимательно прочитаем задание:
SYG>>Вы являетесь автором одного динамически загружаемого модуля. Этот модуль создает объекты и отдает указатели на них другим динамически загружаемым модулям (другие модули написаны другими производителями, и у Вас есть/будут только их бинарники).

Как организована ваша приватная внутримодульная утилизация более не используемых ресурсов — Ваше личное дело и оно не интересует другие модули (можете даже использовать для этого ту ссылку которую привели). Вопрос состоит в другом — как Вы будете принимать решение об уничтожении объектов адреса которых Вы сообщали другим (внешним) модулям?

В той ссылке описывается доморощенный сборщик мусора работающий только внутри одного модуля. То есть если запустить два экземпляра такой программы, то, соответственно, будет два доморощенных сборщика мусора. Две таких программы не смогут обмениваться объектами друг с другом. Я же говорю об одном единственном на всю ОС сборщике мусора который единолично разруливает все объекты всех модулей системы. В Component Pascal, .NET и Java сборщик мусора всего один на всю систему независимо от того сколько программ (модулей) в этой системе в данный момент загружено. Так понятно?

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Вы дали ссылку на решение задачи для случая когда вся программа состоит всего из одного модуля (скомпилирована в один единственный огромный и монолитный exe-шник)
Я дал эту ссылку для того, чтобы показать технологию эмулирования сборщика мусора. Я думал, что вы догадаетесь, что по тому же принципу можно сделать и разделяемый сборщик мусора. В чем проблема?

Здравствуйте, prVovik, Вы писали:

V>Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>>Вы дали ссылку на решение задачи для случая когда вся программа состоит всего из одного модуля (скомпилирована в один единственный огромный и монолитный exe-шник)
V>Я дал эту ссылку для того, чтобы показать технологию эмулирования сборщика мусора. Я думал, что вы догадаетесь, что по тому же принципу можно сделать и разделяемый сборщик мусора. В чем проблема?

Даже не знаю что и ответить. Действительно, а в чем собственно проблема-то? Всего-то навсего надо написать свой собственный эмулятор ОС (или, на худой конец, свою виртуальную машину) со сборщиком мусора и линковщиком для динамической загрузки модулей. Тяп ляп и готово. Работы на полчаса...

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

Здравствуйте, S.Yu.Gubanov, Вы писали:

DG>>В .Net-е, Java-е, скриптах, Smalltalk-е и т.д. — это проблема же как-то решается.

SYG>Java — интерпретатор (там может быть все что угодно), Smalltalk — не модульный, а в .Net встроен JIT компилятор — это явно не "упрощение", а "утяжеление".

Простите, а почему это Smalltalk не модульный?

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>До сих пор проблема была в том, что Вы утверждали, что сборщик мусора в принципе не нужен, а нужен только для удобства, а я пытался убедить Вас в том что он нужен вовсе не для удобства, а в принципе чтобы писать модульные программы, так как модульные программы без него писать невозможно.


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

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG> Всего-то навсего надо написать свой собственный эмулятор ОС (или, на худой конец, свою виртуальную машину) со сборщиком мусора и линковщиком для динамической загрузки модулей. Тяп ляп и готово. Работы на полчаса...
Во-первых, я не говорил, что будет легко . Во-вторых, не надо никаких осей, машин и пр. Достаточно лишь обязать все модули работать с разделяемым сборщиком мусора.

SYG>До сих пор проблема была в том, что Вы утверждали, что сборщик мусора в принципе не нужен, а нужен только для удобства, а я пытался убедить Вас в том что он нужен вовсе не для удобства, а в принципе чтобы писать модульные программы, так как модульные программы без него писать невозможно.
Стоп, все было не совсем так Я говорил, что при отсутствии встроенного сборшика мусора его работу теоретически можно сэмулировать стандартными средствами. Вот цитата:

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

Вы же начали протестовать...
Я вас убедил в том, что можно решить вашу задачу на С++, несмотря на то, что в С++ нет сборшика мусора?

Здравствуйте, prVovik, Вы писали:

V>Я вас убедил в том, что можно решить вашу задачу на С++, несмотря на то, что в С++ нет сборшика мусора?

Для одного отдельно взятого модуля, для его внутренних объектов, адреса которых он внешним модулям не сообщал, теоретически можно во время написания модуля расставить все delete и вообще забить на сборщик мусора. Для многомодульных программ сама среда исполнения должна обладать сборщиком мусора.

SYG> Всего-то навсего надо написать свой собственный эмулятор ОС (или, на худой конец, свою виртуальную машину) со сборщиком мусора и линковщиком для динамической загрузки модулей. Тяп ляп и готово. Работы на полчаса...
V>Во-первых, я не говорил, что будет легко . Во-вторых, не надо никаких осей, машин и пр. Достаточно лишь обязать все модули работать с разделяемым сборщиком мусора.

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

Здравствуйте, serg_mo, Вы писали:

s>Простите, а почему это Smalltalk не модульный?

Не знаю. Наверное ему просто не повезло. Хотя как знать, как знать...

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Для одного отдельно взятого модуля, для его внутренних объектов, адреса которых он внешним модулям не сообщал, теоретически можно во время написания модуля расставить все delete и вообще забить на сборщик мусора. Для многомодульных программ сама среда исполнения должна обладать сборщиком мусора.
Можно ли динамически загружаемую длл считать динамически загружаемым модулем? И если нет то почему?

Здравствуйте, WolfHound, Вы писали:

WH>Можно ли динамически загружаемую длл считать динамически загружаемым модулем? И если нет то почему?

Модуль — это абстракция языка программирования. После компиляции, модуль имеет физическое представление, например, пускай в виде DLL файла. Но, дело в том, что обычную Win32 DLL называть скомпилированным модулем как-то не очень хорошо, ведь в Win32 DLL не содержится подробной информации о типах, а в модуле она содержится.

Из хелпа к BlackBox-у:
When compiling a module, the compiler produces a code file and a symbol file. The code file contains the executable code, which can be loaded into memory. The code file is a kind of super-lightweight DLL. The compiler also produces a symbol file, which contains a binary representation of the module's interface. If a module imports other modules, the compiler reads the symbol files of all these modules, in order to check that their interfaces are used correctly.

Таким образом, в BlackBox-е модуль после компиляции физически представляется двумя бинарными файлами: symbol file — там хранится бинарное представление типов, так сказать бинарный эквивалент "заголовочного файла"; и code file — super-lightweight DLL.

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

Я считаю что серьезный код зависит от задачи и если от нее плясать то, серьезный код- это код который при изменении задачи или её расширении, дополнении придется минимально расширять + не менять логику програмы в корне.

Здравствуйте, S.Yu.Gubanov, Вы писали:

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

Здравствуйте, WolfHound, Вы писали:

WH>Можно ли динамически загружаемую длл считать динамически загружаемым модулем? И если нет то почему?

Есть все же разница между возможностью создания на языке динамически загружаемых библиотек. И модульной архитектурой языка.

Когда заходит речь о немодульности С++, то речь идет о том, что импорт типов в С++ делается самым глупым и непроизводительным образом — инклюдами. Т.е. по сути импорта как такового нет. Есть обязательное предворительное объявление (предекларация) используемых типов в текстовм виде. И некоторый макросный механизм по подстановке содержимого одного файла в другой.

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

Как показала практика С++ не спасает даже прекомпилируемые хэадеры. Скорость компиляции VC в десятки раз медленнее шарпа (а то и больше). Это прямое следствие не модульности С++. Причем совсем не ясно почему нельзя добавить модульность в С++. Концепции языка это вроде изменить не дожно. Если только шаблоны затронет.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>А, например, в .NET-е после компиляции модуль физически представляется одним бинарным файлом в котором есть и код и информация о типах.
Странно... ну и толку от информации о типах то? Почему модули это то что есть бинарник(любого вида) + информация о типах?
Если наша задача требует модульности... (например ОС Windows сама по себе нуждается в ней и приложения которые под нее написаны ее используют), но именно в том виде в котором она существует. Для того что бы бинарный код общался между собой они должны следовать одному и тому же протоколу, и... и модули в том же виндовз можно _динамически_ загружать и _выгружать_. Учет ссылок и выделенных ресурсах при этом (как и в любых неуправлямых средах) лежит на нас. Поэтому говорить о том что там это нельзя, а здесь можно, просто глупо. На универсальных языках можно все — вот вопрос хотим ли мы писать среду выполнения для себя... вот это уже другой вопрос. Хотя как я заметил как правило любой более-менее большой продукт имеет какие-то управляющие примитивы в run-time
В конце концов... какие-нибудь серверы которые работают 24х7 — довольно критичны к падениям. Возьми любой из Apache. Что? Глючит? А если и заглючит, думаешь упадет? Ну завалить оооочень сложно. А если есть критичность ко всем "завалам" так один клиент на процесс (что настраивается просто в конфиге, просто медленнее работать будет — и ты просто не сможешь нарушить работу других клиентов)... так что надежность по разному реализовать можно. А модуль — выполнен оказался как процесс. в моем примере... ес-сно
За это я и люблю программирование Тут все можно с ног на уши поставить

Здравствуйте, S.Yu.Gubanov, Вы писали

SYG>Не знаю. Наверное ему просто не повезло. Хотя как знать, как знать...

Хм... А если говорить по существу?
Я, например, работаю в VisualWorks Smalltalk. В нем есть такая единица распространения скомпилированного кода, как парсел (parcel). Парсел включает в себя классы (и даже может включать методы классов, не входящих в данный парсел ). Код в парселе хранится в скомпилированном виде (исходники тоже могут идти с парселем, но в отдельном файле).
Также в парселе хранится и мета-информация (например, список определенных в нем классов).
Парсел может быть программно загружен и выгружен. После загрузки парсела определенные в нем классы (методы, переменные и т. д.) становятся доступны в системе.

Так вот, мой вопрос, собственно, таков: можно ли парсел назвать модулем?
И если нет, то почему?

Здравствуйте, serg_mo, Вы писали:

_>Хм... А если говорить по существу?
_>Я, например, работаю в VisualWorks Smalltalk. В нем есть такая единица распространения скомпилированного кода, как парсел (parcel). Парсел включает в себя классы (и даже может включать методы классов, не входящих в данный парсел ). Код в парселе хранится в скомпилированном виде (исходники тоже могут идти с парселем, но в отдельном файле).
_>Также в парселе хранится и мета-информация (например, список определенных в нем классов).
_>Парсел может быть программно загружен и выгружен. После загрузки парсела определенные в нем классы (методы, переменные и т. д.) становятся доступны в системе.

_>Так вот, мой вопрос, собственно, таков: можно ли парсел назвать модулем?
_>И если нет, то почему?

А, ну если так, то прошу прощения. Общипся я.

Здравствуйте, WolfHound, Вы писали:

SYG>>Но, дело в том, что обычную Win32 DLL называть скомпилированным модулем как-то не очень хорошо, ведь в Win32 DLL не содержится подробной информации о типах, а в модуле она содержится.

WH>Не очень хорошо но в принципе можно? А если еще к дллке приложить заголовочный фаил с описанием типов для того чтобы можно было компилить другие дллки?

Частично на Ваш вопрос ответил Vlad2:
http://www.rsdn.ru/Forum/Message.aspx?mid=739894&only=1

Автор: VladD2
Дата: 28.07.04

Скажем так, модулем называется некая абстракция (среды программирования), а "dll-ка + заголовочный файл" — это одна из реализаций этой абстракции. Если у Вас есть только "dll-ка + заголовочный файл", но нет среды программирования поддерживающей абстракцию модуля, то это так и останется "dll-кой + заголовочный файл" и модулем оно не станет.

WH>А можно ли назвать модулем дллку которая предоставляетописание интерфейсов и несколько фабрик классов которые порождают объекты классов реализующих эти интерфейсы?

Совершенно по барабану что внутри дллки.

Здравствуйте, VladD2, Вы писали:

VD>Причем совсем не ясно почему нельзя добавить модульность в С++. Концепции языка это вроде изменить не дожно. Если только шаблоны затронет.

Шаблоны + inline функции + обратная совместимость с Си + все старые программы надо будет переделать так как надо будет перед некоторыми переменными и именами функций написать имя модуля в котором они объявлены. Выгоднее создать новый язык чем пытаться вносить модульность в существующий С++. Наверное, из-за этого и появился C#.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Шаблоны + inline функции + обратная совместимость с Си + все старые программы надо будет переделать так как надо будет перед некоторыми переменными и именами функций написать имя модуля в котором они объявлены.

Ничего подобного. С++ обладает всеми нужными фичами по определению области видимости. В том же МС++ добавили всего одну директиву "#import" позволившую сделать из С++ модульный язык. При это оставили даже возможность инклюдить все как раньше.

SYG> Выгоднее создать новый язык чем пытаться вносить модульность в существующий С++. Наверное, из-за этого и появился C#.

Ну, Шарп сделали как новый язык в котором попытались совместить общую продуманность и простоту. Он даже клоном С++ не является.

AF> серъёзный" код

Код (библиотеки функций, классов, сервисы, утилиты), которым активно пользуются другие программисты