В общем проблема в том что я никак не могу привыкнуть к объектам, есть несколько функций обработки сетевого трафика: ip, tcp, udp. Начал переводить программу на объекты, функция ip:
получает указатель на буфер и его длину, анализирует ip пакет который предположительно находится в буфере (там может быть не ip), по окончании анализа (дефрагментация, фильтрация, ведение статистики) в зависимости от протокола вызывается функция обработки tcp или udp (могут быть другие).

четко видны характеристики объекта, есть параметры source_ip, destination_ip, другие параметры из заголовка, есть отдельная процедура дефрагментации, процедера фильтрации по ip...
Но нет ни малейшей идеи как перевести это в объект, т.е. я могу запихнуть все функции и переменные в класс, но как связать это с tcp и udp. Я вижу это так же как с функцией только к ней можно обращаться по типу ip.source_ip или ip.defragmenter.sessions(). В общем как связать объекты между собой? (создать сперва объекты tcp и udp и зарегистрировать их как-то в ip, потом при анализе ip решает которому обработчику передать дальнейшее управление?)
Помогите разобраться.

Может быть вам следует создать базовый абстрактный или не абстрактный класс для всех протоколов: ip, tcp, udp. В него запихнуть в виде чисто виртуальных функций общий интерфейс. А затем от этого абстрактного класса создавать производные классы для ip, tcp, udp 
В различные статические функции передавать ссылку или указатель на каокй-нибудь базовый класс, (если он не абстрактный), и вызывать виртуальные функции.

Сыроежка, сечас стек вызова: ip(pbuff, len) -> tcp(pbuff, len), причем при анализе одного пакета ip можно вызвать tcp несколько раз, т.е. ip явно знает кому передать управление, я не могу сделать что то типа analyze которая возвращала бы указатель на буфер и длину.
думаю как-то так:

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

наверное, всё-таки udp_class, а не ip_class ?

asmdzen, по той немногочисленной информации, которую ты дал, выглядит вполне нормально.
Если функции обработки tcp_class и udp_class имеют один и тот же интерфейс, так совсем хорошо.
Если же tcp_class возвращает, например, TCPPacket, а udp_class - UDPPacket, то будут проблемы

Если бы у вас был базовый класс, то в нем бы была определена функция register_proc( AbstractProtocol &protocol, size_t len );

 тогда бы вы могли ьвызывать ее как



Это сообщение отредактировал(а) Сыроежка - 29.6.2011, 18:51

Сыроежка, чот не пойму... у asmdzen, вроде именно так и сделано. нет ?

Может быть если эту функцию сделать статической, (так как в нее передается ссылка на объект) так будет более читаемо?

хотел показать что все наследуются от базового класса, т.е. ip в том числе, не знаю пока если так будет правильно, надо будет наверное по уровням их распределить, хотя они все получают как параметры для анализа только буфер. еще сейчас ip сам проверяет какой номер протокола и передает управление нужной функции, наверное писать ip.register_proc(tcp_obj, 6 ); будет не правильно, не смогу этот метож использовать где-то еще, типа сделаю register_proc(base_class next); методом базового класса и очередь анализаторов туда же, просто надо будет переместить проверку номера протокола в tcp и udp (какойто overhead получается, но думаю это не страшно) и изменить

на

чтоб они знали откуда брать дополнительные параметры.

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


то что я хотел прочитать )) Всем спасибо.