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

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

А что, using'и кто-то еще пишет руками?

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

S>Кто как предпочитает писать: Много маленьких исходных текстов или немного, но более длинных? Какова средняя длина (хотя бы с точностью до порядка)? Аргументы в пользу того или иного подхода?
S>Если не учитывать неудобства, связанные со спецификой языка (типа медленная компиляция и т.п.), то как бы вы хотели писать?

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

Ну, а теперь попробую обосновать. Дело в том, что единственная цель ради которой стоит разбивать исходники на отдельные файлы — это логическая организация кода и прощение навигации по нему. Если в одном файле навалено несколько классов и куча функций, то о простоте навигации уже говорить трудно. Лично я пользуюсь соглашениями о форматировании RSDN в которых четко указано, что не вложененые: классы, структуры и перечисления должны находиться в отдельных файлах, а имена файлов должны соотвествовать именам классов. Это за одно позволяет структурировать классы путем размещения их классов в отдельных директориях.

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

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

S>Кто как предпочитает писать: Много маленьких исходных текстов или немного, но более длинных? Какова средняя длина (хотя бы с точностью до порядка)? Аргументы в пользу того или иного подхода?
S>Если не учитывать неудобства, связанные со спецификой языка (типа медленная компиляция и т.п.), то как бы вы хотели писать?
Насчет функций. В большинстве случаев, не больше экрана. Количество строчек зависит от разрешения. Если больше то начинаю думать как рефакторнуть.
Иногда построить алгоритм значительно легче в одной процедуре (большое количество последовательных действий). Тогда так и пишу. Если есть время (и хотение) то потом уже разбиваю на различные логические части.
Что касается файлов, то как-то не регламентирую. Лишь бы наполнение было логически связано. Есть файлы и по 5 тысяч строк. Если файлы по одному классу. В большинстве случаев — класс-файл более удобно. Особенно в условиях VSS.

С уважением, Gleb.

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

Хорошо. Я понял.

Просто выскажу свое мнение. Лично я пишу большими исходниками:

— Я использую имя исходного текста для логического разбиения групп классов (compiler.h, parseTree.h и т.п.).
— Внутри исходника я также отделяю более мелкие группы комментариями. Для меня важен порядок следования этих групп.
— Для меня также важен порядок следования классов внутри соответствующей группы.

Помоему вся эта прелесть теряется, если использовать один файл на класс, соответственно наблюдая общую структуру проекта через project manager (в отсортированном по алфавиту виде и без комментариев).

Вот интересно, я один такой, или нас таких много .

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

S>Кто как предпочитает писать: Много маленьких исходных текстов или немного, но более длинных? Какова средняя длина (хотя бы с точностью до порядка)? Аргументы в пользу того или иного подхода?


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


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


начнем с конца, самого главного.

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


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

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

Во-первых, не факт что не пригодится отдельно.

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


Ну а вопрос о размерах класса и размерах функции — отдельный, и к делу не относится.

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

ГВ>Чушь. Э... Не соответствует действительности. Основная причина — различия в работе с одним и несколькими файлами в текстовом редакторе.

И еще, потому что в каждом мелком файле надо писать одни и теже инклуды, неймспейсы и юзинги.

VladD2,

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

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

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

GZ>Что касается парсеров, то меня тоже ломает разделять его на файлы. Потенциально слишком много классов получается. Писанины много, а сложности мало.

Ну а структура бизнес системы: с бизнес объектами, логикой, формами всякими и отчетами. Например, я бы все бизнес объекты какой-либо подсистемы ("зарплата", например) запихал в один исходник, всю логику в другой (а может и в тот-же).
Меня, например, бесит в Delphi каждую форму в отдельном юните делать.

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

C>>В С++ поэтому удобно группировать схожие классы в один файл — типа
C>>allocators.h в котором лежат shared_allocator, locked_allocator,
C>>st_allocator.

VD>Ничего удобного тут нет. Искать код в 10 классах по поределению труднее чем в одном. Если классы занимают пару строк, то еще куда не шло. А для полноценных классов каждый из которых занимает по 40 и более строк такое решение приведет к тому, что на поиск конкретного метода буде уходить по куча времени.

Вообще-то, основная проблема обычно не в поиске метода, а в том что с ним делать.

VD>В С++ часто прибегают к напихиванию классов в один файл из-за банальной медленности компиляции.

Чушь. Э... Не соответствует действительности. Основная причина — различия в работе с одним и несколькими файлами в текстовом редакторе.

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

Дык. Из этого следует, как минимм то, что а) на C++ нельзя слепо переносить практики C# и б) средства навигации ещё не доросли до возможностей C++.

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

S>>Ок. Есть логический порядок следования классов в API некой подсистемы компиляции:
VD>Про папки слышал? Вот ими и отражай свою логическую структуру.

Э... не надо путать логическую и физическую структуру. Это суть две разные вещи. И прежде всего по причинам сопровождабельности не всегда удобно раскидывать сущности по файлам по правилу "одна сущность = один файл".

S>>...И начинаем судорожно лазить по каталогу, заглядывая в каждый файл, для того, чтобы выделить логические группы.
VD>Зачем? Есть дерево проекта в студии или каталоги на диске. Все что унжно находится просто по именам файлам и их пути внутри проекта.

OK. Имеем пачку частичных специализаций примерно такого вида:

// Специализируется только один метод
template<typename X, typename Y, typename Z>
void Foo<X, Y, Z, int>::bar() {...}
template<typename X, typename Y, typename Z>
void Foo<X, Y, Z, double>::bar() {...}
// etc.

Дальше что? Пуляем каждую специализацию в отдельный файл? Как назовём файлы?

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

ГВ>>Э... не надо путать логическую и физическую структуру. Это суть две разные вещи.
VD>Так соедени их в одну и не мучайся. Хотя с плюсами конечно в данном вопросе не все ОК.

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

ГВ>>И прежде всего по причинам сопровождабельности не всегда удобно раскидывать сущности по файлам по правилу "одна сущность = один файл".

VD>Озвучь причины... обсудим.

Простейший пример — вносим изменения в набор логически связанных классов. Мотаться по файлам туда-сюда, ИМХО, не так удобно, как пройтись по одному файлу, тем паче, что в той же VS2003 есть очень удобная возможность на время сколлапсировать лишние строки.

VD> Я вижу ровно обратное. Поддерживать хорошо структурированные небольшие файлы в кторых заранее известно что лежит намного проще чем шариться по файлам в поиске файлов и функций в них.

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

Зато когда классы разложены группами по файлам, очень удобно "отгонять" части проекта для того, чтобы с ними поиграться — добавить функциональность, переделать что-то и т.п. Опять таки, комментарии, если они относятся к группе классов, удобно размещать в таких файлах и использовать для автогенерирования документации.

ГВ>>OK. Имеем пачку частичных специализаций примерно такого вида:

[skip]

ГВ>>Дальше что? Пуляем каждую специализацию в отдельный файл? Как назовём файлы?
VD>Если они умещаются в одну-три строки, то можно конечно и в одном файле оставить.

Я сознательно поставил многоточия между фигурных скобок. Специализации могут быть и объёмными.

VD> Но это уже плюсовые тараканы.

Или — шарповые недоработки.

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

Про typedef-ы мы тут вроде, речи не вели. Я специально предложил специализации классов, посколкьу результат специализации — суть новый класс, и если следовать постулату "один класс — один файл", то их нужно раскидывать по вороху отдельных файлов. Если же мы вводим дополнительные оганичения, типа "если класс больше 3-х строк", то автоматически получаем понятие "логических групп", поскольку как ни крути, а куда-то такие классы всё равно класть нужно. И не факт, что специализации нужно помещать в один файл с исходным шаблоном.

Короче говоря, политика "один класс — один файл" применима далеко не всегда и не везде из-за того, что для группы файлов и одного файла отличаются:

— способы навигации в редакторах (кстати, на MSVS свет клином не сошёлся);
— способы обработки разными тулзами (сравнения, генерация документаций и т.п., вполть до makefile-ов);
— способы управления (переносы, копирования, архивирование).

