вот есть хорошая книжка с примерами кода на сях, там нету в большинстве случаев ничего похожего на классы https://www.ozon.ru/context/detail/id/4187085/

код написан зубрами своего дела

скорее наоборот

да? питон хороший язык для всего, и С - хороший язык для написания плагинов к питону. остальные языки в той или иной степени говно. я верно усвоил вашу точку зрения?

вот есть хорошая книжка с примерами кода на сях, там нету в большинстве случаев ничего похожего на классы https://www.ozon.ru/context/detail/id/4187085/

стоит качать? :)

стоит качать? :)

да. но стоит помнить, что там за бортом оставлкны примерно 70% повседневных задач

в хорошем коде на сях нет подобий классов

Есть

вот есть хорошая книжка с примерами кода на сях, там нету в большинстве случаев ничего похожего на классы https://www.ozon.ru/context/detail/id/4187085/

фраза "в большинстве случаев" намекает на то что если им дать разгуляться они сделают еще одно ООП на сях

да? питон хороший язык для всего, и С - хороший язык для написания плагинов к питону. остальные языки в той или иной степени говно. я верно усвоил вашу точку зрения?

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

а в чём собственно проблема? очередь — хорошее решение для поддержки асинхронности сервер — специфика

А где я сказал слово “проблема”?

да. но стоит помнить, что там за бортом оставлкны примерно 70% повседневных задач

спасибо. и за доклад про ФС тоже благодарствую :)

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

А где я сказал слово “проблема”?

> Внезапно, да? навевало на то, что это выглядит забавно

фраза "в большинстве случаев" намекает на то что если им дать разгуляться они сделают еще одно ООП на сях

откуда такие выводы?

от твоей фразы

Есть

далеко необязательно

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

стоит качать? :)

она довольно специфическая, но если каждый вечер разбирать по главе - может быть интересно и полезно

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

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

> Внезапно, да? навевало на то, что это выглядит забавно

В нашей индустрии все выглядит довольно забавно

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

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

а в ядре как будто не делают ООП на сях?

и это даже я сейчас не топлю за фп, который на сях затруднен

а в ядре как будто не делают ООП на сях?

в некоторых задачах делают, почему нет

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

Во внутренностях линукса подобие ООП таки есть

в некоторых задачах делают, почему нет

да ядро это вообще пример того что стало бы в 3 раза меньше если бы было на плюсах

классический

Во внутренностях линукса подобие ООП таки есть

есть, я согласен. Но это не "лучшие практики", это просто еще один подход

еще хороший пример того что из-за недостаточной выразительности языка там дефайн на дефайне и дефайном погоняет

да ядро это вообще пример того что стало бы в 3 раза меньше если бы было на плюсах

плюсы к ядру Линус в жизни не подпустит, и правильно делает

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

вот хороший пример... go - довольно медленный, вы в курсе? быстрые - ява и плюсы

плюсы к ядру Линус в жизни не подпустит, и правильно делает

ваще это ИМХО большая ошибка

потому что тогда бы из него пришлось выкинуть шаблоны и STL и остался бы чистый си с классами

ваще это ИМХО большая ошибка

а я его поддерживаю полностью

и Гвидо поддерживаю, что он С++ не пускает в ядро питона

потому что тогда бы из него пришлось выкинуть шаблоны и STL и остался бы чистый си с классами

абьюзить фичи можно всегда, было бы желание.

вот хороший пример... go - довольно медленный, вы в курсе? быстрые - ява и плюсы

я в курсе, но это всегда трейдофф между скоростью разработки и скоростью работы программы

на го можно писать быстрее, чем на сях, но медленнее, чем на питоне. И производительность сервера будет где-то посередине.

абьюзить фичи можно всегда, было бы желание.

ну, ты согласен, что в общем случае в коде, где критичен каждый байт, C++ STL непригоден, например?

ну, ты согласен, что в общем случае в коде, где критичен каждый байт, C++ STL непригоден, например?

критичен каждый байт чего?

Критичен каждый бит в байте

критичен каждый байт чего?

да чего угодно - памяти, размера скомпленного бинаря

ваще это ИМХО большая ошибка

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

написание драйверов туда же

уровня ядра, разумеется

да чего угодно - памяти, размера скомпленного бинаря

Какие-то куски STL брать нельзя

уровня ядра, разумеется

