Здравствуйте, Alexey Sudachen, Вы писали:

AS>В полоске над сообщением есть иконка такая с бомбочкой ) кликаешь и выбираешь — послать в КСВ. И усё.
Говны за тобой прибирать интересу нет. Может ты лучше сам туда писать начнёшь?

Здравствуйте, Alexey Sudachen, Вы писали:

AS>Я сюда прихожу 'палочкой потыкать'.
Ещё раз, ходи тыкать палочкой в специально отведённое место.

AS>Тем не менее, вы упускаете один маленький, но важный момент. С — язык активно используемый в вузах. В любом известном мне вузе, где готовят программеров, С читается как ключевой элемент программы и на нём выполняется довольно много заданий. С++ — как спецкурс
Тем хуже для этих вузов.

AS>>Аргументы против чего?
P>

P>Потому что очень много низкокачественных C++ программистов (перешедших с C), которые
P>верят в то, что C быстрее чем C++,
P>верят в void* и т.п.,
P>думают что C++ это раздутые OO-иерархии,
P>могли обжечься 20 лет назад об C++ и этот опыт имеет их до сих пор.
P>В результате, когда этот сброд слышит embedded, fast, system, kernel — они бездумно используют C.

Иначе говоря на С программирует сброд? ))) Такие аргументы это из серии — вы давно перестали бить свою жену?

при сравнении скорости C/C++ быстрее будет программист )))
в void* не надо верить его надо использовать или не использовать, ровно так же как RAII или статически полиморфизм. В С это ровно такая же идиома.
С++ таки способствует раздутым OO иерархиям, фатальый баг реализации обьектности. Аллан Кей как-то сказал что когда создавал концепцию ООП, не имел в виду С++.
Таки C++ лет назад и C++ сейчас — разные языки. Более того если сейчас писать код на C++ как двацать лет назад — сразу получишь обвинение в говнокодерстве. ))))

P>

P>На сегодняшний день я вижу только следующие места когда можно обоснованно использовать C, а не C++ :
P>1) Отсутствие компилятора C++
P>2) В API (причём это не сам C, а только C-style interfaces)
P>3) В распоряжении есть только программисты знающие C, но не C++
P>4) Необходимость ковыряться в уже написанном на C проекте

P>[/q]

AS>>Как и то, что С ровно так же лучше чем С++, как и наоборот. Чем лучше? Дык чем С++. )
P>я уже не раз писал: надежностью, скоростью, безопасностью и т.п.

Есть такая штука, называется статически неустойчивая аэродинамика. Все современные истребители нуждающиеся в предельной манёвренности строятся по такой схеме. Дык вот С — это такой истребитель, С++ же в сравнении С, — пасажирский авиалайнер. С имеет предельную манёвренность, C++ — предельную статическую устойчивость. От только проблема — авиалайнер-то он конечно авиалайнер, но передаланный с истребителя ))) что иногда бывает шокирует не только пилота, но и пассажиров. Фактически пилот шоб рулить такой хреновиной должен уметь летать ваще на всём.

То есть ты не все варианты перечислил.

Здравствуйте, CreatorCray, Вы писали:

E>>Тут вы оба не правы, IMHO. КМК это вообще свойство программиста, а не языка -- изгаляться над формой, вместо того, что бы пилить суть
CC>Скажи, на чём придётся больше внимания уделять "сервисной обвязке": на языке, в котором есть автоматизация рутинных действий и на языке, в котором её нет?

В нормальных программах это всё составляет не очень большую часть трудозатрат, так что пофиг на самом деле.
Непринципиально отличается. Но для того, что бы программы стали "нормально написанными" нужен опыт, но некоторым и опыт не помогает. Будешь спорить?

E>>У большинства это от недостатка опыта, и постепенно проходит, но у некоторых не проходит никогда...
CC>Оставь этот менторский тон. Он не действует как ты рассчитываешь.
Я думаю, что он злит коллег, которые обсуждают персоны, а не идеи...