Вот когда эти различия будут стёрты, вопрос отпадёт сам собой.

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

AVK>Более того — ограничение C# первой версии на размещение класса в одном файле во второй версии убрано совсем не зря.

Немного не в тему, но это ограничение снято на для удобства написания классов, а для удобства использования кодогенераторов (в том числе и form designer и ASP)

Глядя на весь этот флейм, понимаешь, как все-таки правы были авторы Java

VladD2,

> ПК> Имхо, большой интерфейс — в большинстве случаев следствие плохого дизайна.

> Как я уже говорил, бывает и так. Но бывает, что этого требует логика создаваемого ПО. Ради хохмы открой ворд, нажми Alt+F11 и погляди список членов документа ворда.

Посмотрел. Типичный пример "жирного" интерфейса. Скорее всего, обусловлен историческими или еще какими-то подобными причинами, но уж никак не может быть образцом хорошего дизайна. Начал было расписывать явные "ляпы", но решил не тратить время: там все без очков видно. Одно напихивание в этот и без того раздутый интерфейс функциональности, связанной с e-mail чего стоит... Если же это фасад (что может быть оправданием такому ужасу), то тогда и говорить не о чем: полный код будет немногим больше, чем список членов. В общем, непоказательный пример.

Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Имхо, большой интерфейс — в большинстве случаев следствие плохого дизайна.
Ну, вообще-то много места может отнимать банальный маппинг на всякие интерфейсы. Разработчики фреймворков страсть как любят декларировать всякие интерфейсы! А ты, если хочешь быть с ними соупотребляем, будешь их реализовывать. Вон, в DevExpress типичный контрол штук десять-пятнадцать интерфейсов реализует. Причем большинство из них — тривиально. Вот как раз эту часть имеет смысл выкинуть в отдельные файлы, т.к. никакой особо осмысленной логики там нет.

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

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

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

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

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

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

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

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

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

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

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

Добрый день.

Кто как предпочитает писать: Много маленьких исходных текстов или немного, но более длинных? Какова средняя длина (хотя бы с точностью до порядка)? Аргументы в пользу того или иного подхода?
Если не учитывать неудобства, связанные со спецификой языка (типа медленная компиляция и т.п.), то как бы вы хотели писать?

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

GZ>>Если файлы по одному классу. В большинстве случаев — класс-файл более удобно. Особенно в условиях VSS.

S>А не парит держать открытыми в IDE много маленьких текстов и лазить туда-сюда.
Я в VSS лазию через студию, и поэтому удобно. Сразу видишь какие файлы можно уже зачекинить, какие нет. В этом случае — большой плюс получается.
Что касается переключение между файлами, то парит. Но также парит и поиск по файлу. То есть в любом случае парит. Но у меня все таки есть предположение, что переключение между файлами меня лично меньше парит чем Ctrl-F. На Ctrl-TAB уже рука набита.

С уважением, Gleb.

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

S>Дык, по Ctrl-TAB ты же попадаешь на следующий файл, а не на тот, который тебе нужен.
Нет, на предыдущий который переключался до этого. Обычно работаешь с 2-3 файлами одновременно, и между ними с помощью Ctrl-TAB очень удобно переключаться, несмотря что открыто порядка 20.

С уважением, Gleb.

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

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

S>>Кто как предпочитает писать: Много маленьких исходных текстов или немного, но более длинных? Какова средняя длина (хотя бы с точностью до порядка)? Аргументы в пользу того или иного подхода?
S>>Если не учитывать неудобства, связанные со спецификой языка (типа медленная компиляция и т.п.), то как бы вы хотели писать?
GZ>Насчет функций. В большинстве случаев, не больше экрана. Количество строчек зависит от разрешения. Если больше то начинаю думать как рефакторнуть.
+1

GZ>Иногда построить алгоритм значительно легче в одной процедуре (большое количество последовательных действий). Тогда так и пишу. Если есть время (и хотение) то потом уже разбиваю на различные логические части.
Почти так же, но сложные алгоритмы я пишу сначала на бумаге, а там очень легко получается выделить некоторые фрагменты на отдельные подпрограммы еще перед вводом кода в редакторе

GZ>Что касается файлов, то как-то не регламентирую. Лишь бы наполнение было логически связано. Есть файлы и по 5 тысяч строк. Если файлы по одному классу. В большинстве случаев — класс-файл более удобно.
Очень похоже на мою ситуацию, только я предпочитаю не классами оперировать, а сущностями. Если сущность представляется одним классом, значит один класс на файл (вот так, например). Если больше -- то, как правило, все классы данной сущности идут в один файл (например, вот так). Хотя, если классов сильно много, то я делаю дополнительное деление.

GZ> Особенно в условиях VSS.

А мне, с svn, как-то фиолетово
Не обращаещь на такие вещи внимания.

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

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

Это вряд ли. Если нужно объединить несколько классов проще создать для них отдельную папочку, а не лепить все в один файл. Более того — ограничение C# первой версии на размещение класса в одном файле во второй версии убрано совсем не зря.

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

AVK>> Более того — ограничение C# первой версии на размещение класса в одном файле во второй версии убрано совсем не зря.

СГ>В смысле, теперь один класс можно будет размазать по нескольким файлам?

Да.

СГ>Ёёёёёёёёёёёёёёёёёё

Сам такой. Это чертовски удобно.

VladD2 wrote:

> S>Ок. Есть *логический* порядок следования классов в API некой
> подсистемы компиляции:
> Про папки слышал? Вот ими и отражай свою логическую структуру.

Не совсем удобно получается, папки повторяют "тонкую" структуру проекта
и по ним неудобно становится ходить.

> S>...И начинаем судорожно лазить по каталогу, заглядывая в каждый
> файл, для того, чтобы выделить логические группы.
> Зачем? Есть дерево проекта в студии или каталоги на диске. Все что
> унжно находится просто по именам файлам и их пути внутри проекта.

Удобно иметь два метода навигации: по логической структуре
(namespace/package и по классам) и по физической (каталоги/файлы).

В С++ поэтому удобно группировать схожие классы в один файл — типа
allocators.h в котором лежат shared_allocator, locked_allocator,
st_allocator.

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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Почему-то мне кажется, что класс, который приходится разбивать по нескольким файлам из-за размера, просит рефакторинга. Если это приходится делать из-за слабой функциональной связности, то, на мой взгляд, класс уже не просит, а требует...

Бывает по разному. Бывает, что большой файл — это следствие плохого дизайна, а бывает что следствие большого интерфейса. Например, в текстовом редакторе куча функциональности помещается во View. При этом View становится довольно большим классом чтобы по нему было не удобно лазить. Разбиение его на части дает отличный результат. Например, вот разбиение на файлы View из редактора кода:

ObjectModel\View\View.cs
ObjectModel\View\View.Caret.cs
ObjectModel\View\View.Commands.cs
ObjectModel\View\View.Commands.Edit.cs
ObjectModel\View\View.Debug.cs
ObjectModel\View\View.Designer.cs
ObjectModel\View\View.DisplayRowsCalculations.cs
ObjectModel\View\View.Dispose.cs
ObjectModel\View\View.Events.cs
ObjectModel\View\View.Keyboard.cs
ObjectModel\View\View.MouseEvents.cs
ObjectModel\View\View.Paint.cs
ObjectModel\View\View.Properties.cs
ObjectModel\View\View.Selection.cs
ObjectModel\View\View.State.cs
ObjectModel\View\View.Translate.cs

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

Рефакторинг это хорошо, но он не должен быть самоцелью.

VladD2,

> Бывает по разному. Бывает, что большой файл — это следствие плохого дизайна, а бывает что следствие большого интерфейса.

Имхо, большой интерфейс — в большинстве случаев следствие плохого дизайна.

> Рефакторинг это хорошо, но он не должен быть самоцелью.

