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

Ф>Оцени пожалуйста объём.
Ф>Интересует генерация vs ручная писанина.
Ф>(примерно 50 штук и планируется)

Объем ручного кодирования ты можешь оценить и сам. Если это средний класс (его размер ~2Кб), то умножаем 50 на 2 и получаем 100 Кб кода.

Код имеет одниковую структур (скучный), но разные имена. Программист пишет от 2, до 8 Кб отлаженного кода в день. Итого на это дело нужно в среднем месяц.

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

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

Если модель будет доступна в удобном виде (например, в виде иерархии объектов), то с использованием немерла я смогу сделать такой генератор где-то за 2-3 дня. Возможно быстрее.

С использованием T4 и C# где-то неделю-две.

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

Если предоставишь исходнып данные, могу попробовать накидать генератор на немерле (бесплатно, ессесно).

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

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

WH>Судя по всему ДСЛ получается примерно таким:
WH>Что такое [Insertable(0)] не ясно. Почему у тебя все nullable тоже не понял.
WH>

WH>table A 
WH>    Int4 ID_A pk;
WH>    Int4 ID_B fk B.ID_B;
WH>    Int4 ID_C fk C.ID_C;
WH>    VarChar<40> Data1;
WH>    VarChar<40> Data2;
WH>end
WH>

Скорее всего метамоделью тут является БД. Скорее всего, нулаблы вылезают потому что в БД поля поддерживающие NULL.

Если я прав, то ДСЛ тут не нужен. Моделью тут является БД. Ее можно читать прямо из метапрограммы или создать отдельную программу записывающую структуру БД в файл (например, в ХМЛ или том же джейсоне), а потом читать этот файл из метапрограммы. Это позволит сделать процесс сборки независимым от СУБД.

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

VD>В данном случае я оцениваю твои действия. И то что оценка не лестная виноват только ты.
Оценивает один, а виноват только другой, прикольно. Ну разве что оценщик — Абсолют. По-моему ты зазнался.

По теме: дай неквалифицированному программисту метапрограмминг, он напишет говнокод, который генерирует говнокод в квадрате. И сдаётся мне, языки с метапрограммированием не имеют никаких средств защиты от этого. Для некоторых слышать такое — как серпом по яйцам.

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

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

B>>>Завязывайте с грибами.
WH>>Понятно. Очередной thornik.

VD>Скорее очередной Klatu.

Главное, чтобы не очередной VladD2. Этого форум не вынесет.

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

VD>Так ты форумом промазал? Ведь в этом форуме обсуждаются вопросы философии программирования, а не о психологии или социологии.

Филосо́фия (φιλία — любовь, стремление, жажда + σοφία — мудрость → др.-греч. φιλοσοφία (дословно: любовь к мудрости)) — дисциплина, изучающая наиболее общие существенные характеристики и фундаментальные принципы реальности (бытия) и познания, бытия человека, отношения человека и мира

Так что не занимайся демагогией.

VD>Ну, а раз так, то не фиг на заголовок темы пенять, так как проблема в твоем мышлении, а не в применении МП.

Мое мышление тебя не касается.

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

VD>Чья бы корова мычала.

Точно не твоя. Мое мнение основано на знании фактов, твое — на домыслах и больном самомнении.

VD>По сути из него вытекает, что человек делает ошибку генерируя 50 классов на основании модели. А правильно было бы нафигачить 20/50 Кб (в разных сообщениях у тебя разные цифры) кода вручную и потом вручную же его поддерживать.

Конечно. Ежу ведь понятно, что надо нафигачить кодогенератор и потом уже его поддерживать, до полного оргазма.

VD>Я даже не могу подобрать слов для этого вывода, чтобы тебя не оскорбить ненароком. Назовем это мягким словом "заблуждение".

Не строй из себя невинность. Оскорбления из тебя лезут сплошным потоком.

VD>Да кто бы спорил? Переполнен. Но надо же понимать, что если код пишет быдлогодер, то совершенно по фигу как он пишет этот код. Все равно он будет быдлогодом.
VD>И разница только в том будет ли это 10 килобайт метакода, или 500 килобайт быдлокода полученного копипастой.

