Здравствуйте, Сергей Губанов, Вы писали:

СГ>Так я и говорю не модульный.

Ну ладно. Пусть так.

СГ>Придумайте другое слово. Сипульки — например, а?

Ну не надо наезжать то. Они вообще-то могут быть и большими. У меня нет ограничения один класс — один модуль.

Я не думаю, что под модульностью понимается невозможность их (модулей) циклической зависимости.

Сергей Губанов wrote:

> Ёёёооууу, а звездочка "*" — это разьве не указатель?
> Вооще-то, ни кто не может использовать сам класс (а не указатель) не
> зная о нем ничего. Ведь как ни крути, но размер-то его объектов хотя
> бы знать-то надо...

Достаточно размера, на самом деле. В С++ есть placement new и можно
кастовать указатель на "сырую память" к объекту. С помощью такого трюка
можно делать эффективные compilation firewall'ы, ну и в оптимизации
часто очень помогает.

>>> А слабо скомпилировать в динамически загружаемый исполняемый модуль
> (DLL)?
> C>Не слабо. См. boost.plugin — динамическая подгрузка плугинов на С++.
> Еще раз ёёёооууу!!!! Вооще-то, ни кто не может скомпилировать в
> исполняемый модуль то что он сам не знает.
> Нельзя получить исполняемый модуль имея всего-лишь такой исходный код:
>
> class A;
>
>
Зато можно так:

class ABase
{
    virtual method1()=0;
    virtual method2()=0;
};

И работать через виртуальную ABase. Кроме того, есть еще
"полудинамический диспатчинг" как раз для таких случаев — смотреть в
сторону Boost.Interfaces.

> и не имея при этом определения того, что же есть это "А".
> Unresolved external symbol однако...

Если это pure virtual abstract class, то проблем не будет.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

S>Я не думаю, что под модульностью понимается невозможность их (модулей) циклической зависимости.

Дело в том, что модуль — это не только единица компиляции, но и единица исполнения. Но и это еще не всё. Модули можно динамически загружать и выгружать по мере необходимости не выключая при этом всю многомодульную программу целиком.
Модули могут импортировать друг друга. Граф импорта, естественно, ацикличен. Просто конгломерат (кластер, граф) циклически зависящих друг от друга сущностей — это и есть то что можно загрузить/выгрузить только целиком, но не по частям, т.е. модулем является вся эта совокупность сущностей целиком.

Простейший пример модульности: пусть есть два модуля program.exe и library.dll. Модуль program.exe может импортировать (зависеть от) модуль library.dll, а наоборот — нет.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Просто конгломерат (кластер, граф) циклически зависящих друг от друга сущностей — это и есть то что можно загрузить/выгрузить только целиком, но не по частям, т.е. модулем является вся эта совокупность сущностей целиком.

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

А насчет выгрузки. Я нигде не видел такой реализации, ни в Java ни в .Net. Почему-то никто не любит выгружать. Хотя и это сделать можно. При желании.

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

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

VD>>Ну, а теперь попробую обосновать. Дело в том, что единственная цель ради которой стоит разбивать исходники на отдельные файлы — это логическая организация кода и упрощение навигации по нему.

S>Имхо, именно для этого классы и объединяются в исходники по несколько.

По моему речь идёт о больших классах, никто не будет выносить в отдельный модуль вспомогательный класс с 3-мя методами — конструктором, деструктором и проверкой корректности, например. К тому же, некоторые классы зависят друг от друга (редкая вещь, может неправильно проектирую?) и просто "обязаны" быть в одном модуле.

VD>>Конечно современные средства навигации позволяют находить классы и методы даже если они хаотически разбросаны по проектам...

S>Ну, никто же не говорит про "хаотически разбросаны".

Для Вас не хаотически, я вот прошлым летом очень намучился с такими исходниками другого программиста. И главное не знаю кому морду бить.
К тому же при модификации программы небольшой класс, представляющей собой какую-либо концепцию в программе может очень сильно разростись. Что делать тогда будешь? (у месяц назад из 300 строк в 3560 вылилось, а всё потому, что поленился сначала два маленьких класса запихнуть в два файла)

Я лично пишу функции не более 80 строк и модули примерно по 500-1200 строк (ну иногда и меньше). Больше не надобится никогда и никакие цикличиские сылки не мешают.

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

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