+1

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Посмотрел. Типичный пример "жирного" интерфейса. Скорее всего, обусловлен историческими или еще какими-то подобными причинами, но уж никак не может быть образцом хорошего дизайна. Начал было расписывать явные "ляпы", но решил не тратить время: там все без очков видно. Одно напихивание в этот и без того раздутый интерфейс функциональности, связанной с e-mail чего стоит...

Можешь подобные вещи просто не брать врассчет. И без того интерфейс будет огромен.

ПК>Если же это фасад (что может быть оправданием такому ужасу), то тогда и говорить не о чем: полный код будет немногим больше, чем список членов. В общем, непоказательный пример.

Ясно. Как всегда все вокруг криворукие. А грамотный дизайн — это то что делаешь сам.

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

VD>>>Так соедени их в одну и не мучайся. Хотя с плюсами конечно в данном вопросе не все ОК.
ГВ>>Выделенное — дорога в ад. Можешь поверить. Такая широкая-широкая. Причин много, потому озвучу основную — неправомерная агрегация сущностей.
VD>Звучит красиво... Но требует расшифровки.

Классы программы образуют её логическую структуру. Файлы с исходным кодом — файловую (или "физическую") структуру.

Для чего нужны классы? Для того, чтобы структурировать представление о предметной области. Для чего нужны файлы? Для того, чтобы это представление было удобно модифицировать одному или нескольким людям. "Удобство" означает и примлемую навигацию, и трансляцию, и check-in/out и т.п.

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

Только тихо, тихо. Я в курсе, что в Java, например, такой бардак отродясь. Сути дела в общем это не меняет.

ГВ>>Простейший пример — вносим изменения в набор логически связанных классов. Мотаться по файлам туда-сюда, ИМХО, не так удобно, как пройтись по одному файлу, тем паче, что в той же VS2003 есть очень удобная возможность на время сколлапсировать лишние строки.
VD>Плохой пример. Как раз заниматься рефакторингом нескольких мелких файлов куда проще чем возиться с монстром. Основное время тратится на нахождение нужного места и анализ кода. Свертка кода вещь полезная, но у всего есть свои приделы. При привышении некоторого размера файла навигация по нему превращатся в ад.

Да, всё верно. Если не забывать про ключевой момент: "При привышении некоторого размера". И это справедливо для любых файлов. Другое ограничение можно сформулировать так: "при превышении некоторого количества файлов"... Окончание то же, что и у тебя. Разница в том, что в первом случае (n классов на один файл) второе ограничение будет нарушаться реже, чем во втором. Ты же предлагаешь модификацию 10-12 классов автоматом "превращать в ад", поскольку решарпер помогает далеко не всегда.

VD> Ну, и для рефакторинга лучшеп пользоваться средствами вроде Решарпера.

Он не всегда помогает.

VD>>> Я вижу ровно обратное. Поддерживать хорошо структурированные небольшие файлы в кторых заранее известно что лежит намного проще чем шариться по файлам в поиске файлов и функций в них.
ГВ>>Забавный пример неправомерного обобщения.
VD>Скорее очередное наклеивание ярлыков... с твоей стороны.

Чуть ниже я расшифровал, почему употребил определение "неправомерное обобщение". Странно, что ты называешь подобный термин "ярлыком".

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

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

VD>Паттерн "один класс — один файл" коенчно тоже не страхует от появления файлов-монстров, но без этого шанс получить файлы-монстры увеличивается многократно.

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

ГВ>>Зато когда классы разложены группами по файлам, очень удобно "отгонять" части проекта для того, чтобы с ними поиграться — добавить функциональность, переделать что-то и т.п. Опять таки, комментарии, если они относятся к группе классов, удобно размещать в таких файлах и использовать для автогенерирования документации.
VD>К сожалению я не знаком с техникой "отгона" (или правильнее "отгоняния"?) частей проекта. Но проблем с управлением проектом или эксперемениами я почему-то не испытываю. А вот пролистывание огромных файлов в поисках нужной функции и чтение коментариев только чтобы найти нужный участок кода меня не водушивляет.

Копируем X файлов из каталогов проекта в отдельный каталог и начинаем "баловацца вафсю"! Если что-то дельное получается — копируем файлы обратно.

ГВ>>Я сознательно поставил многоточия между фигурных скобок. Специализации могут быть и объёмными.
VD>Тогда засовывать их в один файл не рзумно.

Угу. И получить примерно... эдак... с полтора десятка новых файлов на совершенно ровном месте, только потому, что паттерн "ОФОК" так повелел?

ГВ>>Про typedef-ы мы тут вроде, речи не вели. Я специально предложил специализации классов, посколкьу результат специализации — суть новый класс,
VD>Вообще-то специализации новых классов не порождают.

Согласен, поскольку действительно, специализация (частичная) — ещё не класс. Но тем не менее, в контексте обсуждения организации исходного кода вполне правомерно утверждение "специализация шаблона = класс", равно как и "шаблон = класс". Просто я полагал это по умолчанию.

VD>Или тогда нужно говорить, о том, что любое применение шаблона с новым типом параметра порождает новый класс. (что мягко говоря натянуто).

Ну, вообще-то, мы об организации исходников говорим. А в этом контексте, повторюсь, что классы, что структуры, что шаблоны, что специализации (полные и частичные) шаблонов — одно и то же.

ГВ>> и если следовать постулату "один класс — один файл", то их нужно раскидывать по вороху отдельных файлов. Если же мы вводим дополнительные оганичения, типа "если класс больше 3-х строк", то автоматически получаем понятие "логических групп", поскольку как ни крути, а куда-то такие классы всё равно класть нужно. И не факт, что специализации нужно помещать в один файл с исходным шаблоном.
VD>Мне кажется, что выделенное жирным довольно разумно.

Да, совершенно верно. Но только в некоторых случаях. В некоторых — нет. Например, библиотечный шаблон T может специализироваться классом X, определяемым в некотором модуле Z системы. Если мы положим специализацию T<X> в ту же единицу трансляции, что и сам T, то туда же придётся затолкнуть и сам класс X и ещё неизвестно что из модуля Z. В итоге получим концентрацию всякого барахла в библиотечном модуле. Кашу, короче говоря, получим. Так что, рецепт работает не всегда. Но вот специализации фундаментальными и какими-то well-known типами как правило вполне можно положить вместе с библиотечным шаблоном.

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

Согласен, но это означает, что паттерн "ОФОК" не всегда работоспособен. Как минимум, для C++.

VD>И уж точно это не является разумным оправданием для запихивания в один файл груды полноценных классов.

Depends on, как я это только что показал. Потом, с чего ты решил, что шаблон = неполноценный класс? Давай уж определимся с терминами. Пока что, "полноценный класс" в твоей интерпретации выглядит как чудовище-монстр аццких габаритофф, который и в один-то файл положить страшно, тогда как я уверен, что за подобные классы нужно отлучать от программирования. Это, кстати, можешь считать комментарием к твоему исходному тезису о "классности программистов".

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

Здесь не в "плюсах" проблема, а в размерах и количестве классов. Даже на Java применение ОФОК нехило треплет нервы время от времени — когда нужно мотаться по груде файлов вместо того, чтобы расставить закладки по одному файлу и спокойно по нему прыгать. То есть, абсолютизация этой стратегии имеет и негативные стороны.

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

Опять в одной куче розы и паровозы. А почему? А потому что на "зы"!

С одной стороны — да, разбиение проекта на отдельные файлы упрощает жизнь (обрати внимание на формулировку), а вот максималистическое применение ОФОК как раз жизнь усложнит.

ГВ>>- способы обработки разными тулзами (сравнения, генерация документаций и т.п., вполть до makefile-ов);
VD>Если "тулзы" не кривые, то никакой необходимости засовывать все в один файл нет. Мэйки вообще пережиток прошлого (хотя тоже не ясно как он может повлиять на организацию файлов).

Хорошо, скажем по-другому. Если мы что-то пытаемся оттранслировать в пакетном режиме, то раскидывая классы по отдельным файлам в соответствии с паттерном ОФОК существенно чаще будем заставлять сами себя править пакетное задание. Само по себе это ни на что сильно не влияет, но факт отличий остаётся.