В данном случае — 1 мегабайт быдло-метакода, или 20 килобайт написанного руками.

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

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

VD>Могу только поздравить вас с грамотными решениями.

Да, решения отличные. Не меньше 3 прогеров с этого кормятся

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

Ага, меняется. В ней время от времени появляются новые свойства

VD>Если устроит генератор на дотнете, могу вам с ваять за 30 К рублей. Обещаю, легкость расширения и простоту использования.

Кто ж их тебе даст?

B>>объясняю по слогам, для особо хорошо знающих русский язык. "стучат" о нарушениях правил или законов, начальнику или другим людям, которые обладают властью чтобы наказать.
VD>А ты своим детям объясняй. Мне не надо. "Стучать" и "жаловаться" — это синонимы. Разве что имеющие разный негативный оттенок. Пруфлинк я тебе привел.

Читай параграф выше, пока не дойдет.

VD>После твоего описания только тот кто себе враг возьмется его использовать. Не находишь?

Ты думаешь, топ-менеджеры хоть что-нибудь понимают?

VD>Начнем с того, что этот проект (немерл) для вас скорее всего будет не по карману. По скромным подсчетам на N2 нужно где-то пол миллиона баксов. А по менее скромным от лимона до двух.

Не смеши мои тапочки. На один только говногенератор потратили уже не меньше 100k$, и страшно представить сколько еше потратят.

VD>А закончим, тем, что если ты в своей конторе имеешь право голоса при принятие решений, то ежу понятно, что немерла у вас не появится. И не потому, что я тебе не лестное что-то сказал, а потому, что менталитет у тебя такой. Не понимаешь ты МП и того что он дает. Ну, а если не имеешь, то и говорить не о чем.

МП отличная вещь, когда используется к месту и прямыми руками. А в руках говнокодера это хуже папуаса на бульдозере.
А вы на пару с Wolfhound — сами себе худшие враги.

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

VD>Если я прав, то ДСЛ тут не нужен. Моделью тут является БД. Ее можно читать прямо из метапрограммы или создать отдельную программу записывающую структуру БД в файл (например, в ХМЛ или том же джейсоне), а потом читать этот файл из метапрограммы. Это позволит сделать процесс сборки независимым от СУБД.
Это плохая идея.
Нужно генерировать БД по ДСЛ. А не наоборот.

Ибо в случае с ДСЛ мы можем иметь разные версии схемы БД.
Сделать проверяемые компилятором миграции с одной версии БД в другую. Причем если ДСЛ для миграций сделать правильно (на основе линз) то по этому ДСЛ можно будет сгенерировать код как для миграции на новую версию, так и для миграции на старую версию.
Более того если нам нужно перепрыгнуть через несколько версий мы можем сгенерировать одну оптимизированную миграцию которая в один проход сделает все что надо.

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

B>А вы на пару с Wolfhound — сами себе худшие враги.
Это определенно второй thornik.

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

VD>Объем ручного кодирования ты можешь оценить и сам.

Если быть честным, то уже оценил.


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

За один день я создал тестовую структуру БД (11 таблиц), написал хранимые процедуры (соотв. 11 штук), и написал эти самые классы. После чего протестировал DAL, над которым работал больше месяца. Всё это с 8 утра до 8 вечера.
Так что 20 классов в день — нормально (если заниматься только этим).


VD>В принципе не так много, но надо учитывать, что дальнейшее развитие кода приведет к ручному его изменениию.

Да, именно так. Просто было интересно услышать мнение со стороны.

VD>Что касается метапрограммы...

Метапрограмма...
Она появилась после уже после ручного кодирования, т.е. в тот момент, когда произошло очередное изменение стуктуры БД. Я тогда сильно пожалел, что не сделал её с самого начала.

VD>Если модель будет доступна в удобном виде (например, в виде иерархии объектов), то с использованием немерла я смогу сделать такой генератор где-то за 2-3 дня. Возможно быстрее.

