всю жизнь работал с высокоуровневыми штуками, нужно писать без них

или я навсегда потерян для высокого общества низкоуровневых программистов?

да

Хочешь — учи, не хочешь — не учи. Вопрос какой-то непонятный. Если неинтересно низкоуровневое и нравится кьют, то занимайся тем, что нравится!

Хочешь — учи, не хочешь — не учи. Вопрос какой-то непонятный. Если неинтересно низкоуровневое и нравится кьют, то занимайся тем, что нравится!

Резонно. Но там платят больше (вы ведь тоже работаете не потому, что вам нравится, так?), поэтому можно перефразировать вопрос - оно того стоит? Меня смущает, что для любой ерунды придётся писать велосипед (а ведь так удобно работать с QString и QMap...), да и с построением архитуктуры сишных приложений я опять же не знаком :(

взял QTcpServer, взял QTcpSocket

... и на большом количестве соединений убил производительность за счет ущербной реализации event loop.

Делай обёрточки красивые, да используй их. В конце концов, объекты C++ — это те же структуры, а значит на структурах можно построить некоторое необходимое подмножество ООП, которое будет удобно в данной ситуации.

... и на большом количестве соединений убил производительность за счет ущербной реализации event loop.

Можно подробнее? У тебя есть какой-то негативный опыт? Кроме того, сколько по-твоему времени пройдёт (и не выйдет ли к этому времени новый стандарт С? :)), прежде чем я смогу реализовать event loop, сравнимый по производительности с кьютовым?

А тебе не нужно ничего реализовывать - для сложных случаев есть libev, для простых - хватит простого цикла с poll или select

обёрточки красивые

У каждого программиста на сях есть какой-то джентельменский набор собственных обёрток?

http://apr.apache.org/

Браток, может, книги какие-нибудь подкинешь или мануалы?

хватит простого цикла с poll или select

Мне ведь взаправду это ни о чём не говорит

Читай маны (man poll, man select, man epoll, man pthread и т.д.). Попробуй пописать простые программы с потоками и сетью, используя только стандартную библиотеку и сисколлы. Насчет книг ничего не подскажу (кроме K&R :)

Для сишечек тоже есть библиотеки(и контейнеры, и всё, что нужно для удобной работы), не бойся. Первое, что приходит в голову — http://www.kannel.org/. Там есть обёртки для синхронизации потоков, контейнеры и прочее.

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

гугли «UNIX. Разработка сетевых приложений» Стивенса

НИКАКОГО ООП

А ты сразу во внутрь ядра иди, там ООП во все поля

Спасибо всем за советы, лор не без добрых людей.
Встретимся через неделю, будет сбор на операцию по пересадке мозга.

страшные сетевые да многопоточные штуки

испытываю большую попоболь

стоит ли учить всё это дело

Нет.

Насчет книг ничего не подскажу (кроме K&R :)

Стивенс же.

В общем, всегда писал приложения независимо от платформы (шindoшs, liпuх, мас, bb, апdгoid) и направления (консольные\гуёвые) с использованием, собственно, фреймворка Qt.

Молодец, пиши ещё.

И тут, внезапно, появилась интересная вакансия - писать придётся на Pure C (sic!) для Linux страшные сетевые да многопоточные штуки.

Если совсем не жалко клиента - можно и потренироваться, шишек понабивать годик, да. Оно, правда, работать будет плохо, а клиент потеряет время и деньги. Я бы пожалел клиента, или сразу честно заявил, что тема - не мой конёк. Но если клиент сам настойчиво зовёт, значит не прошарил разницу, так что пусть страдает :)

НИКАКОГО ООП

Это не так.

Вопрос к сообществу - стоит ли учить всё это дело

Как хочешь. Это не модно, но вон люди типа zekka верны old school и идут осознанно в сишку. Но было бы красивее проявить профессионализм и профессиональную солидарность и передать клиента соответствующему специалисту.

Думаешь мне не приходится слезать с высот чтобы низкоуровневый навоз чистить? Но чтобы это было постоянно - ненене...

На чистых сях приходит понимание как и что устроено там «внизу», под обёртками всяких ООП. Вот вчера приблуду доделал на Qt и срезалось всё на, не поверите, gcc, который не умеет в cpp инициализровать сложные типы и вываливается с

sorry, unimplemented: non-trivial designated initializers not supported.

Причём гугол направляет на багтрекер самого gcc, в котором разработчики посмеялись в виде - нужен ли нам PR известной проблемы...

К чему это я. Лучше писать либо на cpp либо на pure c, а то получается как с бочкой варенья. Если тебе действительно интересно - используя структуры получишь то же самое ООП и на чистых сях. Да, придётся некоторые велосипеды самому поизобретать и иметь уже свою библиотеку часто используемых конструкций, но это опыт, за который потом будешь получать денежку. А сейчас всё зависит от ситуации, если клиент готов подождать твои эксперименты и обучение, можешь попробовать, если же ему нужен результат - направь к тем, кто быстрее сделает ему хорошо.

... и на большом количестве соединений убил производительность за счет ущербной реализации event loop

Используй нормальный event dispatcher

только хардкор же. учи

СТРУКТУРЫ и НИКАКОГО ООП
...
или я навсегда потерян для высокого общества низкоуровневых программистов?

Если не способен разглядеть в низкоуровневом сишном коде ООП - определённо да, потерян.