ГВ>>- способы управления (переносы, копирования, архивирование).
VD>Ясно. Мы живем в разных мирах. Я пользуюсь системой контроля вресий вроде SVN-а для управления исходниками. MSBuild-ом для сборки проектов. И студией 2005 или на худой конец 2003 + решарпер, чтобы редактировать код. Плюс плюсы для меня в прошлом и их тараканы меня больше не волнуют.

Мда. Только ты тогда не забывай проставлять теги ".Net/C# world only on/off", а то в заблуждение вводишь. Тогда бы я и не спорил.

ГВ>>Вот когда эти различия будут стёрты, вопрос отпадёт сам собой.
VD>Все это ты сам для себя придумл чтобы опрадать свою точку зрения. Ни одна из перечисленных тобой проблем меня не трогает.

И эти люди запрещают мне ков... тьфу, обвиняют меня в демагогии.

VD>А вот качество структурированности кода меня трогает очень сильно. Я люблю программировать быстро. И ненавижу все что этому мешает. Засовывание кучи классов в один файл мешает этому в первую очередь.

Ну вот, оказывается, где ключи-то к мастерству и быстрому программированию! Раскидать каждый класс в отдельный файл и — полный вперёд! Делов-то!

Самому не смешно? Или это ты в приёмах составления рекламных слоганов практикуешься?

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

СГ>>В смысле, теперь один класс можно будет размазать по нескольким файлам?
VD>Да.
СГ>>Ёёёёёёёёёёёёёёёёёё
VD>Сам такой. Это чертовски удобно.

Чертовски удобно, это как? В смысле, удобно для чертей? Да я не сомневаюсь, что это воистину дьявольская штукенция. Как бы только сам черт теперь там ногу не свернул....

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

ГВ>Классы программы образуют её логическую структуру. Файлы с исходным кодом — файловую (или "физическую") структуру.

ГВ>Для чего нужны классы? Для того, чтобы структурировать представление о предметной области.
Бесспорно.
ГВ>Для чего нужны файлы? Для того, чтобы это представление было удобно модифицировать одному или нескольким людям. "Удобство" означает и примлемую навигацию, и трансляцию, и check-in/out и т.п.
Согласен. Но "удобство" понятие субъективное. Лично мне удобнее когда файлы не большие.
А что касается check-in/check-out то нефиг пользоваться дурными версионниками типа VSS.

ГВ>Так вот, попытка привязать файловую структуру к логической по принципу 1:1 есть ни что иное, как связывание (агрегация) двух сущностей в одну: имени класса и имени файла в некое общее имя "классофайла". Такое связывание неправомерно, поскольку нарушается требование удобства доступа.
Если требования к структуре классов вещь довольно формальная то трубования к удобству субъективны.
Например в моей практике был случай когда мне пришлось разделить один класс на несколько файлов. Ибой искать конци в файле в несколько тысяч строк мне очень не понравилось.
Только не надо про кривизну дизайна. Нужно было реализовать в одном классе несколько здоровых COM интерфейсов которые придумал не я.

VD>> Ну, и для рефакторинга лучшеп пользоваться средствами вроде Решарпера.
ГВ>Он не всегда помогает.
Например?

ЗЫ Рекомендую завязывать с аффтарским сленгом. Здесь за это банят.

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

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

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

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

WolfHound wrote:

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

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

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

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

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

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

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

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

Ну, это уже зависит не только и не столько от размера, сколько от других факторов.

VladD2 wrote:

> C>Есть вкладка "ClassView" — в ней класс точно так же выбрать можно.
> Ты не поверишь, но при большом количестве файлов ClassView тоже
> доступен. Вот только почему-то я не часто им пользуюсь. Почему? Да
> потому, что там просто свалка из классов. Даже фильтраций в 2005-ой
> студии дает слишком много вариантов в больших проектах. А вот в
> недерве проекта разобраться элементарно, так как *это дерево*. Все
> файлы структурированы каталогами и на их поиск почти не тратится вренмени.

Просто можно изначально ориентироваться на "чистый" ClassView — тогда
все будет нормально.

> C>У меня в солюшене 20 проектов, кода около мегабайта. Файлов порядка 100.
> C>Поиск определения "глазками" — не напрягает абсолютно, в каждом файле
> C>1-3 класса. Самое большее — 20 (классы узлов AST-дерева).
> Вауууу!!!
> Это выходит в среднем по 5 файлов на проект? Если не ошибаюсь ты на
> С++ пишешь? Значит из этих 5 файлов еще и инклюды есть?

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

> Да и 20 проектво это тоже явный перебор.

А что делать... Проекты действительно логически отдельные.

> Боюсь, чтодучи построенным по твоим принципам он просто развалился бы.

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

>>> C>VisualAssist справляется.
>>> Помню я как он справлялся. Вместо АТЛ-а показывал МФЦ. А на более
>>> менее сложных шаблонах врал безбожно.
> C>Он с тех пор улучшился.
> Но не думаю, что он дошел до качества компилятора. А для безошибочной
> работы нужно именно это.

А 100% безошибочность от Vassist'а и не нужна (в отличие от
компилятора). Вполне достаточна 95%, современный ассист как раз примерно
на этом уровне и работает.

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

Здравствуйте, Павел Кузнецов, Вы писали:

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

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

В общем, будем радоваться хотя бы тому, что мы не спорим о том нужно ли пихать в один файл 20 пухлых файлов или нет.

ПК>Правильно ли я тебя понял, что ты считаешь приведенный интерфейс примером грамотного дизайна?

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

Мой посыл был в том, что всегда найдется задача требующая огромного (ну, относительно) класса. Опять таки всегда можно извернуться и попытаться обойти это требование. Но проще иметь банальные средства разбиения на файлы большой сущьности. Это не частое явление, но все же иногда от этого не уйти.

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

Зачем тогда вообще разбивать на файлы?

VladD2 wrote:

> C>namespace val_nodes;
> C>namespace literal_nodes;
> C>namespace bindable_nodes;
> C>...
> И пользователь твоих классов будет вынужден ссылаться на все эти
> сокращения только потому что тебе было влом разнести классы по файлам?

Нет, с неймспейсами код выглядит более читабельным.

> C>Компилируется в набор файлов весом 5Мб
> Во-во. А фрэймворк в сжатом вид 20 мег. Прикинь насколько у него
> длинее...



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

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

E>А что
E>

E>grep -REl "(class|struct)[[[:space:]]+(\w+\W+)*some_class_name" . | grep ".hpp$"
E>

E>уже отменили?
E>)

Давно. А ты не занал?

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

S>Здравствуйте, eao197, Вы писали:
E>>А что
E>>

E>>grep -REl "(class|struct)[[[:space:]]+(\w+\W+)*some_class_name" . | grep ".hpp$"
E>>

E>>уже отменили?
E>>)
S>Не смеши мои тапочки. Современные библиотеки очень любят декларировать классы при помощи макросов.

Покажи мне, плиз, такие фокусы в библиотеках Qt, ACE и Boost.

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

S>Добрый день.

S>Кто как предпочитает писать: Много маленьких исходных текстов или немного, но более длинных? Какова средняя длина (хотя бы с точностью до порядка)? Аргументы в пользу того или иного подхода?
S>Если не учитывать неудобства, связанные со спецификой языка (типа медленная компиляция и т.п.), то как бы вы хотели писать?

Зависит от задач. Например, я пишу (на С++) semantic analyser для некоторого языка. Каждый semantic check суть класс, но т.к. их дофига (порядка 700), то отводить под каждый класс отдельный файл неразумно. Поэтому я группирую классы по файлам исходя из некотрых принципов. Средняя длина файла 1000 — 1500 строк.

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

GZ>Есть файлы и по 5 тысяч строк.

У меня примерно так и получается.

GZ>Если файлы по одному классу. В большинстве случаев — класс-файл более удобно. Особенно в условиях VSS.

А не парит держать открытыми в IDE много маленьких текстов и лазить туда-сюда.

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