Здравствуйте, CreatorCray, Вы писали:

CC>А вот защищаемый тобой товарищ этого понимать не желает.

Это твоя главная ошибка в дискуссии. Я никого не защищаю. Я просто считаю, что преимущества того самого подмножества С неожиданно не так уж и велики...

AS>>От только что делать с сортировкой тривиальных объектов, для которых не реализован swap, но по всем правилам реализован конструктор копирования?
P>qsort тут вообще ничего не предлагает, только свапает бит за битом
P>в то же время, как ты правильно заметил std::sort может использовать оптимизированный swap

И? Надо сделать довольно большое колическтво работы, которую обычно никто не делает. Просто потенциальная возможность очень мало когда имеет значение.

AS>>Что делать с компаратором, сложность которого выше чем сложность копирования?
P>а что с ним делать на qsort?
Ничего, но возможность подстановок которая деклариуется в этом случае как основной плюс, не даст ровным счётом ничего.

AS>>Как-то так сложилось, что qsort не приводит к распуханию кода и выноса его за кэш.
P>если это действительно проблема — то всё прекрасно решается в рамках C++ — почитай performance TR, и всё равно будет надёжный интерфейс, принимающий правильные компараторы и т.п.

Это действительно проблема. Но вот как-то так сложилось, что я пишу не на стандарте и других писульках коммитета, а не реальных компилерах. И как-то от не получается оно. Очень показательна в этом плане была GRETA. И понятно что оно решается. Ровно тем же способом что и удаление гландов через задний проход. )))

AS>>В С вот нет конструктора копирования и требований на exception-safe код, что бывает сильно раляет в сравнении. Если сортировать не целые числа ... то std::sort далеко не всегда так крут как хотелось бы некоторым.
P>ээ... std::sort это лишь пример, что имхо очевидно. и дело тут вовсе не в алгоритме сортировки.

О... таки всего лишь пример, и всё очевидно? Ну тогда давайте перестанем рассмативать std::sort как пример, и больше не будет упоминать? ОК?!

AS>>Кстати С++, на минуточку, далеко не всегда инлайнит то что хотелось бы программеру. Что бывает несколько неприятно. Как-то помнится в одном жутко шаблоном коде NO_INLINE встречался существенно чаще чем inline ))) Иначе тормозил этот код просто ужасно.
P>для этого используются compiler-specific options, типа force inline — один раз пишется макрос на каждый компилятор и всё

Э... я даже не знаю даже чего и сказать. Я как бы о том что практика показала, что инлайнинг не только добро но и очень даже себе зло, а в ответ получил нотацию что типа в каждом компилере макрос который может сделать force inline... Мы точно друг друга поняли?!

P>>>вот, тот же void*, те же проблемы — это стандартный способ решения этой задачи на C
AS>>У меня только один вопрос, откуда такой мистический страх перед void* и макросами?
P>страха нет.
P>это тупо не type-safe, разве не очевидно? (есть и другие, но менее важные причины)

Нет не очевидно. Type-safe это что такое магическое заклинание? Не, не слышал ))))

P>может ли компаратор сравнивающий double, скомпилироваться вместе с int массивом?

Вот можно в С++ лёгким росчерком пера нарваться нарушение ODR, и скомпилировать код пользующиий совсем не ту структуру какую хотелось? Да легко. Чем монструознее софтина и больше программеров. И куда интересно подевалась это хвалёная типа безопасность?

AS>>Я сюда прихожу 'палочкой потыкать'.
CC>Ещё раз, ходи тыкать палочкой в специально отведённое место.

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

AS>>Тем не менее, вы упускаете один маленький, но важный момент. С — язык активно используемый в вузах. В любом известном мне вузе, где готовят программеров, С читается как ключевой элемент программы и на нём выполняется довольно много заданий. С++ — как спецкурс
CC>Тем хуже для этих вузов.