ГВ>>> В принципе, я совершенно согласен, что "Поддерживать хорошо структурированные небольшие файлы в кторых заранее известно что лежит намного проще чем шариться по файлам в поиске файлов и функций в них" но ведь из этого никак не следует, что в каждом файле лежит ровно один класс, верно?
VD>>Не верно. Файл даже с двумя более менее серьезными классами в принципе не может быть маленьким и простым.

ГВ>А вот тут давай поподробнее. С чего ты взял, что "серьёзные классы", размер которых приводит к "аду" в навигации по его телу вообще должны быть? Моё и, кстати, не только моё мнение по этому поводу сводится к тому, что большие классы нужно рубить на куски. Чем раньше, тем лучше. В противном случае получаем суровую ошибку проектирования. Разумеется, это не относится к классам-API типа какого-нибудь навороченного интерфейса IMyCoolSoftware о двухстах методах, поскольку такие классы как правило содержат очень простой шлюзовой код и ничего более.

Между прочим, при анализе исходников, в "серьёзных классах" ориентироватся гораздо легче, т.к. при разбиении последних обычно получается запутанная иерархическая структура — ад для отладки и производительность обычно ниже. И вообще, что такое "серьёзный класс" ещё подумать надо прежде чем писать (я уже не подумал, у меня всегда так)

Вообще много что-то понаписали...

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

S>А насчет выгрузки. Я нигде не видел такой реализации, ни в Java ни в .Net. Почему-то никто не любит выгружать. Хотя и это сделать можно. При желании.

О! То-то и оно. Знаете, в этих системах 1) есть JIT компилятор, 2) так называемые Java или .NET модули на самом деле содержат внутри себя вовсе не уже готовый к выполнению машинный код, а фактически они содержат исходный текст программы написанный на промежуточном языке программирования (Java byte code, MSIL). Так вот, ни что не мешает, чисто теоретически, этому JIT компилятору просто взять все исходные модули используемые программой и скомпилировать их в один большой виртуальный мега exe-шник, но никому его не показывать — дескать его на самом деле нету, дескать система модульная и всё такое; и запустить на выполнение этот "потайной" exe-шничек, а потом стереть его втихомолку. Ну а в Java, так и делать его не обязательно — там интерпретировать можно. Ясное дело, что при таком подходе однажды загруженный модуль выгрузить уже невозможно — надо будет много чего перекомпилировать, и наверняка программу перезагрузить придется.

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

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

ГВ>>> Основная причина — различия в работе с одним и несколькими файлами в текстовом редакторе.
VD>>И что прыганье по туче мест в одном файле проще чем выбрать в дереве проекта нужный файл-класс?

ГВ>Чёй-то я не понимаю противопоставления. Тут уж или "выбрать несколько файлов", или вообще никакого противопоставления нет.

Не понимашь? Тогда о чем споришь?

VD>>Нет. Из этого следует, что для С++ (если бы не тормоза при компиляции и проблему необходимости предварительной декларации) в первую очередь полезно разносить классы по отдельным файлам.

ГВ>А кто спорит с полезностью разнесения классов по файлам вообще?

Мне показалось, что ты. Я ошибся?

ГВ> Я как раз оспариваю постулат, что "один класс = один файл".

Оспаривай.

VD>>Ну, и то что чем бороться с проблемами старичка проще на него забить.

ГВ>Ну это-то подразумевается тобой почти в каждом посте в "философии",

В 2002-ом и до этого я еще питал какие-то иллюзии. Но сейчас у меня уже сомнений нет. Этот уродец мне не нужен. Все стоящие передомной задачи я намного проще решаю без него.

ГВ> я уж даже удивляться перестал.

А ты удивлялся?

ГВ>Другое дело, что основания для такого твоего вывода выглядят всё более зыбкими...

Аутотренинг тебе явно вреден.

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

C>Тонкая == fine-grained. Просто при работе с папками из FAR'а не очень
C>удобно, когда вложенность очень глубокая.

Я пользуюсь Тоталкомандером и проблем не испытываю. Хотя он тут не причем. Основная рбота с проектами ведется из студии.

C>Ну а чем это отличается от выбора вместо вкладки с файлами выбрать
C>вкладку с логической структурой?

Какие еще вкладки? Нужен класс — выбирашь его в списке файлов проекта. Если открыто слишком много окон, закрывашь все файлы кроеме того над которым в данный момент работаешь.