GZ>Что касается переключение между файлами, то парит. Но также парит и поиск по файлу. То есть в любом случае парит. Но у меня все таки есть предположение, что переключение между файлами меня лично меньше парит чем Ctrl-F. На Ctrl-TAB уже рука набита.

Дык, по Ctrl-TAB ты же попадаешь на следующий файл, а не на тот, который тебе нужен.

Здравствуйте, stalcer, Вы писали:
S>- Я использую имя исходного текста для логического разбиения групп классов (compiler.h, parseTree.h и т.п.).
Что касается парсеров, то меня тоже ломает разделять его на файлы. Потенциально слишком много классов получается. Писанины много, а сложности мало.

С уважением, Gleb.

Здравствуйте, stalcer

1) Если для описания типа "А" нужен тип "Б", а для описания типа "Б" нужен тип "А" (кроссылка, цикл), то типы "А" и "Б" должны быть описаны в одном модуле. Аналогично для случая нескольких типов, когда они циклически ссылаются друг на друга (завязаны друг на друге, "круговая порука", граф связей между ними имеет циклы).

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

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

> 1) Если для описания типа "А" нужен тип "Б", а для описания типа "Б"
> нужен тип "А" (кроссылка, цикл), то типы "А" и "Б" должны быть описаны
> в одном модуле. Аналогично для случая нескольких типов, когда они
> циклически ссылаются друг на друга (завязаны друг на друге, "круговая
> порука", граф связей между ними имеет циклы).

А что, в Обероне нет опережающих описаний (forward declarations)?

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

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

СГ>1) Если для описания типа "А" нужен тип "Б", а для описания типа "Б" нужен тип "А" (кроссылка, цикл), то типы "А" и "Б" должны быть описаны в одном модуле. Аналогично для случая нескольких типов, когда они циклически ссылаются друг на друга (завязаны друг на друге, "круговая порука", граф связей между ними имеет циклы).

Зависит от языка. В моем случае такой проблемы вообще нет.

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

S>Добрый день.

S>Кто как предпочитает писать: Много маленьких исходных текстов или немного, но более длинных? Какова средняя длина (хотя бы с точностью до порядка)? Аргументы в пользу того или иного подхода?

Как правило, у меня исходники маленького размера. Общее правило — 1 класс = 1 файл. Средняя длина файла — 100-200 строк. Есит конечно исключения в видк файла в 1000-2000 строк, но это редкость.

Для выбора файла в редактор в проектную модель не смотрю никогда. Всегда ищу конкретный класс по имени, или по навигации из его usage'а

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

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

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

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

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

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

S>Зависит от языка. В моем случае такой проблемы вообще нет.

Я что-то не понял, какой проблемы?

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

C>А что, в Обероне нет опережающих описаний (forward declarations)?

Не понимаю, при чем тут Оберон, но если Вас это так сильно интересует, то для описания типов циклически ссылающихся друг на друга предварительные объявления не требуются:

A = POINTER TO RECORD
      b: B
    END;

B = POINTER TO RECORD
      a: A
    END;

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

AVK> Более того — ограничение C# первой версии на размещение класса в одном файле во второй версии убрано совсем не зря.

В смысле, теперь один класс можно будет размазать по нескольким файлам? Ёёёёёёёёёёёёёёёёёё

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

Ок. Есть логический порядок следования классов в API некой подсистемы компиляции:

namespace compiler 
{
    public class CompileException {}
    public class SomeSpecificException : CompileException {}
    public class OtherSpecificException : CompileException {}

    public interface ICompilationModuleCallbacks {}
    public interface ICompilationModuleLoader {}
    public interface ICompilationModuleManager {}
    
    public class TypeDeclContext {}
    public class MemberDeclContext {}
    public class ExpressionCompContext {}
    public class BodyCompContext {}
    
    public class Compiler {}
}

Делаем для каждого класса отдельный файл и видим следующее:

BodyCompContext.cs
CompileException.cs
Compiler.cs
ExpressionCompContext.cs
ICompilationModuleCallbacks.cs
ICompilationModuleLoader.cs
ICompilationModuleManager.cs
MemberDeclContext.cs
OtherSpecificException.cs
SomeSpecificException.cs
TypeDeclContext.cs

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

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

СГ>Я что-то не понял, какой проблемы?

Необходимости объявлять mutual-depended классы в одном исходнике.

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

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

СГ>>Я что-то не понял, какой проблемы?

S>Необходимости объявлять mutual-depended классы в одном исходнике.

Ну а в моем сообщении говорилось не об исходниках, а о модулях:

...то типы "А" и "Б" должны быть описаны в одном модуле....

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

СГ>Ну а в моем сообщении говорилось не об исходниках, а о модулях:
СГ>

СГ>...то типы "А" и "Б" должны быть описаны в одном модуле....

Опять же, зависит от языка. В моем DSL и это необязательно .

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

> C>А что, в Обероне нет опережающих описаний (forward declarations)?
> Не понимаю, при чем тут Оберон, но если Вас это так сильно интересует,
> то для описания типов циклически ссылающихся друг на друга
> предварительные объявления не требуются:
>
>A = POINTER TO RECORD
> b: B
> END;
>
>B = POINTER TO RECORD
> a: A
> END;
>
Это в одном файле. В С++ я могу делать так:

class A;
boost::shared_ptr<A> A_ptr;
struct B
{
    A_ptr field;
};

При этом я могу структуру B использовать без всякого знания о
внутренностях класса A (кроме знания о самом его существовании). При
этом этот класс может быть определен в любой единице компиляции.

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

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

X>Немного не в тему, но это ограничение снято на для удобства написания классов, а для удобства использования кодогенераторов (в том числе и form designer и ASP)

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

А что до дизайнеров, то они то как раз могут и в один и тот же файл писать.

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

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

S>Ок. Есть логический порядок следования классов в API некой подсистемы компиляции:

Про папки слышал? Вот ими и отражай свою логическую структуру.

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

Зачем? Есть дерево проекта в студии или каталоги на диске. Все что унжно находится просто по именам файлам и их пути внутри проекта.

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

C>VladD2 wrote:

>> S>Ок. Есть *логический* порядок следования классов в API некой
>> подсистемы компиляции:
>> Про папки слышал? Вот ими и отражай свою логическую структуру.

C>Не совсем удобно получается, папки повторяют "тонкую" структуру проекта
C>и по ним неудобно становится ходить.

Зависит от разумности формирования проекта. Что такое "тонкая структура" я не знаю. Если интересно могу привести структуры проектов с которыми я работаю.

C>Удобно иметь два метода навигации: по логической структуре
C>(namespace/package и по классам) и по физической (каталоги/файлы).

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

C>В С++ поэтому удобно группировать схожие классы в один файл — типа
C>allocators.h в котором лежат shared_allocator, locked_allocator,
C>st_allocator.

Ничего удобного тут нет. Искать код в 10 классах по поределению труднее чем в одном. Если классы занимают пару строк, то еще куда не шло. А для полноценных классов каждый из которых занимает по 40 и более строк такое решение приведет к тому, что на поиск конкретного метода буде уходить по куча времени. В С++ часто прибегают к напихиванию классов в один файл из-за банальной медленности компиляции. А уж говорить серьезно о навигации по логической структуре большого и сложного С++-проекта вовсе не приходится. Все виденные мной средства навигации обычно ломаются уже на средних проектах. Этот язык банально слишком сложен для разбора в рельном времени.

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

ГВ>Э... не надо путать логическую и физическую структуру. Это суть две разные вещи.

Так соедени их в одну и не мучайся. Хотя с плюсами конечно в данном вопросе не все ОК.

ГВ>И прежде всего по причинам сопровождабельности не всегда удобно раскидывать сущности по файлам по правилу "одна сущность = один файл".

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

ГВ>OK. Имеем пачку частичных специализаций примерно такого вида:

ГВ>