ну в ядре у тебя и сишной стандартной библиотеки нет и плюсовой не было бы

там никакого C++ не должно быть никогда, имхо

там никакого C++ не должно быть никогда, имхо

Да должен, на плюсах было б компактнее при той же скорости работы

если не быстрее

Какие-то куски STL брать нельзя

процентов 80 минимум

Да должен, на плюсах было б компактнее при той же скорости работы

далеко не факт, что при той же, и далеко не факт, что читабельнее

разве что работа со строками в C++ может быть проще, но в целом это больше сахар

далеко не факт, что при той же, и далеко не факт, что читабельнее

писать ужасный код можно на любом языке, на Си это не сложнее чем на плюсах

писать ужасный код можно на любом языке, на Си это не сложнее чем на плюсах

сложнее. В С++ народ часто полагается на код, который за них уже написали, то есть "средние структуры, которые подходят всем". Ну да, можно умные указатели на коленке сделать. Но в остальном большая часть C++ скорее мешает при написании ясного низкоуровневого кода, чем помогает

шаблоны туда же

сложнее. В С++ народ часто полагается на код, который за них уже написали, то есть "средние структуры, которые подходят всем". Ну да, можно умные указатели на коленке сделать. Но в остальном большая часть C++ скорее мешает при написании ясного низкоуровневого кода, чем помогает

как по мне так не мешает

шаблоны туда же

и с этим я не согласен. Разумное использование шаблонов делает код читабельнее

как по мне так не мешает

вот школьный пример банальный

std::cout во много раз больше подводных камней содержит, чем printf

и он по дефолту медленнее в разы

и с этим я не согласен. Разумное использование шаблонов делает код читабельнее

и где ты видал разумное? едет же крыша у людей

std::cout во много раз больше подводных камней содержит, чем printf

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

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

почему? там что, нет ни ввода, ни вывода? ни логов?

разумеется, буду

и где ты видал разумное? едет же крыша у людей

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

почему? там что, нет ни ввода, ни вывода? ни логов?

Ну наверное потому что я под низкоуровневым кодом понимаю ядро и драйвера

а там у тебя нет ни STL ни stdlib сишных

ERROR: S client not available

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

это, опять же, верно для любого языка, как ты выше написал

это, опять же, верно для любого языка, как ты выше написал

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

а там у тебя нет ни STL ни stdlib сишных

да, но там свои примитивы есть

А значит отказываться от фич - глупо

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

разумеется

да, но там свои примитивы есть

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

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

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

А значит отказываться от фич - глупо

от фич никто и не отказывается, вопрос в том, что понимать под фичами. То, что есть в C++ - это не фичи, это ненужный и неявный сахар

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

да. как позволит Си :)

от фич никто и не отказывается, вопрос в том, что понимать под фичами. То, что есть в C++ - это не фичи, это ненужный и неявный сахар

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

да. как позволит Си :)

если писать проект на плюсах, то как позволят плюсы

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

не всегда, и потом, явное всегда лучше неявного

если писать проект на плюсах, то как позволят плюсы

ну вот комьюнити не одобряет модули ядра на C++. И правильно делает

не всегда, и потом, явное всегда лучше неявного

понимание "явного" и "неявного" довольно субъективно. То что тебе неявно, мне может быть вполне очевидно

ну вот комьюнити не одобряет модули ядра на C++. И правильно делает

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

Я думал это термины такие.

И увеличить читаемость

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

понимание "явного" и "неявного" довольно субъективно. То что тебе неявно, мне может быть вполне очевидно

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

Или вы не про типизацию?

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

ну, это твое мнение :) я с ним не спорю, просто у меня другое

Или вы не про типизацию?

мы про код в целом

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

да я и с этим не согласен :)

>Код на C тупо значит то, что он описывает, поэтому и неоднозначного толкования меньше в разы ахаха.

Ну как то глупо говорить вот это явный код.

А вот это неявный.

Какие-то аспекты языка могут быть такими.

Типа той же типизации.

>Код на C тупо значит то, что он описывает, поэтому и неоднозначного толкования меньше в разы ахаха.

по сравнению с C++ - да, он более простой и понятный

Да варпа лысого.

Какие-то аспекты языка могут быть такими.

ну, мы сравниваем-то с С++, а не с каким-то другим языком

С++ язык выше уровнем.