Дык, хто ж спорит. Хуже для вузов, хуже для компаний, хуже для рынка... Как несправедлива жизнь однако.

Здравствуйте, Alexey Sudachen, Вы писали:

AS>в void* не надо верить его надо использовать или не использовать
Речь не о том, использовать или нет. А о том, что использовать везде void* довольно таки неудобно, но в С выбора то и нету.

AS>Таки C++ лет назад и C++ сейчас — разные языки. Более того если сейчас писать код на C++ как двацать лет назад — сразу получишь обвинение в говнокодерстве. ))))
От спасибо, Кэп!

Здравствуйте, Erop, Вы писали:

E>>>Тут вы оба не правы, IMHO. КМК это вообще свойство программиста, а не языка -- изгаляться над формой, вместо того, что бы пилить суть
CC>>Скажи, на чём придётся больше внимания уделять "сервисной обвязке": на языке, в котором есть автоматизация рутинных действий и на языке, в котором её нет?
E>В нормальных программах это всё составляет не очень большую часть трудозатрат, так что пофиг на самом деле.
В нормальных это в каких? По мне так эта часть достаточно крупная чтоб заколебать через некоторое время. Всё то, что на плюсах делается контейнерами, RAII и прочими простыми упрощениями жизни тут приходится колбасить вручную каждый раз. Или делать на макросах, отлаживать которые потом то ещё развлечение.

E>>>У большинства это от недостатка опыта, и постепенно проходит, но у некоторых не проходит никогда...
CC>>Оставь этот менторский тон. Он не действует как ты рассчитываешь.
E>Я думаю, что он злит коллег, которые обсуждают персоны, а не идеи...
Значит он способствует скатыванию темы в простой срач.
Тем более оставь.

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>>>Аргументы против чего?
P>>

P>>Потому что очень много низкокачественных C++ программистов (перешедших с C), которые
P>>верят в то, что C быстрее чем C++,
P>>верят в void* и т.п.,
P>>думают что C++ это раздутые OO-иерархии,
P>>могли обжечься 20 лет назад об C++ и этот опыт имеет их до сих пор.
P>>В результате, когда этот сброд слышит embedded, fast, system, kernel — они бездумно используют C.

AS>Иначе говоря на С программирует сброд? )))

сброд — это те, кто бездумно использует и тупо верит в мифы.
ещё раз:

На сегодняшний день я вижу только следующие места когда можно обоснованно использовать C, а не C++ :
1) Отсутствие компилятора C++
2) В API (причём это не сам C, а только C-style interfaces)
3) В распоряжении есть только программисты знающие C, но не C++
4) Необходимость ковыряться в уже написанном на C проекте

AS>при сравнении скорости C/C++ быстрее будет программист )))

здесь все оппоненты "защищающие" С, переходят в сферический вакуум, к пятнистым поням?

AS>в void* не надо верить его надо использовать или не использовать, ровно так же как RAII или статически полиморфизм. В С это ровно такая же идиома.

а теперь ещё раз:

Потому что очень много низкокачественных C++ программистов (перешедших с C), которые

"вера в void*" заключается в использовании его где не попадая. ты не поверишь, но многие считает чем более low-level код — тем более быстр. они отождествляют void* (так как самый что ни на есть low-level) с производительностью. это всё я и называю верой.

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

AS>С++ таки способствует раздутым OO иерархиям, фатальый баг реализации обьектности.

чем именно он способствует?

AS>Аллан Кей как-то сказал что когда создавал концепцию ООП, не имел в виду С++.

ну и?

AS>Таки C++ лет назад и C++ сейчас — разные языки. Более того если сейчас писать код на C++ как двацать лет назад — сразу получишь обвинение в говнокодерстве. ))))

это смотря как и кто писал двадцать лет назад