Над своей версией я работал чуть больше недели.
Однако она делает несколько больше чем видно здесь, например генерит хранимые процедуры (Insert'ы).

VD>С использованием T4 и C# где-то неделю-две.
Что есть T4?

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

да, именно так.

VD>Если предоставишь исходнып данные, могу попробовать накидать генератор на немерле (бесплатно, ессесно).

Спасибо, но не надо. Однако некоторая доля любопытства таки была.
Исходные данные просты: MS SQL 2005, PK — int identity, в большинстве случаев поля Not null, а те которые нет — отображаются в конечном классе на свойства, помеченые атрибутом Nullable. Те поля, которые вставляются в таблицу — Insertable. Конструктор InsertableAttribute принимает int — порядковый номер параметра в хранимой процедуре.
Все поля в конечном CEntity nullable. Это сделано затем, чтобы можно было контролировать данные, записываемые в таблицу (0 и null — не одно и то же).

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

Это несколько усложняет DAL. (ИМХО)

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

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

VD>>Если я прав, то ДСЛ тут не нужен. Моделью тут является БД. Ее можно читать прямо из метапрограммы или создать отдельную программу записывающую структуру БД в файл (например, в ХМЛ или том же джейсоне), а потом читать этот файл из метапрограммы. Это позволит сделать процесс сборки независимым от СУБД.
WH>Это плохая идея.
WH>Нужно генерировать БД по ДСЛ. А не наоборот.

Миграции между БД, а особенно между СУБД — крайне редкая штука.
Генерация БД по коду уменьшает свободу оптимизаций на уровне БД (кэш-таблицы, вычисляемые поля и т.д).

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

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

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

VD>>>Если я прав, то ДСЛ тут не нужен. Моделью тут является БД. Ее можно читать прямо из метапрограммы или создать отдельную программу записывающую структуру БД в файл (например, в ХМЛ или том же джейсоне), а потом читать этот файл из метапрограммы. Это позволит сделать процесс сборки независимым от СУБД.
WH>>Это плохая идея.
WH>>Нужно генерировать БД по ДСЛ. А не наоборот.

Ф>Миграции между БД, а особенно между СУБД — крайне редкая штука.
Ф>Генерация БД по коду уменьшает свободу оптимизаций на уровне БД (кэш-таблицы, вычисляемые поля и т.д).

Лучше выделите оффтопик в отдельную ветку

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

Ф>Миграции между БД, а особенно между СУБД — крайне редкая штука.
А миграции между схемами БД?
Например, таблица добавилась. Или поле в таблице?
А если приложение коробочное, то у тебя будет куча пользователей с разными схемами БД.
И они имеют привычку обновляться, когда попало.
Те тебе нужно будет иметь все схемы БД. Уметь перестроить БД из текущей схемы в ту которую понимает новая версия программы.

Ф>Генерация БД по коду уменьшает свободу оптимизаций на уровне БД (кэш-таблицы, вычисляемые поля и т.д).
Это не так. Просто в ДСЛ нужно это предусмотреть.

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

WH>Просто в ДСЛ нужно это предусмотреть.
И продолжать предусматривать, пока ДСЛ не сравнится по сложности с языком общего назначения.

You will always get what you always got
  If you always do  what you always did

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

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

B>>А вы на пару с Wolfhound — сами себе худшие враги.
WH>Это определенно второй thornik.

А что он сделал? Тоже наступил на вашу любимую машинку? Я не со зла, просто так получилось.

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

VD>>Если я прав, то ДСЛ тут не нужен. Моделью тут является БД. Ее можно читать прямо из метапрограммы или создать отдельную программу записывающую структуру БД в файл (например, в ХМЛ или том же джейсоне), а потом читать этот файл из метапрограммы. Это позволит сделать процесс сборки независимым от СУБД.
WH>Это плохая идея.
WH>Нужно генерировать БД по ДСЛ. А не наоборот.

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

WH>Ибо в случае с ДСЛ мы можем иметь разные версии схемы БД.

Ну, вот, например, Ziaw считает, что с ДСЛ-я нельзя использовать для описания версий БД, и нужно использовать подход Рельс, в котором описываются "миграции", которые по сути являются императивными скриптами меняющими БД. При этом объекты для мапинга он описывал отдельно. На мой взгляд это хреновое решение, но у него есть свои аргументы.

Другой вариант наш Ваня (IB). Он считает, что БД надо править исключительно вручную (с помощью специализированной версии VS), а мапинг генерировать по БД. И фиг ты ему что докажешь .

WH>Сделать проверяемые компилятором миграции с одной версии БД в другую.

Миграции — это импратив. В них записывается как надо изменить БД от одной версии к другой. Они как раз очень плохо сочетаются с подходом от модели.

WH> Причем если ДСЛ для миграций сделать правильно (на основе линз) то по этому ДСЛ можно будет сгенерировать код как для миграции на новую версию, так и для миграции на старую версию.

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

WH>Более того если нам нужно перепрыгнуть через несколько версий мы можем сгенерировать одну оптимизированную миграцию которая в один проход сделает все что надо.

Это все теория. К тому же то что ты нарисовал в предыдущем сообщении не имеет никакого отношения к миграциям.
А практика бывает разная. Если у людей есть БД которую правят руками, то им не нужен никакой ДСЛ. Им нужен генератор мапинга на основании структуры БД.

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

Ф>За один день я создал тестовую структуру БД (11 таблиц), написал хранимые процедуры (соотв. 11 штук), и написал эти самые классы. После чего протестировал DAL, над которым работал больше месяца. Всё это с 8 утра до 8 вечера.

Хардкейс за две недели создал парсер C# 4... Но ошибки из него вылавливаем мы до сих пор.
Так что есть огромная разница между "нахреначил кода" и "создал работающий код".

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

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

Ф>Так что 20 классов в день — нормально (если заниматься только этим).

Ну, да. А пом еще две недели на рефактонинг и отладку.

Тогда по генератору в час тоже нормально .

Ф>Метапрограмма...
Ф>Она появилась после уже после ручного кодирования, т.е. в тот момент, когда произошло очередное изменение стуктуры БД. Я тогда сильно пожалел, что не сделал её с самого начала.

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

VD>>Если модель будет доступна в удобном виде (например, в виде иерархии объектов), то с использованием немерла я смогу сделать такой генератор где-то за 2-3 дня. Возможно быстрее.

Ф>Над своей версией я работал чуть больше недели.

Дык, ты нибось и инструменты использовал не такие как я. Плюс я МП занимаюсь довольно плотно.

Ф>Однако она делает несколько больше чем видно здесь, например генерит хранимые процедуры (Insert'ы).

Я бы просто воспользовался бы BLToolkit. Он это автоматом делает. Но если надо, то сгенерировать инсерты в работающем генераторе с проверенной моделью задача на час другой.

VD>>С использованием T4 и C# где-то неделю-две.
Ф>Что есть T4?

http://msdn.microsoft.com/en-us/library/bb126445.aspx

VD>>Если предоставишь исходнып данные, могу попробовать накидать генератор на немерле (бесплатно, ессесно).

Ф>Спасибо, но не надо. Однако некоторая доля любопытства таки была.
Ф>Исходные данные просты: MS SQL 2005, PK — int identity, в большинстве случаев поля Not null, а те которые нет — отображаются в конечном классе на свойства, помеченые атрибутом Nullable. Те поля, которые вставляются в таблицу — Insertable. Конструктор InsertableAttribute принимает int — порядковый номер параметра в хранимой процедуре.
Ф>Все поля в конечном CEntity nullable. Это сделано затем, чтобы можно было контролировать данные, записываемые в таблицу (0 и null — не одно и то же).

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

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

Ф>Это несколько усложняет DAL. (ИМХО)

Это ничего не усложняет. Наоборот меньшая связанность упрощает развитие. Наследование реализации нужно чтобы избежать копипасты. Но когда копипаст делается генератором кода — это не проблема. Ведь код все равно будет в одном экземпляре описан.

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

VD>На мой взгляд это хреновое решение, но у него есть свои аргументы.
Какие?

VD>Другой вариант наш Ваня (IB). Он считает, что БД надо править исключительно вручную (с помощью специализированной версии VS), а мапинг генерировать по БД. И фиг ты ему что докажешь .
Да я и не собираюсь.

VD>Миграции — это импратив. В них записывается как надо изменить БД от одной версии к другой. Они как раз очень плохо сочетаются с подходом от модели.
Это в рельсах императив.
Но можно сделать по-другому.

VD>Миграции и должны позволять менять версию в любую сторону. Но на практике это не выходит, так как там в итоге появляется полнейший императив (вставки/удаления данных и т.п.). Причем тестируют обычно только миграцию вверх. А на обратную миграцию забивают.
Я что зря про линзы сказал?
Линзы это гарантированно обратимое преобразование.
Комбинация линз дает линзу.
Как следствие, можно сделать какое угодно преобразование. При условии, что оно выражается через примитивные линзы.

Соответственно просто задаем две схемы БД. После чего на специальном ДСЛ описываем гарантированно обратимые миграции.
Причем компилятор проверит, что программист нигде не ошибся.

VD>Это все теория. К тому же то что ты нарисовал в предыдущем сообщении не имеет никакого отношения к миграциям.
Потому что я там ничего про миграции не рисовал.

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

WH>Но можно сделать по-другому.

Можно много чего. Но на это "можно" можно убить пол жизни. А людям нужно здесь и сейчас мапинг с РБД на объекты. Предлагать им написать вселенский всемогутр довольно самонадеянно.

VD>>Миграции и должны позволять менять версию в любую сторону. Но на практике это не выходит, так как там в итоге появляется полнейший императив (вставки/удаления данных и т.п.). Причем тестируют обычно только миграцию вверх. А на обратную миграцию забивают.
WH>Я что зря про линзы сказал?
WH>Линзы это гарантированно обратимое преобразование.

Это все мечты. А кода ты столкнешься с тем, что народу нужно в БД данные и хранимки пихать, то все станет намного сложнее.

WH>Соответственно просто задаем две схемы БД. После чего на специальном ДСЛ описываем гарантированно обратимые миграции.

Ага. Все просто... в теории. На практике же в БД есть данные. Данные нужно сохранять и преобразовывать.

WH>Причем компилятор проверит, что программист нигде не ошибся.

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

VD>>Это все теория. К тому же то что ты нарисовал в предыдущем сообщении не имеет никакого отношения к миграциям.
WH>Потому что я там ничего про миграции не рисовал.

Ты про них сказал.

ЗЫ

В общем, мы опять уперлись в твой максимализм. Решение задач идеальным образом зачастую выливается в очень долгую и кропотливую разработку. Это ты можешь видеть на примере того же N2. А людям надо решать основную задачу. И при наличии БД им может оказаться проще сгенерить код мапинга и пойти дальше.

Так что твой совет был бы хорош, если бы имелся супр-тул который бы реализовывал бы работу от модели с надлежащим качеством. Но пока такого не. МС-ный код-фирст — это детская поделка. У конкурентов тоже (вроде бы) нет ничего путного.

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

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

B>А что он сделал? Тоже наступил на вашу любимую машинку? Я не со зла, просто так получилось.

Да не наступил ты никуда. Неумело юлишь тут, игнорируя прямо поставленные вопросы. Позор на весь интернет... Я прочитал всю ветку и такой облом по твоей милости... Зря время потратил.

Фиг с ним, с конкретикой, уже 100 раз можно было показать пример исходных метаданных (банально поменять "говорливые" идентификаторы на нейтральные), и следом пример результирующего сгенеренного кода по метаданным. Можно упростить до 2-3-х полей и рядом приписать сколько в среднем полей в вашем протоколе. Всё! Если это ручная кодогенерация действительно такая простая, как ты говоришь, это заняло бы 5-10 мин, т.е. на порядок меньше времени, чем ты потратил на все свои юления и перегавкивания с коллегами по форуму. Как бонус: возможно уже получил бы пару полезных советов или даже готовый код, делающий основную работу (угу, здесь и такое случается).

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

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

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

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

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

Абсолютная нормальная манера. Только очень примитивные задачи можно объяснить парой десятков строк текста и кода. А нормальным программистам почему-то не только с примитивными задачами работать приходиться.