ГВ>// Специализируется только один метод
ГВ>template<typename X, typename Y, typename Z>
ГВ>void Foo<X, Y, Z, int>::bar() {...}
ГВ>template<typename X, typename Y, typename Z>
ГВ>void Foo<X, Y, Z, double>::bar() {...}
ГВ>// etc.
ГВ>

ГВ>Дальше что? Пуляем каждую специализацию в отдельный файл? Как назовём файлы?

Если они умещаются в одну-три строки, то можно конечно и в одном файле оставить. Но это уже плюсовые тараканы. В Шарпе тоже есть одно исключение — делегаты. Они описываются в одну строку и конечно городить из-за делегата одтельный файл не разумно.

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

VD>>Так соедени их в одну и не мучайся. Хотя с плюсами конечно в данном вопросе не все ОК.

ГВ>Выделенное — дорога в ад. Можешь поверить. Такая широкая-широкая. Причин много, потому озвучу основную — неправомерная агрегация сущностей.

Звучит красиво... Но требует расшифровки.

ГВ>Простейший пример — вносим изменения в набор логически связанных классов. Мотаться по файлам туда-сюда, ИМХО, не так удобно, как пройтись по одному файлу, тем паче, что в той же VS2003 есть очень удобная возможность на время сколлапсировать лишние строки.

Плохой пример. Как раз заниматься рефакторингом нескольких мелких файлов куда проще чем возиться с монстром. Основное время тратится на нахождение нужного места и анализ кода. Свертка кода вещь полезная, но у всего есть свои приделы. При привышении некоторого размера файла навигация по нему превращатся в ад.

Ну, и для рефакторинга лучшеп пользоваться средствами вроде Решарпера.

VD>> Я вижу ровно обратное. Поддерживать хорошо структурированные небольшие файлы в кторых заранее известно что лежит намного проще чем шариться по файлам в поиске файлов и функций в них.

ГВ>Забавный пример неправомерного обобщения.

Скорее очередное наклеивание ярлыков... с твоей стороны.

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

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

ГВ> Эх, демагогия...

Да, уж любиш ты к ней прибегать. Тут не поспоришь.

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

К сожалению я не знаком с техникой "отгона" (или правильнее "отгоняния"?) частей проекта. Но проблем с управлением проектом или эксперемениами я почему-то не испытываю. А вот пролистывание огромных файлов в поисках нужной функции и чтение коментариев только чтобы найти нужный участок кода меня не водушивляет.

ГВ>Я сознательно поставил многоточия между фигурных скобок. Специализации могут быть и объёмными.

Тогда засовывать их в один файл не рзумно.

VD>> Но это уже плюсовые тараканы.

ГВ>Или — шарповые недоработки.

Тебе виднее.

ГВ>Про typedef-ы мы тут вроде, речи не вели. Я специально предложил специализации классов, посколкьу результат специализации — суть новый класс,

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

ГВ> и если следовать постулату "один класс — один файл", то их нужно раскидывать по вороху отдельных файлов. Если же мы вводим дополнительные оганичения, типа "если класс больше 3-х строк", то автоматически получаем понятие "логических групп", поскольку как ни крути, а куда-то такие классы всё равно класть нужно. И не факт, что специализации нужно помещать в один файл с исходным шаблоном.

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

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

ГВ>Короче говоря, политика "один класс — один файл" применима далеко не всегда и не везде из-за того, что для группы файлов и одного файла отличаются:

ГВ>- способы навигации в редакторах (кстати, на MSVS свет клином не сошёлся);
Согласен. Есть еще такие хиты как Инея и т.п.

ГВ>- способы обработки разными тулзами (сравнения, генерация документаций и т.п., вполть до makefile-ов);

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

ГВ>- способы управления (переносы, копирования, архивирование).

Ясно. Мы живем в разных мирах. Я пользуюсь системой контроля вресий вроде SVN-а для управления исходниками. MSBuild-ом для сборки проектов. И студией 2005 или на худой конец 2003 + решарпер, чтобы редактировать код. Плюс плюсы для меня в прошлом и их тараканы меня больше не волнуют.

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

Все это ты сам для себя придумл чтобы опрадать свою точку зрения. Ни одна из перечисленных тобой проблем меня не трогает. А вот качество структурированности кода меня трогает очень сильно. Я люблю программировать быстро. И ненавижу все что этому мешает. Засовывание кучи классов в один файл мешает этому в первую очередь.

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

ГВ>Вообще-то, основная проблема обычно не в поиске метода, а в том что с ним делать.

Ну, у каждого свои проблемы.

VD>>В С++ часто прибегают к напихиванию классов в один файл из-за банальной медленности компиляции.

ГВ>Чушь. Э... Не соответствует действительности.

Ну, с такими аргументами не поспоришь.

ГВ> Основная причина — различия в работе с одним и несколькими файлами в текстовом редакторе.

И что прыганье по туче мест в одном файле проще чем выбрать в дереве проекта нужный файл-класс?

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

ГВ>Дык. Из этого следует, как минимм то, что а) на C++ нельзя слепо переносить практики C# и б) средства навигации ещё не доросли до возможностей C++.


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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Имхо, большой интерфейс — в большинстве случаев следствие плохого дизайна.

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

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

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

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

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

VD>>>А уж говорить серьезно о навигации по логической структуре большого и сложного С++-проекта вовсе не приходится. Все виденные мной средства навигации обычно ломаются уже на средних проектах. Этот язык банально слишком сложен для разбора в рельном времени.
ГВ>>Дык. Из этого следует, как минимм то, что а) на C++ нельзя слепо переносить практики C# и б) средства навигации ещё не доросли до возможностей C++.
VD>Нет. Из этого следует, что для С++ (если бы не тормоза при компиляции и проблему необходимости предварительной декларации) в первую очередь полезно разносить классы по отдельным файлам.

А кто спорит с полезностью разнесения классов по файлам вообще? Я как раз оспариваю постулат, что "один класс = один файл".

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

Ну это-то подразумевается тобой почти в каждом посте в "философии", я уж даже удивляться перестал. Другое дело, что основания для такого твоего вывода выглядят всё более зыбкими...

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

ПК>>Если же это фасад (что может быть оправданием такому ужасу), то тогда и говорить не о чем: полный код будет немногим больше, чем список членов. В общем, непоказательный пример.

VD>Ясно. Как всегда все вокруг криворукие. А грамотный дизайн — это то что делаешь сам.

Просто не стоит принимать структуру интерфейса за внутреннюю структуру программы. Это, извини меня, азы.

VladD2 wrote:

> C>Не совсем удобно получается, папки повторяют "тонкую" структуру проекта
> C>и по ним неудобно становится ходить.
> Зависит от разумности формирования проекта. Что такое "тонкая
> структура" я не знаю. Если интересно могу привести структуры проектов
> с которыми я работаю.

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

> C>Удобно иметь два метода навигации: по логической структуре
> C>(namespace/package и по классам) и по физической (каталоги/файлы).
> Логической навигации никто не отменял. Вот только при хорошей
> организации проекта обычно проще просто ткнуть в нужный файл (если
> конечно ты не стоишь на идентификаторе по которму можно прыгнуть на
> его определение).

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

> C>В С++ поэтому удобно группировать схожие классы в один файл — типа
> C>allocators.h в котором лежат shared_allocator, locked_allocator,
> C>st_allocator.
> Ничего удобного тут нет. Искать код в 10 классах по поределению
> труднее чем в одном. Если классы занимают пару строк, то еще куда не
> шло. А для полноценных классов каждый из которых занимает по 40 и
> более строк такое решение приведет к тому, что на поиск конкретного
> метода буде уходить по куча времени.

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

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

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

VisualAssist справляется. Не в 100% случаях (сбоит пару раз в час), но
вполне нормально. Стандартный "Go to definition" тоже работает нормально.

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

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

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

VD>Про папки слышал? Вот ими и отражай свою логическую структуру.

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

Во-вторых, возмем первую группу — ексепшены:

public class CompileException {}
public class SomeSpecificException : CompileException {}
public class OtherSpecificException : CompileException {}

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

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