AS>>>Как и то, что С ровно так же лучше чем С++, как и наоборот. Чем лучше? Дык чем С++. )
P>>я уже не раз писал: надежностью, скоростью, безопасностью и т.п.
AS>Есть такая штука, называется статически неустойчивая аэродинамика. Все современные истребители нуждающиеся в предельной манёвренности строятся по такой схеме. Дык вот С — это такой истребитель, С++ же в сравнении С, — пасажирский авиалайнер. С имеет предельную манёвренность, C++ — предельную статическую устойчивость.

давай ты спустишься со сферических турбулентных облаков, и перечислишь по пунктам то, что даёт манёвренность в C, ок?
а потом мы пройдёмся по этим пунктам, и посмотрим, было ли это такой уже добродетелью или тупо жёсткой необходимостью для латания дыр в обшивке. и какие альтернативы есть в C++, потеряли ли они что-то в "манёвренности" или наоборот улучшили её

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>>>От только что делать с сортировкой тривиальных объектов, для которых не реализован swap, но по всем правилам реализован конструктор копирования?
P>>qsort тут вообще ничего не предлагает, только свапает бит за битом
P>>в то же время, как ты правильно заметил std::sort может использовать оптимизированный swap
AS>И? Надо сделать довольно большое колическтво работы, которую обычно никто не делает. Просто потенциальная возможность очень мало когда имеет значение.

кто-то использует, кто-то нет. но возможность есть, чего не скажешь о qsort


AS>>>Что делать с компаратором, сложность которого выше чем сложность копирования?
P>>а что с ним делать на qsort?
AS>Ничего, но возможность подстановок которая деклариуется в этом случае как основной плюс, не даст ровным счётом ничего.

то есть объективно ты согласен, что есть более богатые возможности для реиспользования, так?

AS>>>Как-то так сложилось, что qsort не приводит к распуханию кода и выноса его за кэш.
P>>если это действительно проблема — то всё прекрасно решается в рамках C++ — почитай performance TR, и всё равно будет надёжный интерфейс, принимающий правильные компараторы и т.п.
AS>Это действительно проблема. Но вот как-то так сложилось, что я пишу не на стандарте и других писульках коммитета, а не реальных компилерах. И как-то от не получается оно. Очень показательна в этом плане была GRETA. И понятно что оно решается. Ровно тем же способом что и удаление гландов через задний проход. )))

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

AS>>>В С вот нет конструктора копирования и требований на exception-safe код, что бывает сильно раляет в сравнении. Если сортировать не целые числа ... то std::sort далеко не всегда так крут как хотелось бы некоторым.
P>>ээ... std::sort это лишь пример, что имхо очевидно. и дело тут вовсе не в алгоритме сортировки.
AS>О... таки всего лишь пример, и всё очевидно?

ты начал скатываться к конкретному алгоритму стоящему за std::sort, хотя очевидно было, что дело не в нём

AS>Ну тогда давайте перестанем рассмативать std::sort как пример, и больше не будет упоминать? ОК?!

ок, но сначала ответь, желательно с аргументами: qsort vs std::sort
1. что быстрее
2. что надёжней
3. что безопасней
4. что более абстрактно
?

AS>>>Кстати С++, на минуточку, далеко не всегда инлайнит то что хотелось бы программеру. Что бывает несколько неприятно. Как-то помнится в одном жутко шаблоном коде NO_INLINE встречался существенно чаще чем inline ))) Иначе тормозил этот код просто ужасно.
P>>для этого используются compiler-specific options, типа force inline — один раз пишется макрос на каждый компилятор и всё

AS>Э... я даже не знаю даже чего и сказать. Я как бы о том что практика показала, что инлайнинг не только добро но и очень даже себе зло, а в ответ получил нотацию что типа в каждом компилере макрос который может сделать force inline... Мы точно друг друга поняли?!

и не только force inline, но и noinline

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

Здравствуйте, Alexéy Sudachén, Вы писали:

P>>>>вот, тот же void*, те же проблемы — это стандартный способ решения этой задачи на C
AS>>>У меня только один вопрос, откуда такой мистический страх перед void* и макросами?
P>>страха нет.
P>>это тупо не type-safe, разве не очевидно? (есть и другие, но менее важные причины)
AS>Нет не очевидно. Type-safe это что такое магическое заклинание? Не, не слышал ))))

а type rich interfaces?

P>>может ли компаратор сравнивающий double, скомпилироваться вместе с int массивом?
AS>Вот можно в С++ лёгким росчерком пера нарваться нарушение ODR, и скомпилировать код пользующиий совсем не ту структуру какую хотелось? Да легко. Чем монструознее софтина и больше программеров. И куда интересно подевалась это хвалёная типа безопасность?

мастер ухода от ответа 4го разряда

AS>>при сравнении скорости C/C++ быстрее будет программист )))
P>здесь все оппоненты "защищающие" С, переходят в сферический вакуум, к пятнистым поням?

Угу, тем более что это так и есть (про программиста, а не про оппонентов).

P>"вера в void*" заключается в использовании его где не попадая. ты не поверишь, но многие считает чем более low-level код — тем более быстр. они отождествляют void* (так как самый что ни на есть low-level) с производительностью. это всё я и называю верой.

Ты это сами придумал, или где-то прочитал? Если сам, то как часто ты пишешь на так нелюбимом тобой С, что бы знать во что верят С-программеры? Обожаю людей которые допридумывают за оппонентов. С другой стороны, почему бы и нет. Довольно забавно получается.

AS>>С++ таки способствует раздутым OO иерархиям, фатальый баг реализации обьектности.
P>чем именно он способствует?
AS>>Аллан Кей как-то сказал что когда создавал концепцию ООП, не имел в виду С++.
P>ну и?

Да не, ничё. ))) Забудь. Лениво мне эту тему развивать.

AS>>Таки C++ лет назад и C++ сейчас — разные языки. Более того если сейчас писать код на C++ как двацать лет назад — сразу получишь обвинение в говнокодерстве. ))))
P>это смотря как и кто писал двадцать лет назад

Да? Ну вот как бы камрад СС считает что сие совершенно очевидно. )))

P>давай ты спустишься со сферических турбулентных облаков, и перечислишь по пунктам то, что даёт манёвренность в C, ок?
P>а потом мы пройдёмся по этим пунктам, и посмотрим, было ли это такой уже добродетелью или тупо жёсткой необходимостью для латания дыр в обшивке. и какие альтернативы есть в C++, потеряли ли они что-то в "манёвренности" или наоборот улучшили её

А зачем, мне в метафорах интереснее ))) К тому же я ничего не доказываю, просто изгаляюсь над примитивизмом основной идеи флейма и её обоснованием. Уж на столько всё просто, что должно бы быть очевидно любому идиоту, дык пойди ж ты, оказывается периодически всплывают таки кому не очевидно )))) Это наверное всё те низкокачественные программисты что перешли с С. )))

AS>>Ну тогда давайте перестанем рассмативать std::sort как пример, и больше не будет упоминать? ОК?!

P>ок, но сначала ответь, желательно с аргументами: qsort vs std::sort
P>1. что быстрее
P>2. что надёжней
P>3. что безопасней
P>4. что более абстрактно
P>?

Java.

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>>>Ну тогда давайте перестанем рассмативать std::sort как пример, и больше не будет упоминать? ОК?!
P>>ок, но сначала ответь, желательно с аргументами: qsort vs std::sort
P>>1. что быстрее
P>>2. что надёжней
P>>3. что безопасней
P>>4. что более абстрактно
P>>?
AS>Java.

ну то есть я понял, нажимаю на кнопку бачка..

