Здравствуйте, Cyberax, Вы писали:
C>Просто можно изначально ориентироваться на "чистый" ClassView — тогда C>все будет нормально.
Ну, в начале проекта так и будет. А через пару лет?
C>Инклуды не посчитал, сглючил, только cpp взял. С инклудами — в 4 раза C>больше файлов.
Ну, уже лучше.
>> Да и 20 проектво это тоже явный перебор.
C>А что делать... Проекты действительно логически отдельные.
Думать. 20 это как раз так цифра когда нужно задуматься над тем, что что-то не так. Вариантов много. Выеледение некоторых частей в отдельные библиотеки. Слияние проектов...
>> Боюсь, чтодучи построенным по твоим принципам он просто развалился бы.
C>Нет, были у меня и такие проекты — вполне нормально жили. Буст же живет C>вполне нормально.
Буст это по файкту куча отдельных библиотек.
C>А 100% безошибочность от Vassist'а и не нужна (в отличие от C>компилятора). Вполне достаточна 95%, современный ассист как раз примерно C>на этом уровне и работает.
Нужна, нужна. Когда попробуешь быстрый и безошибочный вариант на VA смотреть тошно становится. Ну, по крайней мере я когда приходится трахаться с плюсами всегда получаю от этого серьезное раздражение.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Скажу крамольную фразу. Размер отдельных исходных файлов и количество типов в одном файле обратно пропорционален классу программиста.
Значит я на верном пути. Начинает мутить если файл >500 строчек [блюющий смайлик]
А некоторые ужасные классы вообще оформляю: один метод-один файл.
Ну еще константная болезнь и полгода назад чего-то пробило явно указывать this-> при вызове собственных методов класса. Старею ...
А ведь раньше создание файлов в 1500-2000 строчек было любимым занятием
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
VD>Много это сколько? В проекте R# 673 только .cs-файлов. В редакторе кода который я сейчас пишу на сегодня 82 файла. В Хоуме 409. Ни в одном из проектов проблем с поиском нужного участка кода не встает. И поиск обычно ведется по фйлам, а не по логической структуре, так как в ней можно утонуть (она ведь не может структурироваться папками).
WH>Садись два. Модуль нельзя выгрузить по тому что сначала нужно удалить все объекты которые были созданы на основе кода этого модуля. В общем случае это не возможно.
Это почему невозможно? Вариантов вижу как минимум два. Первый, дать возможность убрать классы сборщиком мусора, когда их больше никто не будет использовать. Второй, классы удалять сразу, а у живых объектов поудалять все методы. Второй подход используется в VW ST.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Это почему невозможно? Вариантов вижу как минимум два. Первый, дать возможность убрать классы сборщиком мусора, когда их больше никто не будет использовать. Второй, классы удалять сразу, а у живых объектов поудалять все методы. Второй подход используется в VW ST.
Те либо в первом варианте таки дождаться пока все объекты будут удалены либо во втором варианте сломать программу что ИМХО не приемлемо.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
VladD2 wrote:
> C>Просто можно изначально ориентироваться на "чистый" ClassView — тогда > C>все будет нормально. > Ну, в начале проекта так и будет. А через пару лет?
Уже год живет, пока полет нормальный.
>>> Да и 20 проектво это тоже явный перебор. > C>А что делать... Проекты действительно логически отдельные. > Думать. 20 это как раз так цифра когда нужно задуматься над тем, что > что-то не так. Вариантов много. Выеледение некоторых частей в > отдельные библиотеки. Слияние проектов...
4 проекта — утилиты, для работы с проектными документами (преобразование
формата, браузер структуры и т.п.). 2 проекта — библиотеки, 5 проектов —
отдельные модули (в виде COM-серверов), и т.п. Кое-что можно объединить,
но нет особого смысла.
>>> Боюсь, чтодучи построенным по твоим принципам он просто развалился бы. > C>Нет, были у меня и такие проекты — вполне нормально жили. Буст же живет > C>вполне нормально. > Буст это по файкту куча отдельных библиотек.
Тем не менее, в Бусте очень многие библиотеки зависят друг от друга, так
что пример проходит.
VladD2 wrote:
> C>namespace val_nodes; > C>namespace literal_nodes; > C>namespace bindable_nodes; > C>... > И пользователь твоих классов будет вынужден ссылаться на все эти > сокращения только потому что тебе было влом разнести классы по файлам?
Нет, с неймспейсами код выглядит более читабельным.
> C>Компилируется в набор файлов весом 5Мб > Во-во. А фрэймворк в сжатом вид 20 мег. Прикинь насколько у него > длинее...
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>А кто спорит с полезностью разнесения классов по файлам вообще? Я как раз оспариваю постулат, что "один класс = один файл".
Один файл= 50...300 строк. Сколько в этот обьем удастся впихнуть классов не важно.
Re[17]: Короткие или длинные исходинки - Модульный подход
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Сергей Губанов, Вы писали:
GZ>Поговорим про элементарный COM. Он автоматически выгружает модули независимо от языка. Потому, открытия Америки в этом нет.
Разве разные COM-серверы запускаются не в разных процессах, и быть может даже на разных машинах? COM-овская DLL запущенная на выполнение COM-овским загрузчиком на удаленной машине, или на этой же самой, но в другом процессе — она же не может быть прилинкована к программе (разные адресные пространства). А раз она не прилинкована, то и отлинковывать ее не надо. Если уж говорить, про что-то элементарное, то не про "элементарный COM", а про элементарную DLL — вот она динамически загружается, линкуется, потом отлинковывается и выгружается — вот где нет открытия америки. Ну а то что приложение могло сохранить адреса процедур из уже выгруженной DLL и попытаться их потом вызвать — так это проблемы самого приложения.
Re[18]: Короткие или длинные исходинки - Модульный подход
Сергей Губанов wrote:
> GZ>Поговорим про элементарный COM. Он автоматически выгружает модули > независимо от языка. Потому, открытия Америки в этом нет. > Разве разные COM-серверы запускаются не в разных процессах, и быть > может даже на разных машинах?
Нет, COM-серверы могут запускаться и в том же процессе. Называется
in-proc COM server.
Выгружается COM-сервер тогда, когда количество блокировок его модуля
становится равно 0. Блокировки ставятся при создании/удалении объекта,
либо с помощью специальных функций.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
VD>>Много это сколько? В проекте R# 673 только .cs-файлов. В редакторе кода который я сейчас пишу на сегодня 82 файла. В Хоуме 409. Ни в одном из проектов проблем с поиском нужного участка кода не встает. И поиск обычно ведется по фйлам, а не по логической структуре, так как в ней можно утонуть (она ведь не может структурироваться папками).
ANS>Зачем тогда вообще разбивать на файлы?
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>А некоторые ужасные классы вообще оформляю: один метод-один файл.
А какого же размера эти методы?
КД>Ну еще константная болезнь и полгода назад чего-то пробило явно указывать this-> при вызове собственных методов класса. Старею ...
Ну, это полезно только если из имени переменной не видно к чему она относится. В соглашении о форматировании кода РСДН для переменных-членов применяется префикс состоящий из подчеркивания. Так что код читается очень хорошо.
КД>А ведь раньше создание файлов в 1500-2000 строчек было любимым занятием
Моя первая прогамма состояла из одно С-ишного файла и была написана в худших традициях. Почти вся она состояла из одного switch-а, а весь значимый код был внутри case-ов. Причем написан он был дико прямолинейно... процедур было минимум... казалось, что его причесали гребенкой настолко он был прямолинеен. Но программа работлала! А ведь это была резедентная программа способная появляться поверх других дос-овских приложений и отображать гипертекстовую информацию (я тогда даже слова такого как "гипертекст" не знал, и об Интернете не слышал). В общем, это действительно работало и глюки (которые наверняка в ней были) особо не досаждали. Но вот одна беда... Внесение изменений, даже малейших, превращалось в истенный ад. После этого я серьезно задумался на структурированием и ООП. И каждая следующая программа все больше и больше расползалась по файлам. А те, в свою очередь, становились все меньше и меньше.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Короткие или длинные исходинки - Модульный подход
Здравствуйте, Сергей Губанов, Вы писали:
GZ>>Поговорим про элементарный COM. Он автоматически выгружает модули независимо от языка. Потому, открытия Америки в этом нет.
СГ>Разве разные COM-серверы запускаются не в разных процессах, и быть может даже на разных машинах?
Длл загружается в пространство процесса. Если не принимать специльных мер (регистрировать объекты так чтобы они грузились в сурогатных процессах или насильно загружать их в такие процессы), то длл загружается в адресное пространство процесса создающего объект. И выгрузить КОМ-серев из памяти очень не просто.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: VD>>>Много это сколько? В проекте R# 673 только .cs-файлов. В редакторе кода который я сейчас пишу на сегодня 82 файла. В Хоуме 409. Ни в одном из проектов проблем с поиском нужного участка кода не встает. И поиск обычно ведется по фйлам, а не по логической структуре, так как в ней можно утонуть (она ведь не может структурироваться папками).
ANS>>Зачем тогда вообще разбивать на файлы?
VD>Re: Короткие или длинные исходинки
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>>А некоторые ужасные классы вообще оформляю: один метод-один файл.
VD>А какого же размера эти методы?
Такого, какой нужен для выполнения поставленной задачи
В таких случаях стараюсь укладываться в два-три экрана.
Бывают, правда, экстремальные случаи. Но они лечутся показом исходного кода новым людям
У меня IBProvider, в этом плане, является тренировочной площадкой. Например, реализация интерфейсных методов OLEDB-команды (которая оформлена в виде одного плюсового класса, не принимая во внимание агрегацию дополнительной функциональности) разнесено по разным файлам. Удобно править — в поле зрения нет ничего лишнего.
Есть случаи, когда один класс реализует несколько интерфейсов и реализации этих интерфейсов находятся в разных файлах.
В 99%, конечно, стараюсь один класс — одна пара файлов (h/cpp).
КД>>А ведь раньше создание файлов в 1500-2000 строчек было любимым занятием
VD>Моя первая прогамма состояла из одно С-ишного файла и была написана в худших традициях. Почти вся она состояла из одного switch-а, а весь значимый код был внутри case-ов.
VD>Внесение изменений, даже малейших, превращалось в истенный ад. После этого я серьезно задумался на структурированием и ООП. И каждая следующая программа все больше и больше расползалась по файлам. А те, в свою очередь, становились все меньше и меньше.
Навеяло чего-то: "Утучняется плоть, испаряется пыл..." (c) не моё
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Xentrax, Вы писали:
X>>- размером команды
VD>Фиг с ним со всем остальным. Но как размер команды то влияет? Какие зависимости?
Ну вот я же и расписал сразу после этой строчки. Конкретный пример: вот у нас есть штук 10 больших файлов по 5000 строк, их постоянно кто-то правит, и все записываются в очередь на чек-ин. Кто-нибудь забывает положить в америке или в японии, мы тогда здесь в москве этот файл додумываем, чтобы компилировалось, и потом люди его забирают через шару.
Тот же пример с парсерами тут где-то в ветке был. Пока один человек пишет, все нормально, а ну как проект вырастет, наймут еще пару атусорсеров? Фигня получится.
Поэтому серьезный многолетний проект должен состоять из маленьких файлов.
Еще пример. Предположим, у вас действительно серьезный продукт. И у вас есть версия 8, 7, и 6. И вы к ним выпускаете патчи. Имея маленькие файлики, очень удобно вставлять исправления из версии 8 в версию 6. Почти всегда это ограничивается сравнением и копированим файла в FARе. Т.е. не нужно привлекать всю ту машинерию для броузинга по файлам, которую тут так продвигали, и даже не нужно запускать CSDiff!!!
И еще. В развитие тезиса "никогда не знаешь, что понадобится". Мы наследуем исходники из другой команды, и из-за крупноватых кусков нам приходится больше портировать абсолютно ненужного нам кода, и чаще пользоваться CSDdiff'ом, чем хотелось бы. Прчием в процессе миграции они свои исходники часто обновляют и их часто приходится сливать. Маленькие файлы сливать не в пример легче. Прямо в Фаре. Когда эти исходники только начинались, Windwos CE еще не было.
Вот еще пример из жизни, который я вроде бы нигде не приводил, кпочему удобно иметь класс в файле с именем, однозначно выводщимся из имени класса:
Вот у нас сейчас 35 модулей, на каждый уже по 4 файла с проектами — для VC7.1, EVC3, EVC4 и теперь VC8.0. Кто-то добавил файл в проект для VC7.1, а мне надо собрать версию для iPAQ(EVC3), а она не ликуется из-за класса CMyClass, я беру и добавляю MyClass.cpp в нелинкующийся проект, и все. А так мне еще нужно будет запустить поиск по всем файлам на CMyClass, чтобы узнать где он реализован, и только потом добавить файл MySuperClasses.cpp. И так несколько раз.
Короче, я к тому, что слияние файлов и вообще работа на стыке множества проектов, пишущихся активно и параллельно разнородными командами, которые по английски-то иногда не говорят, может быть затруднена до полной стагнации использованием слишком больших файлов.
Опять же, я не претендую на общность, все что я говорю, касается сейчас только совремнного С++ в том виде, в котором я его вижу, имея возможность работать с простыми индо-китайцами с американским паспортом. Может в будущем, как хотел Страуструп, вообще файлов не будет.