E>Глядя на весь этот флейм, понимаешь, как все-таки правы были авторы Java

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

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

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

C>Это в одном файле. В С++ я могу делать так:

class A;
boost::shared_ptr<A> A_ptr;
struct B
{
    A_ptr field;
};

C>При этом я могу структуру B использовать без всякого знания о
C>внутренностях класса A (кроме знания о самом его существовании). При
C>этом этот класс может быть определен в любой единице компиляции.

1) Вообще-то, тут используется указатель на класс А, а не он сам.
2) Единица компиляции — слишком громко сказано, тут это — в смысле компилируется в объектный фал, который сам по себе ничего не представляет.

А слабо использовать сам класс, а не указатель на него?
А слабо скомпилировать в динамически загружаемый исполняемый модуль (DLL)?

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

СГ>>

СГ>>...то типы "А" и "Б" должны быть описаны в одном модуле....

S>Опять же, зависит от языка. В моем DSL и это необязательно .

Значит он не модульный.

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

СГ>Значит он не модульный.

Он позволяет путем одновременной компиляции нескольких модулей делать циклические зависимости между ними. В результате компиляции все равно получается несколько модулей.

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

В Java же тоже самое. Классы (эээ, типа маленькие модули компиляции) могут ссылаться друг на друга как угодно.

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

> C>При этом я могу структуру B использовать без всякого знания о
> C>внутренностях класса A (кроме знания о самом его существовании). При
> C>этом этот класс может быть определен в любой единице компиляции.
> 1) Вообще-то, тут используется указатель на класс А, а не он сам.
> 2) Единица компиляции — слишком громко сказано, тут это — в смысле
> компилируется в объектный фал, который сам по себе ничего не представляет.

То есть "не представляет"?

> А слабо использовать сам класс, а не указатель на него?

Да запросто:

class A;
class B
{
    A* field;
    void method1();
};
class A
{
    B *field;
    void method2();
};

void A::method1()
{
    field=new B();
}

> А слабо скомпилировать в динамически загружаемый исполняемый модуль (DLL)?

Не слабо. См. boost.plugin — динамическая подгрузка плугинов на С++.

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

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

>> А слабо использовать сам класс, а не указатель на него?

C>Да запросто:
C>

C>class A;
C>class B
C>{
C>    A* field;
C>    void method1();
C>};
C>class A
C>{
C>    B *field;
C>    void method2();
C>};

C>void A::method1()
C>{
C>    field=new B();
C>}
C>

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

>> А слабо скомпилировать в динамически загружаемый исполняемый модуль (DLL)?

C>Не слабо. См. boost.plugin — динамическая подгрузка плугинов на С++.

Еще раз ёёёооууу!!!! Вооще-то, ни кто не может скомпилировать в исполняемый модуль то что он сам не знает.
Нельзя получить исполняемый модуль имея всего-лишь такой исходный код:

  class A;

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

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

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

Так я и говорю не модульный. А то что Java классы — не модули и так известно. Те сущности, которые Вы называете словом "модуль", нуждаются в другом названии. Придумайте другое слово. Сипульки — например, а?

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

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

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

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

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

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

Сергей Губанов 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 класс. Если так мелко делать папки, то... . Это во-первых.

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

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

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

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)

Здравствуйте, 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)

WolfHound wrote:

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



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

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

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

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

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

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

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

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

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

Кстати, сказать, в Open Source BlackBox модуль выгружать можно, за исключением случая когда он импортирован другим модулем (сначала надо выгрузить тот — и так по очереди от листьев к корню). А что до хуков (адресов процедур которых больше нет) — глюкаются они конечно со страшной силой, но особого вреда системе не причиняют — там поставлены системные ловушки (что-то вроде catch-ей). Например, если выгрузить модуль в котором был описан объект View, который отображался, то вместо рисунка этого View появится сеточка — дескать объект неожиданно сдох под воздействием непреодолимой силы.

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

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

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

Поговорим про элементарный COM. Он автоматически выгружает модули независимо от языка. Потому, открытия Америки в этом нет.

С уважением, Gleb.

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

Для С#.
Не делать. Что касается конкретной работы, то Studio не очень помогает при навигации со своими namespace. Даже скорее мешается. Важнее и достаточно само понятие сборки и классов. Смысла в namespace больше чем как разрешения конфликтов имен, я не вижу. Поэтому у меня редко в сборке более 1 namespace.

Для С++
Тут вообще всегда обходился одним namespace или без оного. И как-то никогда более не требовалось. Не попадал на такие ситуации, и по старинке уникальность определялась только именем класса.

С уважением, Gleb.

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

VD>Скажу крамольную фразу. Размер отдельных исходных файлов и количество типов в одном файле обратно пропорционален классу программиста.

Да!!!

А уж для языка С++ это категорически так.
Причем должна быть известна функция ИмяФайла=F(ИмяТипа).

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

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

S>>Кто как предпочитает писать: Много маленьких исходных текстов или немного, но более длинных? Какова средняя длина (хотя бы с точностью до порядка)? Аргументы в пользу того или иного подхода?


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


X>Разбиение на файлы диктуется
X>- удобством
X>- логической зависмостью классов
X>- физическим размером кода
X>- нежеланием иметь в одном заголовочном файле классы, применяемые независимо
X>- размером команды и организаией работы в команде

X>Далее. Иногда, если классики маленькие разбрасывать вспомогательные классы по файлам не хочется.
см. меня. Я уже об этом писал, особенно по поводу того, что классы имеют свойства разрастаться. Потом не очень-то удобно их разделять на файлы, да и названия файлов тогда хуже согласуются.

X>С другой стороны если файлы большие, то лучше разложить по файлам.

X>Во-первых, не факт что не пригодится отдельно.

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


X>Ну а вопрос о размерах класса и размерах функции — отдельный, и к делу не относится.

Как раз относится.

В общем, по моему Xentrax написал резюме того, что тут говорилось при обсуждении.

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

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

Ты не поверишь, но при большом количестве файлов ClassView тоже доступен. Вот только почему-то я не часто им пользуюсь. Почему? Да потому, что там просто свалка из классов. Даже фильтраций в 2005-ой студии дает слишком много вариантов в больших проектах. А вот в недерве проекта разобраться элементарно, так как это дерево. Все файлы структурированы каталогами и на их поиск почти не тратится вренмени.

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

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


Вауууу!!!
Это выходит в среднем по 5 файлов на проект? Если не ошибаюсь ты на С++ пишешь? Значит из этих 5 файлов еще и инклюды есть?

Да и 20 проектво это тоже явный перебор.

Для сравнения могу привести характиристики R#-а.