C>Семантический поиск спасет отца советской демократии.

Никого он не спасает. Поиск есть и по проекту и по солющену. Плюс есть еще навигация по коду. Но это все дополнительные возможности. Структурирования кода они не заменяют.

C>С другой стороны, когда файлов очень много — так же сложно найти НУЖНЫЙ
C>файл.

Много это сколько? В проекте R# 673 только .cs-файлов. В редакторе кода который я сейчас пишу на сегодня 82 файла. В Хоуме 409. Ни в одном из проектов проблем с поиском нужного участка кода не встает. И поиск обычно ведется по фйлам, а не по логической структуре, так как в ней можно утонуть (она ведь не может структурироваться папками).

C>VisualAssist справляется.

Помню я как он справлялся. Вместо АТЛ-а показывал МФЦ. А на более менее сложных шаблонах врал безбожно.

C>Кстати, есть еще "инсайдерская" информация — одна контора пишет
C>realtime-парсер для С++ на основе gccxml. Будет под лицензией GPL, и
C>скорее всего, сразу будет добавлен в KDevelop.

Ну, ну. Мечты... мечты.

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

S>В приведенном мной примере 4 группы. В них по 3-4 класса всего. А в последней группе — всего 1 класс. Если так мелко делать папки, то... . Это во-первых.

С четыремя файлами ты и в плоском списке не запуташся.

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

S>Как раз сейчас я делаю свою систему со своим встроенным языком и хотел узнать мнение народа, пойти ли по пути Java, или по традиционному пути . И как раз таки разные мнения доказывают, что особых преимуществ ни у того ни у другого пути нет.

S>С другой стороны, WinAPI, VCL, Mono, JNI, OCI, OCCI (C++ интерфейс к Oracle) сделаны большими исходниками.

Не нужно путать стиль и требование языка.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>О! То-то и оно. [] Ясное дело, что при таком подходе однажды загруженный модуль выгрузить уже невозможно — надо будет много чего перекомпилировать, и наверняка программу перезагрузить придется.
Садись два. Модуль нельзя выгрузить по тому что сначала нужно удалить все объекты которые были созданы на основе кода этого модуля. В общем случае это не возможно.
Можно конечно на каждую сборку повесить счетчик сссылок и каждый раз при создании объекта его увиличивать, а при удалении уменьшать... но тк эта функциональность реально мало кому нужна то...
К томуже если вспомнить о доменах то сборки таки можно выгружать... правдо только вместе с доменом.

VladD2 wrote:

> C>Тонкая == fine-grained. Просто при работе с папками из FAR'а не очень
> C>удобно, когда вложенность очень глубокая.
> Я пользуюсь Тоталкомандером и проблем не испытываю. Хотя он тут не
> причем. Основная рбота с проектами ведется из студии.

Ну так в студии и нет проблем с прыжками по файлам. Жму ctrl-j и пишу
имя класса — ассист мне на него прыгает.

> C>Ну а чем это отличается от выбора вместо вкладки с файлами выбрать
> C>вкладку с логической структурой?
> Какие еще вкладки? Нужен класс — выбирашь его в списке файлов проекта.
> Если открыто слишком много окон, закрывашь все файлы кроеме того над
> которым в данный момент работаешь.

Есть вкладка "ClassView" — в ней класс точно так же выбрать можно.

> C>С другой стороны, когда файлов очень много — так же сложно найти НУЖНЫЙ
> C>файл.
> Много это сколько? В проекте R# 673 только .cs-файлов. В редакторе
> кода который я сейчас пишу на сегодня 82 файла. В Хоуме 409. Ни в
> одном из проектов проблем с поиском нужного участка кода не встает. И
> поиск обычно ведется по фйлам, а не по логической структуре, так как в
> ней можно утонуть (она ведь не может структурироваться папками).

У меня в солюшене 20 проектов, кода около мегабайта. Файлов порядка 100.

Поиск определения "глазками" — не напрягает абсолютно, в каждом файле
1-3 класса. Самое большее — 20 (классы узлов AST-дерева).

> C>VisualAssist справляется.
> Помню я как он справлялся. Вместо АТЛ-а показывал МФЦ. А на более
> менее сложных шаблонах врал безбожно.

Он с тех пор улучшился.

