Здравствуйте, Piko, Вы писали:
P>Вот вы кстати упоминали динамические языки в соседней теме. P>Во многих из них есть точно такой же duck-typing, но в C++ этот duck-typing времени компиляции, а не исполнения.
Дык и какая разница? Всё равно баги только при тестировании вылезут...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
P>>Вот вы кстати упоминали динамические языки в соседней теме. P>>Во многих из них есть точно такой же duck-typing, но в C++ этот duck-typing времени компиляции, а не исполнения. E>Дык и какая разница? Всё равно баги только при тестировании вылезут...
Здравствуйте, Piko, Вы писали:
E>>Дык и какая разница? Всё равно баги только при тестировании вылезут...
P>someDuckTypeCrap.quack();
P>шаблоны — ошибка compile-time P>динамическая типизация — run-time P>
Ага-ага.
std::vector<std::auto_ptr<quack_T> > ups;
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
И чё? Этаа штука разложит всё хорошо по ядрам, не нарушит паттерны доступа к памяти и эффективно заюзает память текстур?
что-то я не верю. Они просто собирают ядро тупо, и всё.
E>>Никого, поросто руками ядро прогер напишет и всё.
P>на каждое встретившееся выражение напишет? А потом каждое перепишет на новую архитектуру? P>ну так я о том и говорю, кода на порядки больше.
Ну при такой безумной архитектуре да. На порядки. Но обычно выделяют какие-то операции и вперёд, потом пишут на них...
P>Ага, вот купил чувак допустим ansys, и solver ему говорит: "ты скопируй пожалуйста вот эти матрицы, вектора и выражения в MathCad, а мне результат скажешь".
А зачем коду ansys выглядеть, как матрицы с плюсиками?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>>>Дык и какая разница? Всё равно баги только при тестировании вылезут... P>>someDuckTypeCrap.quack(); P>>шаблоны — ошибка compile-time P>>динамическая типизация — run-time P>>
E>Ага-ага. E>std::vector<std::auto_ptr<quack_T> > ups;
точно такой же баг возможен и без duck-typing — например есть интерфейс с методом copy, и есть класс который реализует этот copy как move, либо вообще как remove.
duck-typing не причём
P>>пожалуйста, только там Cuda http://graphics.tu-bs.de/media/publications/wenger2011cuda.pdf (я бы делал на OpenCL, ибо не надо таскать с собой компилятор) P>> E>И чё? Этаа штука разложит всё хорошо по ядрам, не нарушит паттерны доступа к памяти и эффективно заюзает память текстур? E>что-то я не верю. Они просто собирают ядро тупо, и всё.
эта штука proof-of-concept, у них только сложения векторов и умножение на скаляр.
При сложении векторов/умножению на скаляр, доступ к памяти наипростейший, всё прекрасно coalesced.
Насколько я помню, память текстур не нужно юзать уже года как два, так как добавили кэш (раньше он был только для текстурной памяти), но в этом примере кэш вообще не решает.
решает то, что если есть несколько десятков разных выражений — для каждого строится оптимальное ядро.
подобные принципы можно применять и для более сложных задач, например spmv, gemm, и т.п.
E>>>Никого, поросто руками ядро прогер напишет и всё. P>>на каждое встретившееся выражение напишет? А потом каждое перепишет на новую архитектуру? P>>ну так я о том и говорю, кода на порядки больше. E>Ну при такой безумной архитектуре да. На порядки. Но обычно выделяют какие-то операции и вперёд, потом пишут на них...
ну вот в случае сложения с векторами, ну выделили вы vec_add(v1,v2), и как вы теперь сделаете сложение 5 векторов?
vec_add(vec_add(vec_add(vec_add(v1,v2),v3),v4)
?
а ничего что это почти в два раза медленней чем одним ядром?
P>>Ага, вот купил чувак допустим ansys, и solver ему говорит: "ты скопируй пожалуйста вот эти матрицы, вектора и выражения в MathCad, а мне результат скажешь". E>А зачем коду ansys выглядеть, как матрицы с плюсиками?
эти матрицы с плюсиками:
1. более читабельны, ближе к языку решаемой проблемы
2. выражают семантику намерений напрямую — соответственно могут лениво вычисляться, блокироваться, и т.д, причём автоматом.
3. легче расширять на новые наборы инструкций
P>эти матрицы с плюсиками: P>1. более читабельны, ближе к языку решаемой проблемы P>2. выражают семантику намерений напрямую — соответственно могут лениво вычисляться, блокироваться, и т.д, причём автоматом. P>3. легче расширять на новые наборы инструкций
Здравствуйте, Piko, Вы писали:
P>точно такой же баг возможен и без duck-typing — например есть интерфейс с методом copy, и есть класс который реализует этот copy как move, либо вообще как remove.
Это легко формально проверяется и требуется.
P>duck-typing не причём
Наверное, а шаблоны С++ при чём...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Piko, Вы писали:
P>>эти матрицы с плюсиками: P>>1. более читабельны, ближе к языку решаемой проблемы P>>2. выражают семантику намерений напрямую — соответственно могут лениво вычисляться, блокироваться, и т.д, причём автоматом. P>>3. легче расширять на новые наборы инструкций P>4. на порядок меньше кода чем в Fortran/C
5. к матрицам(столбцам), векторам и т.п., можно добавить единицы измерения — использование векторов/матриц с неправильными единицами измерения ловится в compile-time
Здравствуйте, Erop, Вы писали:
P>>точно такой же баг возможен и без duck-typing — например есть интерфейс с методом copy, и есть класс который реализует этот copy как move, либо вообще как remove. E>Это легко формально проверяется и требуется.
как именно?
как проверишь то, что этот метод copy не отформатирует диск?
P>>duck-typing не причём E>Наверное, а шаблоны С++ при чём...
Здравствуйте, Piko, Вы писали:
E>>Ага-ага. E>>std::vector<std::auto_ptr<quack_T> > ups;
P>точно такой же баг возможен и без duck-typing — например есть интерфейс с методом copy, и есть класс который реализует этот copy как move, либо вообще как remove. P>duck-typing не причём
При чём, при чём.
Вот смотри, если есть интерфейс, то мы можем формально описать его свойства, и даже формально их как-то проверить, например юнит-тестами... Или ещё как-нибудь.
В любом случае для всех объектов, которые поддерживают тот интерфейс, нам надо проверить корректность его поддержания. При этом факт поддержания всегда заявлен явно, так что понятно что где и как проверять. А в функции мы только формально опять же требуем на вход интерфейс и всё.
Во-первых, ошибка хорошо локализуется, во-вторых, хорошо делится ответственность...
А в случе шаблонов фиг чего и где потребуешь, а если и потребуешь, то это бует всё равно на втой страх и риск и только. Формально среда разработки тебе не поможет...
Понятно, что на std::vector ответственность ты не переложишь, но если это будет какой-то твой шаблон, который неожиданным для тебя образом заюзали, то будет очень трудно понять, чь это ошибка. Твоя, что не предусмотрел и такой сценарий, или того, кто этот сценарий воплотил...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
P>? P>а ничего что это почти в два раза медленней чем одним ядром?
Блин, ну что за криворукость-то? А как это запраграммировать, если шаблонов нет? Сам придумаешь?
P>1. более читабельны, ближе к языку решаемой проблемы
Это мифическое преимущество. Всякие тем add и dp не менее читабельны...
Тем более, что многие операторы ты всё равно не запишешь на С++. Ну, как, например, обратную матрицу записать?
P>2. выражают семантику намерений напрямую — соответственно могут лениво вычисляться, блокироваться, и т.д, причём автоматом.
Почему ты считаешь, что автоматом решать что там надо считать, а что нет лучше, чем если таки программист подумает и напишет оптимальный код?
P>3. легче расширять на новые наборы инструкций
Тоже неправда.
Переписывать надо будет только те функции, в которых есть ядра...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, 11molniev, Вы писали:
1>>Позволю себе частично с вами не согласиться, все достаточно сильно зависит от решаемых задач. Бесспорно, грамотный код на С++, при реализации дублирующихся функций будет компактней, безопасней и во всех остальных отношениях (кроме, возможно сложности) лучше. Но если функциональность не дублируется или дублируется с мелкими изменениями, выходит, что приплюснутого кода получается больше, иногда ещё и с ущербом для скорости и читабельности.
E>Не понимаю, в чём тут отличие С и С++ даже, а не С и С-подобного подмножества С++ E>Мне так кажется, что у всех сторонников С в голове всё время сидят С++-темплейты. А их можно вообще не использовать, ну или использовать очень очень ограниченно, там где они реально рулят и дают огромные преимущества, например...
По факту отличий два:
1. Простой (ограниченный) синтаксис.
2. Полная предсказуемость поведения.
E>С++ намного больше, чем шаблоны и ООП. Там ещё есть строгая типизация, перегруженные функции, тип CComplex, можно написать нормальную строчку или класс данных, содержащий изображения, например, и т. д... E>Опять же RAII и исключения всякие могут рассматриваться...
Вот это как раз и есть 1 и 2 пункты выше. E>То есть есть некоторый даже не "С с классами", а "С с классами, но не с объектами". И он вроде как таки лучше С, при этом он позволяет писать всё то же, что и на С, и в общем-то так же, только проще, безопаснее, выразительнее и т. д...
Беда людей, которые отрицают С именно в непонимании отличий, что я назвал. Когда я хочу получать только то что хочу — я предпочитаю С. Если мне нужна краткая запись & RAII — я выберу С++.
Вы пытаетесь мне объяснить преимущества С++ — но я ведь пишу программы и на нём. И знаю эти преимущества. И мне нравиться ими пользоваться. Но иногда я использую чистый С — разве в этом есть что-то плохое?
E>Плохо, что мало есть средств автоматического ограничения С++ таким образом.
А зачем они вообще нужны? Зачем пытаться использовать С++ отказываясь от отдельных элементов языка?
Просто есть люди которые первым языком изучали С++ — им им тяжело отказываться от его преимуществ. Я думаю от того и идут заявления — пишите на ++, а не на С.
E>Я бы, например, как менеджер, хотел бы иметь в С++ проекте какой-то профиль, в котором было бы размечено, чего из зыка можно юзать, а чего нет. И на выход в каком-то куске кода в продакшен-сборке, требовалась бы цыфровая подпись куска каким-то начальником или экспертом...
E>Но такого рода инструментов в С++ вообще нет...
1>>Если уж совсем грубо, то плюсы можно сравнить с архиватором — сжатие (улучшение параметров) зависит от контента и результат может оказаться больше оригинала (при этом ещё и время на распаковку будет тратиться).
E>Ну так это только при бездумном использовании инструмента. Причём любого. В микроскоп прекрасно видно бактерии, но орехи им колоть неудобно, а соседское окно, так и вовсе не видно...
Просто входные данные бывают разными ))
Здравствуйте, Piko, Вы писали:
P>Здравствуйте, 11molniev, Вы писали:
P>>>>>то что цитата в вопросе вырвана из контекста, я уже писал 1>>>>Ну сделайте голосовалку не вырванную из контекста. Я чем этому мешаю? P>>>а смысл? вот буквально ниже: P>>>>>итого, мою точку зрения поддерживают 32.5% (даже при "плохой" постановке вопроса) P>>>>>и? 1>>>>Привет им. Мног8ие считают, что питон быстрей всех языков в мире. P>>>вы приравниваете людей разделяющих мою точку зрения к баранами 1>>Нет, просто я обращаю внимание, что большинство участников этого форума имеют значительный опыт и знание, и их мнение стоит слышать. И ставить выше мнения отдельных товарищей.
P>то есть 67.5% имеют значительный опыт и знание, а 32.5% это бараны?
а 32.5% имеют меньший опыт, могут заблуждатся или иначе трактовать вопрос... Мне кажется очевидным, что кто то имеет больший опыт/знания, а кто то меньший и ваше желание оскорбить людей мне совершенно не понятно.
Здравствуйте, Piko, Вы писали:
P>Здравствуйте, 11molniev, Вы писали:
P>>>>>смотрим моё утверждение в этом топике: 1>>>>Ваше утверждение это самый серьезный пруф, который я только видел. P>>> P>>>у вас в голове контекст вообще мизерный, что-ли? 1>>Так вы в той ветки так и не смогли написать код на С++, быстрей кода на С.
P>вам уже объясняли, и не только я: P>http://www.rsdn.ru/forum/cpp/4735187.1.aspx
1>>> P>Так что быстрее? std::sort (C++ style) vs qsort (C-style) ?
1>>> Они идентичны, если речь идёт о стандарте, Если не стандарт, то некоторые
1>>> реализации qsort сливают.
MZ>>Как бы ты не прав. Они НЕ идентичны. С++ный шаблоный код потенциально
MZ>>быстрее, т.к. там возможно встраивание кода функции сравнения, и
MZ>>прочие оптимизации, отсюда вытекающие. Также С++ный код знает
MZ>>ТИП массива, а С-шный -- не знает. Тоже могут быть оптимизации.
MZ>>Конечно, С-шный код в принципе тоже может это соптимизнуть,
MZ>>но только это должен быть ОЧЕНЬ умный компилятор.
P>а теперь конкретно про тот пример, сколько кода добавится в вашем случае если нужно отсортировать ещё float'ы, double'ы, несколько структур? И сколько в случае C++?
А вам в каждой программе необходимо отсортировать "ещё float'ы, double'ы, несколько структур"? Лично я за последние пару лет ни qsort, ни std::sort не пользовался. Пользовался order by в linq & sql — это да. А вот в С/С++... нет.
P>>>>>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.
P>>>>>что вам не ясно-то? 1>>>>Мне не ясно, почему вы не думаете головой. пытаетесь противоречить фактам. P>>>каким фактам? 1>>1. Любой код на С++ представим эквивалентным кодом на С. 1>>2. Код на С++ и эквивалентный на С при компиляции дадут идентичный машинный код (если вы знаете, что это). 1>>3. Идентичный машинный код имеет идентичную скорость.
P>4. эквивалентный код на C может быть в 10/100/1000 раз больше, и зачастую не пишется
Чё так мало то? Если у вас так сильно дублируеться код могу только сочувствовать.
P>>>
P>>>Ну так там где в C возможно compile-time, оно возможно и в C++, причём в C++ — оно может достигается намного легче/лучше/красивее, а может намного тяжелее/хуже/уродливей
P>>>Вы с этим согласны/не согласны? 1>>Да, с исправленным мной согласен.
P>вы исправили мой текст, facepalm..
Ну а вы мой. В расчете?
P>"а может намного тяжелее/хуже/уродливей" P>как оно вообще может достигаться уродливей, если C по большей части является подмножеством C++ ?
Использованием не того подмножества И кстати С и С++ — это пересекающиеся множества, а не один подмножество другого.
P>>>>>вы хотели подтвердить моё высказывание своим опросом? 1>>>>Что 2/3 посетителей этого форума с вами совсем не согласны.
P>>>ну и?: P>>>
P>>>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.
1>>Вы повторяете это как мантру только на этом форуме, каждое сообщение, или в жизне тоже? Я не хочу вас обидеть, но ИМХО: у вас нет опыта практической работы. А информацию о распространеном заблуждении вы почерпнули из книжки/лекций/форумов.
P>мне не раз отвечали на вопрос почему они не используют средства C++, тем что считают их медленными. на что, я показывал идентичный ассемблерный листинг при намного меньшем коде
Если вы знаете, что токае ассемблерный листинг, то уж должны то понимать, почему на С++ нельзя писать код более быстрый, чем на С. Равный да. Медленней да. Быстрей нет.
P>на ваше имхо, могу ответить "аналогичным" своим: вы вообще не написали строчки кода C++
Ну некоторые думаю, что бог создал Землю и она плоская. Это право каждого человека. P>и к чему это?
Кто му, что это ваше предложение подтвержадет мою мысль. А значит переливать с вами из пустого порожня толку нету.
1>>PS. Либо аргументируйте свою позицию, либо спорьте ещё с кем то. Меня аргументы, что это распространенное заблуждение совсем не впечатляют.
P>"распространённое заблуждение" — это пояснение к результатам голосования
Аргументов нет. Так что я откланяюсь. Досвидание, успехов в повышении квалификации. (без сарказма).
Здравствуйте, Erop, Вы писали:
E>>>Ага-ага. E>>>std::vector<std::auto_ptr<quack_T> > ups; P>>точно такой же баг возможен и без duck-typing — например есть интерфейс с методом copy, и есть класс который реализует этот copy как move, либо вообще как remove. P>>duck-typing не причём
E>При чём, при чём.
E>Вот смотри, если есть интерфейс, то мы можем формально описать его свойства, и даже формально их как-то проверить, например юнит-тестами... Или ещё как-нибудь. E>В любом случае для всех объектов, которые поддерживают тот интерфейс, нам надо проверить корректность его поддержания. При этом факт поддержания всегда заявлен явно, так что понятно что где и как проверять. А в функции мы только формально опять же требуем на вход интерфейс и всё.
ну вот поверьте точно также конструктор копирования
E>Во-первых, ошибка хорошо локализуется, во-вторых, хорошо делится ответственность... E>А в случе шаблонов фиг чего и где потребуешь, а если и потребуешь, то это бует всё равно на втой страх и риск и только. Формально среда разработки тебе не поможет...
что надёжней по вашему мнению, std::sort или qsort?
E>Понятно, что на std::vector ответственность ты не переложишь, но если это будет какой-то твой шаблон, который неожиданным для тебя образом заюзали, то будет очень трудно понять, чь это ошибка. Твоя, что не предусмотрел и такой сценарий, или того, кто этот сценарий воплотил...
Здравствуйте, Erop, Вы писали:
P>>ну вот в случае сложения с векторами, ну выделили вы vec_add(v1,v2), и как вы теперь сделаете сложение 5 векторов? P>>
P>>? P>>а ничего что это почти в два раза медленней чем одним ядром? E>Блин, ну что за криворукость-то? А как это запраграммировать, если шаблонов нет? Сам придумаешь?
в случае с gpgpu — можно, но:
Но обычно выделяют какие-то операции и вперёд, потом пишут на них...
это ваши слова
P>>1. более читабельны, ближе к языку решаемой проблемы E>Это мифическое преимущество. Всякие тем add и dp не менее читабельны...
менее, я сравнивал
P>>2. выражают семантику намерений напрямую — соответственно могут лениво вычисляться, блокироваться, и т.д, причём автоматом. E>Почему ты считаешь, что автоматом решать что там надо считать, а что нет лучше, чем если таки программист подумает и напишет оптимальный код?
четвёртая страница — на fortran'е получилось в 5 раз больше кода + не один день ручного тюнинга, и всё равно получилось медленней
для каждого выражения будете тратить несколько дней
P>>3. легче расширять на новые наборы инструкций E>Тоже неправда. E>Переписывать надо будет только те функции, в которых есть ядра...
ну, целые ядра, а на C++ при правильном подходе лишь небольшие части ядер (которые общие для многих ядер), так как логика не меняется
Здравствуйте, 11molniev, Вы писали:
P>>>>>>то что цитата в вопросе вырвана из контекста, я уже писал 1>>>>>Ну сделайте голосовалку не вырванную из контекста. Я чем этому мешаю? P>>>>а смысл? вот буквально ниже: P>>>>>>итого, мою точку зрения поддерживают 32.5% (даже при "плохой" постановке вопроса) P>>>>>>и? 1>>>>>Привет им. Мног8ие считают, что питон быстрей всех языков в мире. P>>>>вы приравниваете людей разделяющих мою точку зрения к баранами 1>>>Нет, просто я обращаю внимание, что большинство участников этого форума имеют значительный опыт и знание, и их мнение стоит слышать. И ставить выше мнения отдельных товарищей.
P>>то есть 67.5% имеют значительный опыт и знание, а 32.5% это бараны? 1>а 32.5% имеют меньший опыт, могут заблуждатся или иначе трактовать вопрос...
Браво!!!
"тот кто со мной не согласен, просто имеют меньший опыт, либо заблуждаются"
1>>>> P>Так что быстрее? std::sort (C++ style) vs qsort (C-style) ?
1>>>> Они идентичны, если речь идёт о стандарте, Если не стандарт, то некоторые
1>>>> реализации qsort сливают.
MZ>>>Как бы ты не прав. Они НЕ идентичны. С++ный шаблоный код потенциально
MZ>>>быстрее, т.к. там возможно встраивание кода функции сравнения, и
MZ>>>прочие оптимизации, отсюда вытекающие. Также С++ный код знает
MZ>>>ТИП массива, а С-шный -- не знает. Тоже могут быть оптимизации.
MZ>>>Конечно, С-шный код в принципе тоже может это соптимизнуть,
MZ>>>но только это должен быть ОЧЕНЬ умный компилятор.
P>>а теперь конкретно про тот пример, сколько кода добавится в вашем случае если нужно отсортировать ещё float'ы, double'ы, несколько структур? И сколько в случае C++? 1>А вам в каждой программе необходимо отсортировать "ещё float'ы, double'ы, несколько структур"?
да
1>Лично я за последние пару лет ни qsort, ни std::sort не пользовался. Пользовался order by в linq & sql — это да. А вот в С/С++... нет.
так смысл ведь не в самой сортировке(это один из примеров) а в том, что интерфейсы C++ более надёжные и быстрые одновременно, по-моему это очевидно
P>>>>>>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.
P>>>>>>что вам не ясно-то? 1>>>>>Мне не ясно, почему вы не думаете головой. пытаетесь противоречить фактам. P>>>>каким фактам? 1>>>1. Любой код на С++ представим эквивалентным кодом на С. 1>>>2. Код на С++ и эквивалентный на С при компиляции дадут идентичный машинный код (если вы знаете, что это). 1>>>3. Идентичный машинный код имеет идентичную скорость. P>>4. эквивалентный код на C может быть в 10/100/1000 раз больше, и зачастую не пишется 1>Чё так мало то? Если у вас так сильно дублируеться код могу только сочувствовать.
у меня код не дублируется зачем переходить на личности не понятно
я выше по топику привёл пример, что на fortran'е понадобилось на порядок больше кода, для реализации меньшей функциональности, при соизмеримой скорости так это был fortran, и задача была fortran'овская, что уж говорить про C
1> И кстати С и С++ — это пересекающиеся множества, а не один подмножество другого.
и? в этой теме это не раз говорилось, и мной в том числе
P>>>>>>вы хотели подтвердить моё высказывание своим опросом? 1>>>>>Что 2/3 посетителей этого форума с вами совсем не согласны.
P>>>>ну и?: P>>>>
P>>>>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.
1>>>Вы повторяете это как мантру только на этом форуме, каждое сообщение, или в жизне тоже? Я не хочу вас обидеть, но ИМХО: у вас нет опыта практической работы. А информацию о распространеном заблуждении вы почерпнули из книжки/лекций/форумов.
P>>мне не раз отвечали на вопрос почему они не используют средства C++, тем что считают их медленными. на что, я показывал идентичный ассемблерный листинг при намного меньшем коде 1>Если вы знаете, что токае ассемблерный листинг, то уж должны то понимать, почему на С++ нельзя писать код более быстрый, чем на С. Равный да. Медленней да. Быстрей нет.
если бы вы знали что такое aliasing,
если бы вы поняли (наконец) что аналогичный код на C может быть на несколько порядков больше, то перестилали бы повторять свою мантру.
1>>>PS. Либо аргументируйте свою позицию, либо спорьте ещё с кем то. Меня аргументы, что это распространенное заблуждение совсем не впечатляют. P>>"распространённое заблуждение" — это пояснение к результатам голосования 1>Аргументов нет. Так что я откланяюсь. Досвидание, успехов в повышении квалификации. (без сарказма).
аргументы есть, вы их в упор не видите. из всех собеседников здесь вы самый унылый, узколобый и не конструктивный
(без сарказма).
удачи
1>По факту отличий два: 1>1. Простой (ограниченный) синтаксис.
пока не началась макропись, да, относительно простой.
Но конструкции вида
int (((*)f(int[])*)(int(*)[5]))[10];
и
b += с += ++b-c++;
-- примеры хвалёного простого синтаксиса и полной предсказуемости, кстати, тоже 1>2. Полная предсказуемость поведения.
но есть подмножество с++, обладающее теми же свойствами.
1>Беда людей, которые отрицают С именно в непонимании отличий, что я назвал. Когда я хочу получать только то что хочу — я предпочитаю С. Если мне нужна краткая запись & RAII — я выберу С++.
Не мог бы ты понятно пояснить, чем хак с __AutoRelease__ { } лучше честного RAII?
E>>Ну так это только при бездумном использовании инструмента. Причём любого. В микроскоп прекрасно видно бактерии, но орехи им колоть неудобно, а соседское окно, так и вовсе не видно... 1>Просто входные данные бывают разными ))
Просто программировать надо не в состояни полного ачтоиилота, а с превлечением головы к процессу
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
И кстати С и С++ — это пересекающиеся множества, а не один подмножество другого.