Количество проектов — 13. Из них 1 проекты CocoR (к R#-у отношения не имеет) и 4 проекта генерирующие код (т.е. не С#-ные).
Количество .cs-файлов — 673. (кстати, это C#-файлы, так что на С++ их объем заметно увеличился бы).
Объем в мегабайтах — 2.7.
Количество АСТ-классов 187.

Боюсь, чтодучи построенным по твоим принципам он просто развалился бы.

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

Но не думаю, что он дошел до качества компилятора. А для безошибочной работы нужно именно это.

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

C>WolfHound wrote:

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

C>namespace спасают.

Ты же вроде с АСТ возишся. Так? Тогда кому как не тебе знать, о том что бывают случаи когда простраства имен оказываются ну очень большими. В AST R#-а более 180 классов. Смотреть на них как на плоских список занятие не из приятных.

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

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

Щаз он тебе расскажет о размере фрэймворка.

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

ГВ>>Классы программы образуют её логическую структуру. Файлы с исходным кодом — файловую (или "физическую") структуру.
ГВ>>Для чего нужны классы? Для того, чтобы структурировать представление о предметной области.
WH>Бесспорно.
ГВ>>Для чего нужны файлы? Для того, чтобы это представление было удобно модифицировать одному или нескольким людям. "Удобство" означает и примлемую навигацию, и трансляцию, и check-in/out и т.п.
WH>Согласен. Но "удобство" понятие субъективное.
+1 В том-то и дело.

WH>Например в моей практике был случай когда мне пришлось разделить один класс на несколько файлов. Ибой искать конци в файле в несколько тысяч строк мне очень не понравилось.
WH>Только не надо про кривизну дизайна. Нужно было реализовать в одном классе несколько здоровых COM интерфейсов которые придумал не я.
Дык к таким классам (aka API, aka Facade) мои рассуждения не особо и относятся.

VD>>> Ну, и для рефакторинга лучшеп пользоваться средствами вроде Решарпера.
ГВ>>Он не всегда помогает.
WH>Например?
Например, если меняется протокол взаимодействия объектов.

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

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

Я и не спорю. Я предполагаю возможные трактовки.

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

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

[...]
ГВ>> я уж даже удивляться перестал.
VD>А ты удивлялся?
Нет, аккурат с 2002 года.

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

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

Еще одно вдогонок. FxCop жутко ругается если в namespace мало классов.

С уважением, Gleb.

VladD2 wrote:

> C>namespace спасают.
> Ты же вроде с АСТ возишся. Так? Тогда кому как не тебе знать, о том
> что бывают случаи когда простраства имен оказываются ну очень
> большими. В AST R#-а более 180 классов. Смотреть на них как на плоских
> список занятие не из приятных.

namespace val_nodes;
namespace literal_nodes;
namespace bindable_nodes;
...

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

Компилируется в набор файлов весом 5Мб

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

VladD2,

> ПК> Начал было расписывать явные "ляпы", но решил не тратить время: там все без очков видно. Одно напихивание в этот и без того раздутый интерфейс функциональности, связанной с e-mail чего стоит...

> Можешь подобные вещи просто не брать врассчет. И без того интерфейс будет огромен.

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

> ПК> Если же это фасад (что может быть оправданием такому ужасу), то тогда и говорить не о чем: полный код будет немногим больше, чем список членов. В общем, непоказательный пример.

> Ясно. Как всегда все вокруг криворукие. А грамотный дизайн — это то что делаешь сам.

Правильно ли я тебя понял, что ты считаешь приведенный интерфейс примером грамотного дизайна?

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

ГВ>>>А кто спорит с полезностью разнесения классов по файлам вообще?
VD>>Мне показалось, что ты. Я ошибся?
ГВ>Да, ошибся.

Тогда нам не очем спорить. Предлагаю заройтись.

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

C>namespace val_nodes;
C>namespace literal_nodes;
C>namespace bindable_nodes;
C>...

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

C>Компилируется в набор файлов весом 5Мб

Во-во. А фрэймворк в сжатом вид 20 мег. Прикинь насколько у него длинее...

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

C>Просто можно изначально ориентироваться на "чистый" ClassView — тогда
C>все будет нормально.

Ну, в начале проекта так и будет. А через пару лет?

C>Инклуды не посчитал, сглючил, только cpp взял. С инклудами — в 4 раза
C>больше файлов.

Ну, уже лучше.

>> Да и 20 проектво это тоже явный перебор.

C>А что делать... Проекты действительно логически отдельные.

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

>> Боюсь, чтодучи построенным по твоим принципам он просто развалился бы.

C>Нет, были у меня и такие проекты — вполне нормально жили. Буст же живет
C>вполне нормально.

Буст это по файкту куча отдельных библиотек.

C>А 100% безошибочность от Vassist'а и не нужна (в отличие от
C>компилятора). Вполне достаточна 95%, современный ассист как раз примерно
C>на этом уровне и работает.

Нужна, нужна. Когда попробуешь быстрый и безошибочный вариант на VA смотреть тошно становится. Ну, по крайней мере я когда приходится трахаться с плюсами всегда получаю от этого серьезное раздражение.

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

GZ>Еще одно вдогонок. FxCop жутко ругается если в namespace мало классов.

Ну, это его личные проблемы.

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

X>- размером команды

Фиг с ним со всем остальным. Но как размер команды то влияет? Какие зависимости?

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

VD>Скажу крамольную фразу. Размер отдельных исходных файлов и количество типов в одном файле обратно пропорционален классу программиста.

Значит я на верном пути. Начинает мутить если файл >500 строчек [блюющий смайлик]
А некоторые ужасные классы вообще оформляю: один метод-один файл.

Ну еще константная болезнь и полгода назад чего-то пробило явно указывать this-> при вызове собственных методов класса. Старею ...

А ведь раньше создание файлов в 1500-2000 строчек было любимым занятием

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

Вообщем я так и делаю.

WH>Садись два. Модуль нельзя выгрузить по тому что сначала нужно удалить все объекты которые были созданы на основе кода этого модуля. В общем случае это не возможно.

Это почему невозможно? Вариантов вижу как минимум два. Первый, дать возможность убрать классы сборщиком мусора, когда их больше никто не будет использовать. Второй, классы удалять сразу, а у живых объектов поудалять все методы. Второй подход используется в VW ST.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Это почему невозможно? Вариантов вижу как минимум два. Первый, дать возможность убрать классы сборщиком мусора, когда их больше никто не будет использовать. Второй, классы удалять сразу, а у живых объектов поудалять все методы. Второй подход используется в VW ST.
Те либо в первом варианте таки дождаться пока все объекты будут удалены либо во втором варианте сломать программу что ИМХО не приемлемо.

VladD2 wrote:

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

Уже год живет, пока полет нормальный.

>>> Да и 20 проектво это тоже явный перебор.
> C>А что делать... Проекты действительно логически отдельные.
> Думать. 20 это как раз так цифра когда нужно задуматься над тем, что
> что-то не так. Вариантов много. Выеледение некоторых частей в
> отдельные библиотеки. Слияние проектов...

4 проекта — утилиты, для работы с проектными документами (преобразование
формата, браузер структуры и т.п.). 2 проекта — библиотеки, 5 проектов —
отдельные модули (в виде COM-серверов), и т.п. Кое-что можно объединить,
но нет особого смысла.

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

Тем не менее, в Бусте очень многие библиотеки зависят друг от друга, так
что пример проходит.

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

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

ГВ>А кто спорит с полезностью разнесения классов по файлам вообще? Я как раз оспариваю постулат, что "один класс = один файл".

Один файл= 50...300 строк. Сколько в этот обьем удастся впихнуть классов не важно.

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

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

GZ>Поговорим про элементарный COM. Он автоматически выгружает модули независимо от языка. Потому, открытия Америки в этом нет.

Разве разные COM-серверы запускаются не в разных процессах, и быть может даже на разных машинах? COM-овская DLL запущенная на выполнение COM-овским загрузчиком на удаленной машине, или на этой же самой, но в другом процессе — она же не может быть прилинкована к программе (разные адресные пространства). А раз она не прилинкована, то и отлинковывать ее не надо. Если уж говорить, про что-то элементарное, то не про "элементарный COM", а про элементарную DLL — вот она динамически загружается, линкуется, потом отлинковывается и выгружается — вот где нет открытия америки. Ну а то что приложение могло сохранить адреса процедур из уже выгруженной DLL и попытаться их потом вызвать — так это проблемы самого приложения.

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

> GZ>Поговорим про элементарный COM. Он автоматически выгружает модули
> независимо от языка. Потому, открытия Америки в этом нет.
> Разве разные COM-серверы запускаются не в разных процессах, и быть
> может даже на разных машинах?

Нет, COM-серверы могут запускаться и в том же процессе. Называется
in-proc COM server.

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

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

ANS>Зачем тогда вообще разбивать на файлы?

Re: Короткие или длинные исходинки

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

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>А некоторые ужасные классы вообще оформляю: один метод-один файл.

А какого же размера эти методы?

КД>Ну еще константная болезнь и полгода назад чего-то пробило явно указывать this-> при вызове собственных методов класса. Старею ...

Ну, это полезно только если из имени переменной не видно к чему она относится. В соглашении о форматировании кода РСДН для переменных-членов применяется префикс состоящий из подчеркивания. Так что код читается очень хорошо.

КД>А ведь раньше создание файлов в 1500-2000 строчек было любимым занятием

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