> C>Кстати, есть еще "инсайдерская" информация — одна контора пишет
> C>realtime-парсер для С++ на основе gccxml. Будет под лицензией GPL, и
> C>скорее всего, сразу будет добавлен в KDevelop.
> Ну, ну. Мечты... мечты.

Ну уж помечтать нельзя...

--
С уважением,
Alex Besogonov (alexy@izh.com)

WolfHound wrote:

> СГ>О! То-то и оно. [] Ясное дело, что при таком подходе однажды
> загруженный модуль выгрузить уже невозможно — надо будет много чего
> перекомпилировать, и наверняка программу перезагрузить придется.
> Садись два. Модуль нельзя выгрузить по тому что сначала нужно удалить
> все объекты которые были созданы на основе кода этого модуля. В общем
> случае это не возможно.
> Можно конечно на каждую сборку повесить счетчик сссылок и каждый раз
> при создании объекта его увиличивать, а при удалении уменьшать... но
> тк эта функциональность реально мало кому нужна то...
> К томуже если вспомнить о доменах то сборки таки можно выгружать...
> правдо только вместе с доменом.

В Java все сделано очень просто — там код классов (в том числе и JIT)
собирается сборщиком мусора Красивое решение, ИМХО.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Сергей Губанов, Вы писали:

СГ>О! То-то и оно. Знаете, в этих системах 1) есть JIT компилятор, 2) так называемые Java или .NET модули на самом деле содержат внутри себя вовсе не уже готовый к выполнению машинный код, а фактически они содержат исходный текст программы написанный на промежуточном языке программирования (Java byte code, MSIL).

Ну, дык, понятное дело знаю. Я же VM всою делал. Литературу читал.

СГ>Так вот, ни что не мешает, чисто теоретически, этому JIT компилятору просто взять все исходные модули используемые программой и скомпилировать их в один большой виртуальный мега exe-шник, но никому его не показывать — дескать его на самом деле нету, дескать система модульная и всё такое;

На самом деле он этого, конечно же, не делает.

СГ>Ну а в Java, так и делать его не обязательно — там интерпретировать можно.

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

СГ>Ясное дело, что при таком подходе однажды загруженный модуль выгрузить уже невозможно — надо будет много чего перекомпилировать, и наверняка программу перезагрузить придется.

Выгрузить нельзя по другим причинам:

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

Вот такие дела...

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

C>Есть вкладка "ClassView" — в ней класс точно так же выбрать можно.
Никогда им не пользуюсь ибо там утонуть можно...

C>У меня в солюшене 20 проектов, кода около мегабайта. Файлов порядка 100.
А у меня 78 проектов 10,078,520 байтов кода в 2268 файлах.

C>Поиск определения "глазками" — не напрягает абсолютно, в каждом файле 1-3 класса. Самое большее — 20 (классы узлов AST-дерева).
А у нас в каждом файле один класс.

И проблем с поиском нужного файла не возникает из-за нормальной структуры проекта.

WolfHound wrote:

> C>Есть вкладка "ClassView" — в ней класс точно так же выбрать можно.
> Никогда им не пользуюсь ибо там утонуть можно...

namespace спасают.

> C>У меня в солюшене 20 проектов, кода около мегабайта. Файлов порядка 100.
> А у меня 78 проектов 10,078,520 байтов кода в 2268 файлах.

У нас в проекте лежит еще куча либ, с ними кода мегов на 20 будет.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

>> C>Есть вкладка "ClassView" — в ней класс точно так же выбрать можно.
>> Никогда им не пользуюсь ибо там утонуть можно...
C>namespace спасают.
Ты кого за лемера инсталишь маздай не пропатченый!?
Все раздожено по пространствам имен в лучшем виде. Не помогает.

WolfHound wrote:

>>> C>Есть вкладка "ClassView" — в ней класс точно так же выбрать можно.
>>> Никогда им не пользуюсь ибо там утонуть можно...
> C>namespace спасают.
> Ты кого за лемера инсталишь маздай не пропатченый!?



> Все раздожено по пространствам имен в лучшем виде. Не помогает.

Сторонние либы гадят в основной неймспейс? Еще помогает то, что у нас
нэймспейсы организованы наподобии пакетов в Java.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>>namespace спасают.
WH>Ты кого за лемера инсталишь маздай не пропатченый!?
WH>Все раздожено по пространствам имен в лучшем виде. Не помогает.

Вот подкину еще одну тему для размышления: Делать много маленьких неймспейсов или нет.

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