AS>>>>У меня только один вопрос, откуда такой мистический страх перед void* и макросами?
P>>>страха нет.
P>>>это тупо не type-safe, разве не очевидно? (есть и другие, но менее важные причины)
AS>>Нет не очевидно. Type-safe это что такое магическое заклинание? Не, не слышал ))))
P>а type rich interfaces?

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

P>>>может ли компаратор сравнивающий double, скомпилироваться вместе с int массивом?
AS>>Вот можно в С++ лёгким росчерком пера нарваться нарушение ODR, и скомпилировать код пользующиий совсем не ту структуру какую хотелось? Да легко. Чем монструознее софтина и больше программеров. И куда интересно подевалась это хвалёная типа безопасность?
P>мастер ухода от ответа 4го разряда

А ты думал. Однако, куда таки девается 'типА безопасность'?

AS>>>>Ну тогда давайте перестанем рассмативать std::sort как пример, и больше не будет упоминать? ОК?!
P>>>ок, но сначала ответь, желательно с аргументами: qsort vs std::sort
P>>>1. что быстрее
P>>>2. что надёжней
P>>>3. что безопасней
P>>>4. что более абстрактно
P>>>?
AS>>Java.

P>ну то есть я понял, нажимаю на кнопку бачка..

Да хоть вентитль. С++ настолько же надёжен и безопасен как и ассемблер. Это факт установленный эмперически, просто существуют разные мифы что путём некоторых заклинаний можно сделать код абстрактно надёжно-безопасным. От только корка, как истина в последней инстанции, показыает что это именно что миф.

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

Здравствуйте, Alexéy Sudachén, Вы писали:

P>>"вера в void*" заключается в использовании его где не попадая. ты не поверишь, но многие считает чем более low-level код — тем более быстр. они отождествляют void* (так как самый что ни на есть low-level) с производительностью. это всё я и называю верой.
AS>Ты это сами придумал, или где-то прочитал? Если сам, то как часто ты пишешь на так нелюбимом тобой С, что бы знать во что верят С-программеры? Обожаю людей которые допридумывают за оппонентов. С другой стороны, почему бы и нет. Довольно забавно получается.

а теперь протираем глаза, и читаем:

http://www.rsdn.ru/forum/flame/4784642.1.aspx

Автор: Piko
Дата: 19.06.12

Потому что очень много низкокачественных C++ программистов (перешедших с C), которые
верят в то, что C быстрее чем C++,
верят в void* и т.п.,

P>>давай ты спустишься со сферических турбулентных облаков, и перечислишь по пунктам то, что даёт манёвренность в C, ок?
P>>а потом мы пройдёмся по этим пунктам, и посмотрим, было ли это такой уже добродетелью или тупо жёсткой необходимостью для латания дыр в обшивке. и какие альтернативы есть в C++, потеряли ли они что-то в "манёвренности" или наоборот улучшили её
AS>А зачем, мне в метафорах интереснее ))) К тому же я ничего не доказываю, просто изгаляюсь над примитивизмом основной идеи флейма и её обоснованием. Уж на столько всё просто, что должно бы быть очевидно любому идиоту, дык пойди ж ты, оказывается периодически всплывают таки кому не очевидно )))) Это наверное всё те низкокачественные программисты что перешли с С. )))

я не считаю эту дискуссию бесполезной.
1. я как уже сказал, всё больше убеждаюсь что с другой стороны объективных аргументов нет. после вдалбливания, и разжёвывания что и почему является быстрее и надёжней, оппоненты глотатают антипопоболь, делают отчаянные попытки спасти остатки своей моральной устойчивости, и начинают щебетать что-то типа "скорость редко нужна"/"более лучшая применимость не нужна"/"да у вас вообще есть auto_ptr"/etc.
2. больше людей будут aware -> будет больше хорошего кода -> мир, зелёная травка

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Абстрактность вообще в статическую типизацию не то чтобы плохо лжится, но весьма с трудом запихивается. )))

STL статически типизирован(практически полностью), и при этом абстрактен