Это Qt то высокоуровневый? Посмеялся. А в сравнении с чем? С написанием драйверов - ну, может быть, гг.

Если ты не знаешь stl => ты по определению не знаешь с++. Я в курсе, что в Qt есть свои контейнеры, совместимые с stl, но фраза «Раньше я даже об STL старался руки не марать» намекает, что и Qt-шные контейнеры ты используешь по примерам из руководства.

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

Следующий крупный пласт знаний - это многопоточность. Ну, тут тоже нужно знать теорию в первую очередь: синхронизация, гонки, блокировки и т.п. Для плюсов можно читать Вильямса - concurrency in action.

Изучать низкоуровневые апи (сеть, диск, железо и т.п.), если ты уверенно не знаешь основ из прошлого абзаца, - особого смысла нет.

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

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

Но с возрастом ты начнёшь понимать, что твои знания устаревают, фреймвоки отмирают, технологии меняются. А ты как белка в колесе крутишься, и зарплата твоя особо не растёт.

Сходи на рсдн->форумы->работа. Там собирается весь этот биомусор с плашками на пол экрана «мост проффешионал C#2.0 девелопер», «майкрасофт мост чего-то там сильверлайт сертификейтед павер юзер» и т.п.

Они там в темах перманентно жалуются на жизнь, особо доставляет разрыв шаблонов. У них столько сертификатов, столько балов на брейнбенче, а на нормальную работу не берут. Там же всё это нытьё, что у программистов после 30 лет нет никаких перспектив (молодые наступают, лол)

Просят написать разворот односвязного списка - да это ж пиздец сложная задача! Они и слов-то таких не знают. Без иде на бумажке такие «проблемы» не решаются. Они зато, блять, могут вам рассказать за архитектуру (ну, понятно, пиздить - не мешки ворочать).

^^^ плюсану.

НИКАКОГО ООП

Это ни одному сишнику ещё ни разу не помешало.

Во, таки встретил впервые пример человека, о котором постоянно складывают легенды си программисты чтобы оправдать свои мучения - человек не понимающий как реально работает код. Обычно все нормальные программисты на высокоуровневых языках долго изучали асм, системное программирование и строение ОС

Обычно все нормальные программисты на высокоуровневых языках долго изучали асм, системное программирование и строение ОС

Га-га-га. ЩАЗЗ.

НИКАКОГО ООП

В вакансии прям так написано?

Обычно все нормальные программисты на высокоуровневых языках долго изучали асм, системное программирование и строение ОС

особенно программирующие на php.

Тебе вообще не стыдно называться программистом, если ты не можешь реализовать любую идею на Си?

Слишком много школьного слэнга.

Читай Стивенса, ага.

Чего «Га-га-га» то? Сказано же НОРМАЛЬНЫЕ программисты.

Я думаю, тебе надо смотреть в сторону .Net, и не подходить к сишечке на пушечный выстрел

Как можно писать сетевые приложения, не зная базовых сетевых функций? У меня в голове не укладывается.

По теме - мне лично C++ не нравится, а чистый C больше нравится. Решаешь задачи, а не воюешь с гистоморфизмами и пятьдесят четверым конструктором копирования.

Просят написать разворот односвязного списка - да это ж пиздец сложная задача! Они и слов-то таких не знают. Без иде на бумажке такие «проблемы» не решаются. Они зато, блять, могут вам рассказать за архитектуру (ну, понятно, пиздить - не мешки ворочать).

Знал я одного такого «специалиста» — делал сортировку массива при помощи System.Windows.Forms.ListBox.

Да, Qt все ближе и ближе подбирается к delphi. Qt это GUI-библиотека с набором дополнительных свистелок, типа QThread и QTcpSocket. И относится к ней нужно так-же.

Не надо писать сервера с использованием QTcpServer, они не способны будут работать под нормальной нагрузкой.

Раньше я даже об STL старался руки не марать, а тут, право, настоящая чернуха начнётся.

Ололо, ну ты тупой. STL это намного более высокий уровень абстракции, чем тот помоечный недо-ООП, который типичен для кода Qt.

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

сетевые да многопоточные штуки

Были прецеденты тактичного перетаскивания всей конторы на эрланг. При этом объяснялось, что это просто такой сетевой «драйвер». Поможешь себе и людям. Погугли.

Не надо писать сервера с использованием QTcpServer, они не способны будут работать под нормальной нагрузкой.

Ы? 5,000 одновременных соединений — нормальная нагрузка? QTcpServer такую спокойно держал (правда, мы использовали свой Event Dispatcher).

Тогда что осталось QTcpServer'у, тянуть зависимость от Qt? :)

Event dispatcher — это QtCore, не QtNetwork.

стоит ли учить всё это дело

ИМХО ты не до конца понял. Дело в том, что тебе всё это дело придётся писать.

Кстати ООП вполне себе реализуется на структурах. Макросы опять же.

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

Отличное объяснение. И что? :)

В чем смысл использования Qt при написания серверов? Заметьте, пулинг вы уже переписали.

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

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

Словил бугурта что ли? Узнал себя в портрете гоблина с рсдн? Где я писал про системщиков вообще? Фундаментальные знания нужны любому разработчику, если он не хочет остаться обезьяной. И да, современные технологии тоже надо знать в определённом объёме, спасибо, КЭП.

Сказано же НОРМАЛЬНЫЕ программисты.

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