Здравствуйте, Piko, Вы писали:
P>>>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C. CC>>Слушай, чего ты разоряешься? Хотят писать на С — хай пишут. Это их геморрой.
P>Если честно, хотелось услышать аргументы против. В ответ услышал старые перепетые мифы, и ни одного аргумента
[надевая пенсне]
Ой ну ви таки послушайте наконец старого одесского тролля жителя: таки ничего вам тут нового не скажут! Все их стереотипы провоняли нафталином, ну так и хай они себе дальше грызут свой кактус, если они считают что по вкусу он аккурат как текила.
[снимая пенсне]
Забей. Проще пристрелить чем добиться аргументированного ответа.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
P>И получаем, что std::auto_ptr не валиден. Грустно плачем и несём С++/STL на помоечку?
P>о чём спорить? если косяк в auto_ptr — для тебя это повод нести C++/stdlib на помоечку
Ты тут рассказывал, как надёжно всё можно в С++ выявить и проверить.
Я показал тебе, что твой тест не пройдёт уже стандартная библиотека С++, так что что-то надо на омоечку, либо тест, либо С++ и его стандартную библиотеку
Предложение нести на помоечку не тест, а язык было сарказмом
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Piko, Вы писали:
E>>Интересно, а чувакам, которые в скде говорят, что они не убивали, ты тоже веришь?
P>я не знаю что такое скде
Очевидно, что это "суде" При наборе на сенсорном экране соседние буквы путаются на раз
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, CreatorCray, Вы писали:
CC>Представьте что вы такой крутой С программер, ну скажем, один такой крутой на целый на город. Суровая рукопашка на макросах для имитации автоматики, goto out; goto cleanup; goto error; и т.п.
Суть тут в том, что крутой С-программер рукопашкой на макросах страдает только если ОЧЕНЬ надо, а goto cleanup -- стандартный приём в С, примерно такой же стандартный, как RAII в С++
CC>Круто да? И вдруг вам нужно часть своей работы делегировать кому-то ещё... упс, да?
Ну, если проект нормально написан, то делигируешь без проблем. Впрочем как и на С++, только если он тоже НОРМАЛЬНО написан, а не как локи с STL...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, CreatorCray, Вы писали:
AS>>вместо решения задачи, будет решаться задача как это правильно сделать на С++. CC>Ты путаешь тёплое с мягким. Это верно в обратную сторону — это на С приходится изгаляться чтоб сделать то, что есть в С++.
Тут вы оба не правы, IMHO. КМК это вообще свойство программиста, а не языка -- изгаляться над формой, вместо того, что бы пилить суть
У большинства это от недостатка опыта, и постепенно проходит, но у некоторых не проходит никогда...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
CC>Слушай, чего ты разоряешься? Хотят писать на С — хай пишут. Это их геморрой.
Просто ему статья Страуст. слегка помыла мозг примером qsort vs std::sort. Он даже не верит, что может быть ситуация, когда qsort гибче и когда qsort быстрее
Но я думаю его постепенно отпустит
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Просто ему статья Страуст. слегка помыла мозг примером qsort vs std::sort.
Не думаю. Пример на самом деле отлично демонстрирует разницу между обычной функцией с callback и шаблонной функцией с предикатом.
E> Он даже не верит, что может быть ситуация, когда qsort гибче и когда qsort быстрее
Дык я тоже не верю, мне доказательства нужны.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Erop, Вы писали:
E>Тут вы оба не правы, IMHO. КМК это вообще свойство программиста, а не языка -- изгаляться над формой, вместо того, что бы пилить суть
Скажи, на чём придётся больше внимания уделять "сервисной обвязке": на языке, в котором есть автоматизация рутинных действий и на языке, в котором её нет?
E>У большинства это от недостатка опыта, и постепенно проходит, но у некоторых не проходит никогда...
Оставь этот менторский тон. Он не действует как ты рассчитываешь.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Erop, Вы писали:
CC>>Представьте что вы такой крутой С программер, ну скажем, один такой крутой на целый на город. Суровая рукопашка на макросах для имитации автоматики, goto out; goto cleanup; goto error; и т.п. E>Суть тут в том, что крутой С-программер рукопашкой на макросах страдает только если ОЧЕНЬ надо
Судя по С коду разнообразных проектов, это самое "ОЧЕНЬ надо" случается очень часто. В общем то оно и понятно, не вручную же это всё каждый раз колбасить.
E> а goto cleanup -- стандартный приём в С, примерно такой же стандартный, как RAII в С++
Я ведь не говорю что это пц как плохо. Альтернативы в С очень мало, и goto не самый плохой вариант.
CC>>Круто да? И вдруг вам нужно часть своей работы делегировать кому-то ещё... упс, да? E>Ну, если проект нормально написан, то делигируешь без проблем.
Если ты не заметил, то мой пост практически цитата того, на что я отвечаю. Это было сделано специально чтоб показать оппоненту на нелепость категоричности его заявлений.
E> Впрочем как и на С++, только если он тоже НОРМАЛЬНО написан, а не как локи с STL...
Вооот! Ты начал подходить к правильному ответу: нормально написанный проект делегируется и поддерживается без проблем, вне зависимости написан он на С или на С++.
А вот защищаемый тобой товарищ этого понимать не желает.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
CC>Представьте что вы такой крутой С программер, ну скажем, один такой крутой на целый на город. Суровая рукопашка на макросах для имитации автоматики, goto out; goto cleanup; goto error; и т.п. CC>Круто да? И вдруг вам нужно часть своей работы делегировать кому-то ещё... упс, да?
Нет не упс.
Если вы за своим страхом шаблонов не заметили, что я как раз таки использую подход без этих симпатичных goto... (а не их имитации), это опять же показатель. Собственно, с той же серии, что и заблуждения про RAII, и фантазии про единственно верную и всё включающую модель ОО в С++. Однако, учить я никого здесь не собираю, как и доказывать что бы то ни было. Зачем? ))) Я сюда прихожу 'палочкой потыкать'.
Тем не менее, вы упускаете один маленький, но важный момент. С — язык активно используемый в вузах. В любом известном мне вузе, где готовят программеров, С читается как ключевой элемент программы и на нём выполняется довольно много заданий. С++ — как спецкурс, и в поверхностно. С не требует много времени, C++ же требует минимум два-три года практики для уверенного владения основным ядром конструкций, и пять лет для свободного владения языком. Хотите поспорить про годы практики на С++?
Фактически, студента ещё помнящего алгоритмику и прошедшего курс C вполне можно кидать на освоение предметной области. В случае c++ человек будет вместо работы несколько лет воевать с языком, а затем уйдёт в другую компанию как продвинутый С++ чувак. ))
Здравствуйте, CreatorCray, Вы писали:
AS>>Я сюда не для просвещения страждущих хожу, мне сие с некоторого момента сугубо фиолетово, но троллинга и флуда ради. Короче, поразвлекаться. CC>Ради троллинга вали к троллям в КСВ.
В полоске над сообщением есть иконка такая с бомбочкой ) кликаешь и выбираешь — послать в КСВ. И усё.
CC>>Слушай, чего ты разоряешься? Хотят писать на С — хай пишут. Это их геморрой. P>Если честно, хотелось услышать аргументы против. В ответ услышал старые перепетые мифы, и ни одного аргумента
Аргументы против чего? Самый главный тормоз программы — прокладка между стулом и клавиатурой, это как бы известный факт. Как и то, что С ровно так же лучше чем С++, как и наоборот. Чем лучше? Дык чем С++. )
E>> Он даже не верит, что может быть ситуация, когда qsort гибче и когда qsort быстрее CC>Дык я тоже не верю, мне доказательства нужны.
std::sort штука интересная. Магическая можно сказать.
От только что делать с сортировкой тривиальных объектов, для которых не реализован swap, но по всем правилам реализован конструктор копирования? Что делать с компаратором, сложность которого выше чем сложность копирования? Как-то так сложилось, что qsort не приводит к распуханию кода и выноса его за кэш. В С вот нет конструктора копирования и требований на exception-safe код, что бывает сильно раляет в сравнении. Если сортировать не целые числа ... то std::sort далеко не всегда так крут как хотелось бы некоторым.
Кстати С++, на минуточку, далеко не всегда инлайнит то что хотелось бы программеру. Что бывает несколько неприятно. Как-то помнится в одном жутко шаблоном коде NO_INLINE встречался существенно чаще чем inline ))) Иначе тормозил этот код просто ужасно.
Здравствуйте, Erop, Вы писали:
P>>Действительно: P>>
P>>И получаем, что std::auto_ptr не валиден. Грустно плачем и несём С++/STL на помоечку?
P>>о чём спорить? если косяк в auto_ptr — для тебя это повод нести C++/stdlib на помоечку E>Ты тут рассказывал, как надёжно всё можно в С++ выявить и проверить. E>Я показал тебе, что твой тест не пройдёт уже стандартная библиотека С++, так что что-то надо на омоечку, либо тест, либо С++ и его стандартную библиотеку E>Предложение нести на помоечку не тест, а язык было сарказмом
дык — можно проверить, точно также как и в случае с интерфейсами
ну вот смотри, есть у тебя какая-нибудь чисто OO либа, допустим на Java. Ну вот есть в ней недостаток/недоработка, не покрытый тестами..
И что ты говоришь?? выкидывать всё из-за этого нахрен? нахрен всё OO ?
Здравствуйте, Erop, Вы писали:
E>>>Интересно, а чувакам, которые в скде говорят, что они не убивали, ты тоже веришь? P>>я не знаю что такое скде E>Очевидно, что это "суде" При наборе на сенсорном экране соседние буквы путаются на раз
мне было не очевидно, уж очень на некую аббревиатуру похоже
Здравствуйте, Erop, Вы писали:
CC>>Слушай, чего ты разоряешься? Хотят писать на С — хай пишут. Это их геморрой. E>Просто ему статья Страуст. слегка помыла мозг примером qsort vs std::sort.
пример показательный в плане того как строятся реюзабельные блоки в одном и в другом языке.
и в каком из этих языков "реюзабельность" платная
я приводил и другие примеры, в которых точно такие же проблемы. http://developer.gnome.org/glib/2.32/glib-Balanced-Binary-Trees.html
вот, тот же void*, те же проблемы — это стандартный способ решения этой задачи на C
E>Он даже не верит, что может быть ситуация, когда qsort гибче и когда qsort быстрее
не верю. ты можешь как-то обосновать/доказать свой трёп?
E>Но я думаю его постепенно отпустит
Здравствуйте, Alexéy Sudachén, Вы писали:
CC>>>Слушай, чего ты разоряешься? Хотят писать на С — хай пишут. Это их геморрой. P>>Если честно, хотелось услышать аргументы против. В ответ услышал старые перепетые мифы, и ни одного аргумента
AS>Аргументы против чего?
Потому что очень много низкокачественных C++ программистов (перешедших с C), которые
верят в то, что C быстрее чем C++,
верят в void* и т.п.,
думают что C++ это раздутые OO-иерархии,
могли обжечься 20 лет назад об C++ и этот опыт имеет их до сих пор.
В результате, когда этот сброд слышит embedded, fast, system, kernel — они бездумно используют C.
На сегодняшний день я вижу только следующие места когда можно обоснованно использовать C, а не C++ :
1) Отсутствие компилятора C++
2) В API (причём это не сам C, а только C-style interfaces)
3) В распоряжении есть только программисты знающие C, но не C++
4) Необходимость ковыряться в уже написанном на C проекте
AS>Самый главный тормоз программы — прокладка между стулом и клавиатурой, это как бы известный факт.
не спорю
AS>Как и то, что С ровно так же лучше чем С++, как и наоборот. Чем лучше? Дык чем С++. )
я уже не раз писал: надежностью, скоростью, безопасностью и т.п.
Здравствуйте, Alexéy Sudachén, Вы писали:
E>>> Он даже не верит, что может быть ситуация, когда qsort гибче и когда qsort быстрее CC>>Дык я тоже не верю, мне доказательства нужны. AS>std::sort штука интересная. Магическая можно сказать. AS>От только что делать с сортировкой тривиальных объектов, для которых не реализован swap, но по всем правилам реализован конструктор копирования?
qsort тут вообще ничего не предлагает, только свапает бит за битом
в то же время, как ты правильно заметил std::sort может использовать оптимизированный swap
AS>Что делать с компаратором, сложность которого выше чем сложность копирования?
а что с ним делать на qsort?
AS>Как-то так сложилось, что qsort не приводит к распуханию кода и выноса его за кэш.
если это действительно проблема — то всё прекрасно решается в рамках C++ — почитай performance TR, и всё равно будет надёжный интерфейс, принимающий правильные компараторы и т.п.
AS>В С вот нет конструктора копирования и требований на exception-safe код, что бывает сильно раляет в сравнении. Если сортировать не целые числа ... то std::sort далеко не всегда так крут как хотелось бы некоторым.
ээ... std::sort это лишь пример, что имхо очевидно. и дело тут вовсе не в алгоритме сортировки.
AS>Кстати С++, на минуточку, далеко не всегда инлайнит то что хотелось бы программеру. Что бывает несколько неприятно. Как-то помнится в одном жутко шаблоном коде NO_INLINE встречался существенно чаще чем inline ))) Иначе тормозил этот код просто ужасно.
для этого используются compiler-specific options, типа force inline — один раз пишется макрос на каждый компилятор и всё
Здравствуйте, Alexéy Sudachén, Вы писали:
P>>я приводил и другие примеры, в которых точно такие же проблемы. P>>http://developer.gnome.org/glib/2.32/glib-Balanced-Binary-Trees.html P>>вот, тот же void*, те же проблемы — это стандартный способ решения этой задачи на C AS>У меня только один вопрос, откуда такой мистический страх перед void* и макросами?
страха нет.
это тупо не type-safe, разве не очевидно? (есть и другие, но менее важные причины)