Здравствуйте.
Я не давно стал назиматься технологией клиент-серверных программ.
Написал многопользовательский сервер, ну и клиента для него.
Всё работает замечательно, но из-за недостатка опыта не могу провести адекватный анализ организации программы.
Прикрепляю файл с кодом сервера.
Прошу Вас при наличии недостатков и неправильного подхода к организации той или иной части программы сказать это и по возможности подсказать в каком направлении двигатся.
Если что то не совсем правильно в оформлении кода, то заранее приношу извенения.
Заранее благодарен,
С уважением HAWK3500.


Это сообщение отредактировал(а) hawk3500 - 19.1.2012, 12:39

Присоединённый файл ( Кол-во скачиваний: 11 )
 server.cpp 32,06 Kb

hawk3500, честно говоря не стал анализировать код настолько глубоко, чтобы дать вам тот ответ, что вы ждете. но могу вам сказать свои впечатления как стороннего человека:
1 у вас несколько структур и функции сваленные в кучу - будет очень сложно не то что масштабировать ваш проект, но даже сопровождать.
2 code-style у вас отсутствует, плюс жуткий code-style от win32 - ваш проект не просто читать
3 используете magic numbers - проименуйте константы, это просто потрясающе полезно
4 не используйте макросы, лучше константы, про полезность см выше
5 комментарии лучше писать на английском - я им тоже не в совершенстве владею и пишу с ошибками, но это уже сложившаяся культура, на русском писать не смертельно, конечно, но все же. также не используйте в комментах жаргонизмы. я в свое время учился ругаться как негры в боевиках, но когда американец начал матерится в разговоре со мной, демонстрируя знание русского языка, я понял, что писать и читать надо грамотно.
6. плюс вы используете bsd-сокеты. почитайте здесь по этому поводу

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

З.Ы.  комментарии не совсем те, что вы ожидали, не сочтите за нравоучение, это все имхо.

Добавлю:
Полностью отказаться от goto. Хороший код лучше читается, чем непонятная лапша.

hawk3500, так а что на счет asio/poco? ты так и не ответил. или это такой "тонкий" способ игнора?

Спасибо.
Не то что ожидалось это верно, но сказанное не менее ценно.
boostcoder не вкоем случае не игнор.
Просто не успел ответить тогда , а потом забыл.
Согласен не правильно, но так как есть.
На счёт asio/poco:
прочёл Вашу тему
http://forum.vingrad.ru/forum/topic-336344.html
1)Пишу проект который будет взаимодействовать с другими проектами построенных на BSD.
2)У меня многие программы реализованны на QT, и в нём на мой взгляд весьма неплохой,
набор функций для работы с сокетами...но и тут я стараюсь этого избегать.

Т.К. не имею дела с кросплатформенными приложениями, то считаю . что всё что реализованно через API должно работать напрямую с API.
Тот же Qt,работая под виндой по сути использует класс надстройку над темеже API функциями работы с сокетом.
А т.к. я любитель асма и низкоуровнего программирования(мне более удобно работать именно на таком уровне), то считаю что не стоит накручивать "недокументированное" вокруг "недокументированного".
Была бы моя воля, я бы обрабатывал всё через NDIS.
Но требования к совместимости и к реализации ставятся за частую не мной,и поэтому я стараюсь выбирать наиболее низкоуровневый вариант из имеющихся.

BSD socket лежат в основе подавляющего большинства библиотек. Не ошибусь, если скажу что при слове сокет все подразумевают именно BSD сокеты. Т.е. не аргумент.

Тут тоже нет аргумента


Зачем работать на прямую с API? Выигрыш не такой большой и зачастую он бесполезен. И где гарантии что вы никогда не будете работать с кроссплатформенными приложениями?
Если любитель, то конечно, это все упрощает. Но представьте, вы отдали машину на замену масла, приходите забирать, а двигатель разобрали и заново собирают - людям нравится работать на низком уровне, они кайфуют от этого. Разбирают каждую детальку, тщательно протирают, смотрят на свет как она выглядит - прямо любуются. Да, они возможно соберут вам двигатель назад без последствий. Но что-то мне подсказывает, что в следующий раз масло вы будете менять у других. У тех кто просто поменяет вам масло. Не надо усложнять, как например я - видите какой пост написал с примером про машину, а мог бы просто сказать, что в большинстве случаев (в том числе и конкретно в вашем) низкоуровневое программирование выльется в громоздкий, а значит излишне сложный и (потенциально более) неустойчивый код, сложный в сопровождении и масштабировании.

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

Добрый день.
Возможно не к месту, но добавлю ИМХО от фаната Boost.Asio:

• начинать стоит с сиcтемного API (можно аж на C) - для Windows стоит рассмотреть все варианты и особенно IOCP (в топку WSASelect);
• писать стоит все же на Asio (для Java это будет Apache MINA или Netty) - так как там многие велосипеды уже реализованы (ну, можно и на ACE/POCO).

Для первого пункта есть (в порядке полезности):

• "Network Programming for Microsoft Windows (Second Edition)";
• "Эффективное программирование TCP-IP" (Йон Снейдер);
• "Создание эффективных Win32-пpилoжeний с учетом специфики 64-разрядной версии Windows";
• "Programming Server-Side Applications for Microsoft Windows 2000".

Насчет "низкоуровневости" - Asio представляет из себя весьма тонкую прослойку (говорю про Windows, так как плотно копался только в этой части) - "тонче", чем Qt и, полагаю, чем ACE. Вместе с тем, Asio избавляет программиста от некоторых проблем в WinSock API, например, от некоторых недокументированных особенностей IOCP. 
Сам я "прошел путь" от raw-C + WinSock (WSASelect + IOCP) до Asio. При чем остановился на последнем, так как многие базовые вещи все равно приходилось реализовывать так, как это сделано в Asio.

Это сообщение отредактировал(а) mabrarov - 23.1.2012, 11:02