это Ваше виденье задачи... наверное оно идеально.... для вас...

для тех кто идеально не читал - повторюсь...

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

а теоретические изыски - это я пас... я больше практик...

Сообщение отредактировал kolobok0 - Jul 26 2012, 12:12

Заметьте, что все многоточия собранны в обработчиках уровней протокола, а не в самом объекте пакета (class Buffer)
Неа, в объекте-пакете (Buffer) не одной точки нету, не то что многоточий

А я об этом сразу говорил, вот цитата -


И еще одна


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

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

Можно подробнее про программирование на С в ООП стиле? желательно с примером

Предыдущую страницу слобо посмотреть ? пример
http://prex.sourceforge.net/src/S/252.html#L48

спасибо. Не могли бы вы немного объяснить в чём приемущества такого подхода(когда работаем с объектами на С)? пока не понятна сама суть. Просто все объекты кода описываются как структуры

Приведен избитый пример структуры базового драйвера. Написан он так не потому, что хотели изобразить в стиле ООП, а потому что иначе не написать драйвер который может динамически подключаться к прикладным уровням.
Например к файловой системе может быть подключен драйвер NAND Flash, а потом отключен и подключен драйвер SD карты.
Но это показуха, поскольку чуть меняется тип периферии скажем нужен драйвер мультиплексированного канала к внешнему вспомогательному контроллеру, как такая структура драйвера уже не подходит и нужно рядом сочинять другой.
Т.е. полное отсутствие полиморфизма.
Другая проблема в том, что самые интересные функции драйвера скрыты в функциях ioctl и devctl.
Там вообще творится беспредел. Что точно эти функции делают можно понять исключительно просканировав все их исходники сверху донизу.
Это противоположность принципу наследования.
В нормальном ООП подходе места таким функциям нет. Вместо этого должно было быть наследование абстрактных методов от базового драйвера и дополнение уникальными методами.
Вместо этого же имеем ioctl с десятками (если не сотнями) типов аргументов. Браузеры кода можно выкинуть, это самые скверные места в операционках.
И после этого любители линукса говорят, что что-то могут сделать за пять минут. Ну-ну!

И на каждый такой уникальный метод создавать новый системный вызов ? ггг - типичный такой индусский подход как все же прекрасно что не все болеют ООП головного мозга.

Сообщение отредактировал sasamy - Jul 29 2012, 22:51

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