Здравствуйте, Piko, Вы писали: RSA>>1) реализовывать весь проект на gcc (ИМХО особый род мазохизма при наличии студии); RSA>>2) использовать студию для отладки/написания с++ кода и gcc/gdb для отладки с99 кода, при таком подходе отладка на стыке компиляторов превращается в достаточно увлекательный квест; RSA>>3) портирование с99 кода в с++ — квест получаем увлекательный и итеративный, т.к. нужно отрабатывать выход новых версий и bug/security фиксы. RSA>>*) другие не очень привлекательные варианты.
P>ещё возможные варианты (я их не тестировал, полностью не уверен): P>4) Intel C вроде понимает C99, и не плохо интегрируется со студией
сколько стоит интересно...
P>5) CLang/LLVM
недавно портировал некоторое количество кода из студии в XCode 4.3, получил забавную ошибку (может и я конечно чего то не понимаю):
template<typename t1>
class A
{
protected:
int m_i;
};
template<typename t1, typename t2>
class B: public A<t1>
{
public:
void foo() { ++m_i; }//веселье тут - говорит, типа не знаю никаких m_i... пришлось this->m_i; ну или ++A<t1>::m_i;
};
не уверен что повторил на 100% точно, но что то в этом духе.
P>6) автотрансляция кода с С99 в более старую версию
меня гложут смутные сомнения что в этой области неба безоблачно...
Здравствуйте, Piko, Вы писали:
P>Здравствуйте, 11molniev, Вы писали:
P>>>>>>>а чем принципиально indirect call отличается от virtual call в контексте runtime decision? и то и то получается посредством усилий разработчика 1>>>>>>В С эти усилия всегда в явном виде. С++ можно и без усилий получить их по дефолту. Проще говоря на чистом Си тормоза всегда являются результатом осознанного решения разработчика. Только то и всего. P>>>>>а где в C++ их можно получить по дефолту, да так чтобы не знать об этом? P>>>>>я когда пишу virtual — всегда осознаю, что в 99% случаев это будет indirect call через vtable 1>>>>Сама концепция объекта как черного ящика их предполагает. P>>>поясните что именно вы имеете ввиду, в данном контексте 1>>То что сама концепция ООП с классами как черными ящиками подразумевает неизвестность будут тормоза или нет. Это "детали скрытые конкретной реализацией". Одновременно и ирония и правда. P>тоже самое можно сказать о функции — вот смотришь на декларацию — и не поймёшь — будут тормоза или нет.
Дык функция то и есть конкретная реализация)) Ничего не скрывается за абстракцией)) Я говорю о том, что в случае с ООП сама парадигма противоречит "я когда пишу virtual — всегда осознаю, что в 99% случаев это будет indirect call через vtable". Ничего более.
1>>>>Я честно сказать не совсем улавливаю о чем мы спорим: С++ даст более компактный код. С даст более быстрый код. С++ со вставками legacy в нужных местах даст скорость, во всех остальных — компактность. P>>>нет. при использовании шаблонов, при определении специализаций для небольших особенностей, при определении алгоритмов которые принимают сущности с большим набором небольших особенностей, полный код алгоритма учитывающий каждую особенность сгенерируется автоматом, и будет он не медленней, а то и быстрее legacy C, так как вручную все эти особенности учесть на несколько порядков труднее. 1>>Практический пример в коде. Если вы ознакомитесь с дизассемблерным листингом — то все эти вопросы исчезнут. 1>>>>Если пропихнуть вместо legacy С asm — будет ещё быстрей (если конечно есть опыт программирования на нем и время на профайлер). P>>>это тоже заблуждение, компиляторы сейчас обладают большими знаниями в оптимизации, чем люди. P>>>если речь идёт о расширениях типа sse — то во-первых, сейчас компиляторы умеют делать автовекторизацию, во-вторых если всё-же придётся использовать sse вручную, то это будет не asm, а intrinsic, и в-третьих эти intrinsic при грамотном дизайне не будут разбросаны по всему проекту, а будут аккуратно обвёрнуты в маленькие абстракции. P>>>Пример, http://eigen.tuxfamily.org/index.php?title=Main_Page — см раздел "Eigen is fast" P>>>Тесты: http://eigen.tuxfamily.org/index.php?title=Benchmark как видите, Eigen уделывает legacy код на многих участках. P>>>Так что миф об legacy speed — это миф. 1>>Тесты аудио/видеодекодеров с вами не согласны. Сравнение скорости крипто алгоритмов тоже. P>какие именно тесты?
Не тесты, сами кодеки. P>что там сравнивается? быстрая реализация на C versus плохая C++ реализация?
Обе реализации от авторов. Так сказать официальные. А ваши слова про быструю/плохую реализации как раз говорят, что тестам верить нельзя. О том и речь. 1>>Как раз таки тесты не показатель — их можно подогнать под что угодно. P>Вы посмотрите что сравнивается на графиках: вылизанные реализации типа GOTO2, INTEL_MKL, versus Eigen. Разве это не честно? Или вы сомневаетесь в чистоте тестов?
Да сомневаюсь. Я полагаю, что INTEL_MKL быстрей. И я абсолютна точно знаю, что тесты можно подогнать к чему угодно. Сам видел сравнения в которых Java быстрей C++. 1>>Ну а насчет мифа — достаточно взглянуть во внутренности математических библиотек Intel'а, чтобы убедиться, как глубоко заблуждаются инженеры этой компании. P>какие именно библиотеки вы имеете ввиду? P>И какие там внутренности? Разве ассемблер?
Смотря в каких. В упомянутой INTEL_MKL насколько помню — да. 1>>Люди умней компиляторов. P>на счёт этого я не спорю. P>Компиляторы могут обработать намного большие объёмы информации чем люди, они знают намного больше об процессорах, pipelines и т.п.
Знания компилятора о процессорах, кеш линиях и прочем сильно ограничены реализованными алгоритмами оптимизации. P>Простое переписывание вручную на ассемблер ничего не даст, а зачастую наоборот замедлит.
Ну дык смотря кто переписывает. P>Многие верят в миф, что просто ручное написание на ассемблере даст ускорение — это bullshit. Простого переписывания не достаточно для обгона компилятора.
Да просто недостаточно. Надо ещё думать головой, иметь соответствующий опыт, хоть минимальные знания и пользоваться профайлером — и тогда код будет быстрей.
P>>>Понимаете, для сортировки есть разные алгоритмы, разные реализации std::sort 1>>Ну я то тут причем? Это вы ведь приводите исследование их сравнивающее. Причем уже во второй раз. На Си там быстрая сортировка. P>я согласен, просто сравнение скорости std::sort и qsort из какой-нибудь реализации не полностью честно. P>Но, идея в том, что если взять одинаковые алгоритмы, один из которых обвернуть в qsort, другой в std::sort, std::sort будет быстрее.
Но это си. Здесь нельзя ничего обернуть не получив проигрыша в скорости. Но если взять одинаковые алгоритмы, хорошо написанные, то скорость либо будет одинаковой либо у С больше.
1>>>>>>>>Если хотите скину код, состряпанный на скорую руку. P>>>>>>>если не трудно — то скиньте, мне будет интересно. можно сюда, а можно в http://ideone.com/ 1>>>>>>http://pastebin.com/YsGRBtZ0 — только #include "stdafx.h" уберите, я забыл 1>>>>>>http://ideone.com/iL6Gb 1>>>>>>На скорую рука, так что не очень, но общий подход иллюстрирует. P>>>>>http://pastebin.com/QXPU0zWC P>>>>>test_c2 и test_cplusplus3 по скорости примерно одинаковы. 1>>>>На N=100000000, qsort: 28.758331, std::sort: 20.791297, c: 17.333931 соотношение 1,38 и 1,199 1>>>>На N=10000000 qsort: 2.567289, std::sort: 1.824936, c: 1.510803 соотношение 1,40 и 1,20 1>>>>т.е. то о чем я говорю: переписывания куска кода на чистый с раздуло этот код и ускорило его работу на ~20 процентов. В два раза меньше чем использование std::sort вместо qsort — так что цифры увеличения скорости вполне сопоставимы. 1>>>>Единственный момент: это 64 разрядный код, std::sort при N=100000000 на 32 битах вылетело с исключением)). Для 32 qsort vs std::sort получается в районе 1,6. P>>>Вы видели test_cplusplus3 ????? У вас там есть разница в скорости? 1>>Опечатался. Разумеется просто "test_cplusplus". Разница в скорости есть, код у вас есть — можите сравнить. P>Вы видели test_cplusplus3 (цифра три на конце) ? выделенная жирным ссылка на pastebin
Перепутал ваши и свои слова. Теперь видел. Разницы нет. Равно как и разницы между вариантом на С и на С++, за исключением возможности применения последнего к любым объектам реализующим соответствующий интерфейс. Это фактически то о чем я и говорю — на С++ можно написать код идентичный С (когда то С с классами)) ). И получить идентичную скорость. Быстрей сделать нельзя. Вот и все. При этом С++ кода будет меньше.
P>>>Кстати, сравнивать сортировку на разных наборах случайных данных не корректно, на определённых данных quicksort вообще может взрываться до N^2. 1>>Но quicksort там это Си. Что на С++ как вы сами сказали — неизвестно. И что значит случайные сравнивать некорректно — да есть алгоритмы, работающие быстрей при увеличении степени упорядоченности. Но сортировка предназначенная для упорядочивания не упорядоченного массива в том числе и случайных данных (пусть это и худший случай). На чем её ещё тестировать — на возрастающем массиве? Впрочем я не имею ничего против, если вы поменяете способ наполнения массива и скинете код.
P>Вы не поняли меня. В ваших тестах (да и в тех что я добавил, основываясь на вашем подходе), производится сравнение скорости сортировки на разных случайных наборах. А нужно делать сравнение на одинаковых, но при это всё равно случайных наборах.
1. Это компенсируется несколькими прогонами вот и все. Получаем медиану. Нам же ведь нужна примерное соотношение скорости, а не десятые доли процента скорости.
2. У нас довольно большой массив элементов, а диапазон их изменения не настолько велик. Фактически статистика сглаживается для таких массивов.
Поэтому я позволил себе каждый раз генерировать последовательность заново.
1>>>>>>И? Померились? P>>>>>?? я с вами мерится не собирался, мне интересно сравнение C vc C++, без личностей... 1>>>>Извините, если восприняли, как переход на личности (хотя подтекст не скрою)) ). Просто очевидно, что С предоставляет меньшие возможности по инициализации/освобождению ресурсов и в подобных сравнениях кода на С будет больше, чем на плюсах. P>>>я думаю при создании функции с 10 ресурсами, как минимум большинство программистов сделает ошибку, а то и не одну. P>>>Зачем вообще надрываться и использовать C, когда есть C++? (естественно, кроме тех случаев когда использование C++ невозможно из-за отсутствия компилятора) 1>>Как минимум у разных людей разные предпочтения. Ну действительно — зачем надрываться и сажать картошку, если можно есть саранчу, которая сама вырастит. P>тут я не спорю — вкусы у всех разные. P>Но, зачастую "отрекание" от C++ в сторону C, происходит на основе неправильной интерпретации опыта.
Могу лишь развести руками. В сущности главное качественный конечный результат. И если человек не умеет правильно интерпретировать опыт — то пусть лучше пишет на С. Это будет выглядеть не так ужасно, как на С++.
1>>>>Поэтому я лично слабо улавливаю, что вы хотите показать этим сравнением. Код на С++ компактней. Ну так в этом то наши мнения совпадают. P>>>далеко не все это понимают. P>>>помимо компактности — это ещё и безопасность и надёжность. 1>>Я об этом уже написал. Печально, что вы не захотели понять, что кто то может иметь точку зрения отличающеюся от вашей и пытаетесь убедить других в своей точке зрения. P>Я помню что вы писали, я понял что вы имели ввиду, но ни один coding standard, никогда не будет лучше отсутствия технической возможности ошибиться.
В том то и дело — что у палки два конца. Отсутствие технической возможности — это ограничение которое дает и плюсы и минусы.
P>>>>>>>Я думаю даже без причёсывания вашего C-style варианта, видно что безопасней и легче. 1>>>>>>Чем меряете безопасность и легкость кода? Всетаки субъективные критерии. Помимо наличия конструкторов и деструкторов. P>>>>>легкость: кода меньше. код лаконичней. вообще не надо парится об корректном сборе ресурсов. P>>>>>безопасность: кода меньше. код лаконичней. вообще не надо парится об корректном сборе ресурсов. P>>>>>вы в своём коде сделали ошибку, я думаю наверняка не одну. проблема не в вас, а в самом подходе, я бы тоже сделал ошибку в вашем случае, потому что код намного сложнее. 1>>>>Отчасти я с вами согласен. Но и вы отнеситесь с пониманием: С язык очень простой. Фактически — простыня вызова функций. Поэтому когда сложный алгоритм предварительно просчитан, разбит на составляющие, использование си приводит к тупому переносу алгоритма с одного языка на другой. И это тоже уменьшает ошибки. Да на С++ кода меньше и он лаконичней, но это достигается его большей информационной емкостью, а значит повышает сложность. Смотрите сами: есть класс — значит есть конструктор/деструктор, есть операция — может быть перегружена и так далее. Это уменьшает объем кода, но дизассемблерный листинг то остается один и тот же (я утирирую) — а значит на одну строчку кода в С++ приходиться больше информации, чем в С. А значит он на некую абстрактную производную от этой информации сложней. P>>>да, язык больше, я не спорю. P>>>но посмотрите на это с другой стороны: какая-либо возможность языка учится один раз, а потом используется многократно, если нет этой возможности то пришлось бы постоянно писать однотипный код. 1>>И при этом не все сопутствующие последствия человек удерживает в голове. Это как раз одна из причин, по которой люди иногда предпочитают чистый С. P>почему в этом случае не использовать тот subset C++, который понятен, и удерживается в голове?
Дык так и делают. И я делаю. Я же ведь не утверждаю, что на С++ нельзя программировать и его надо выкинуть на помойку. Я только говорю, что для некоторых задач и программистов выбор С вполне оправдан. И что С++ не будет быстрей С. Он либо медленней либо равен по скорости.
1>>>>Ну и насчет безопастности — все таки это больше зависит от опыта. Я вот в коде допустил такую дуратскую ошибку, а в реальном коде как в Enter/Leave оборачиваются очень небольшие участки, внутри которых нет переходов за них. И участки эти в голове прокручиваю. А тут просто набросал как пример и даже не задумался, будет работать или нет. Хотя я склонен думать, что программист с малым опытом на С++ допустит меньше ошибок чем на С. Но только если будет следовать RAII, а не писать legacy. Но понимание всей прелести RAII приходит только с опытом. P>>>Тут проблема в образовании, многие начинают учить C++ начиная с legacy C, приобретают вредные привычки, и часто далеко не выходят за пределы legacy C. Прочитайте статью http://www2.research.att.com/~bs/new_learning.pdf — мне понравилось. 1>>Тут проблема в том что С проще и его проще учить. Ну или по крайней мере так полагает большинство авторов. P>в статье как раз говорится что C++ легче учить (хотя бы до определённого уровня)
Может легче. Понятия не имею. Испытать не на ком.
1>>Насчет статьи: 1>>Я не перепечатывал код полностью — но пример данный мной в прошлом сообщении взят именно из этой статьи. И он хорошо показывает, что статья не в полне объективна. Она показывает выигрыш С++ в скорости над С. Но написав сишный код чуть-чуть подругому мы получаем диаметрально противоположный результат.
P>сравниваются две "обобщённые"(как вы сами сказали). да, алгоритмы сортировки в реализации могут быть разные, но давайте возьмём один алгоритм, ок? P>Вы написали не обобщённую C версию, при этом когда я из неё сделал на C++ обобщённую — qSortIT, её скорость была не меньше скорости не обобщённой C версии — вы это увидели?
Да. Я нигде не оспариваю, что на С++ можно получить быстродействие практически идентичное С. Плюс минус пренебрежительную дельту. Я оспариваю утверждение у вас и в статье, что С++ быстрей С.
1>>Мне очень не нравиться попытка сравнить std::sort и qsort. Как я уже сказал, qsort — это нечто вроде wchar_t под unix. Да она есть — но ей в большинстве случаев не пользуются. И она априорно медленней std::sort — что там можно сравнивать, тестировать и как на основе этого теста можно говорить, что С++ быстрей. И утверждение, что более высокий уровень абстракции и защиты от ошибок при этом дает увеличение скорости не лезет ни в какие ворота.
P>почему, по-моему как раз таки лезет. P>1) есть две обощённые(в вашем понимании функции) qsort и std::sort
Причем заведомо известно, что qsort медленней std::sort P>2) интерфейс std::sort более безопасен и менее подвержен ошибкам чем qsort
Верно. P>3) при равный используемых алгоритмах сортировки std::sort будет быстрее qsort
Ну да. Вот я и не понимаю — что можно сравнивать. Автор этой статьи не знает как работают шаблоны? Или что? Если человек ну хоть капельку знает С и С++, то он знает правильный ответ и без этих исследований.
P>с чем из этого вы не согласны?
Ну если бы высокий уровень абстракции и защиты от ошибок увеличивал скорость самыми быстрыми языками были бы Lsip-подобные. Здравый смысл.
Здравствуйте, Piko, Вы писали:
AS>>Ну, по причине неадекватной сложности, ведущей к постоянной борьбе с языком, и постоянного вынужденного скатывания к синтаксическому онанизму. Плюс к тому ещё и высокая сложности разбора крешей в случае использования 'правильных' либ. AS>>Привело к серьёзному упрощению кода, который теперь можно понять не изучая в течении нескольких лет методы высокой магии и прорицания в пространствах синтаксических подсластителей.
P>Синтаксический онанизм говоришь? методы высокой магии? прорицание в пространствах синтаксических подсластителей? серьёзное упрощение кода? P>ну-ну :
Ох, порвал как тузик грелку!
Мне из какого файла STL привести кусок кода в качестве примера? ИМХО из любого. Я уж не говорю про силиконовый (или какой другой) протез, без которого писать на плюсах по человечески невозможно.
Я согласен что для идиотов, что не знают самого языка, но с упоением спорят о метафизики и шаблонах, пара свичей ещё тот бетхерт, но вот проблема — содержимое продукта лихорадочного бреда Степанова сих индивидуумов ваще вгонит в глубокий когнитивный диссонанс, а силиконовые сиськи порвут как капля никотина хомяка. Но кто же лазит разбираться как устроены сиськи?
В остальном, можно по существу что напрягает адепта двух плюсов в этом коде? Макросы? Это как бы прямой путь реализации многих вещей в С, и не надо тащить своё табу ни них из плюсов. Минимальное знание самого языка, а не приёмов построения рекурсивного шаблонного бреда... ну, ё-моё, избавляйтесь от вредных привычек и учите синтаксис.
Хотя мы вроде как не о реализации рантайма спорили, а о том можно ли написать на С код с автоматическим управлением ресурсами толерантный к исключениям, я привёл РАБОЧИЙ (в отличии от тебя) пример что можно, и очень просто. На больших объёмах кода проще чем в плюсах, между прочим. Но уж коли мы пошли в реализацию ... ты можешь менять реализацию под конкретную платформу в С++, ой а шо так? Или хотя бы иметь гарантии по способу реализации механизмов, или хотя бы гарантии что они вообще реализованы? Вопрос типа риторический. )
AS>>С примером, в котором очевидно где 'видно что безопасней и легче', когда тыкать будешь?! P>я уже привёл пример с тремя ресурсами.
Тебе объяснить почему он некорректный и нерабочий? Или сам догадаешься? Давай ты напишешь ПОЛНЫЙ и РАБОЧИЙ пример, и уже с ним будем чего то обсуждать и сравнивать, а так получается сравнение сферического коня в вакууме с рабочим кодом.
Или для настоящего мачо приводить компиируемые и работающие примеры архисложная задача? )))
Здравствуйте, RSATom, Вы писали:
P>>ещё возможные варианты (я их не тестировал, полностью не уверен): P>>4) Intel C вроде понимает C99, и не плохо интегрируется со студией RSA>сколько стоит интересно...
на сайте intel должна быть цена. предполагаю что не больше 500$, а то и меньше
P>>5) CLang/LLVM RSA>недавно портировал некоторое количество кода из студии в XCode 4.3, получил забавную ошибку (может и я конечно чего то не понимаю): RSA>
RSA>template<typename t1>
RSA>class A
RSA>{
RSA>protected:
RSA> int m_i;
RSA>};
RSA>template<typename t1, typename t2>
RSA>class B: public A<t1>
RSA>{
RSA>public:
RSA> void foo() { ++m_i; }//веселье тут - говорит, типа не знаю никаких m_i... пришлось this->m_i; ну или ++A<t1>::m_i;
RSA>};
RSA>
RSA>не уверен что повторил на 100% точно, но что то в этом духе.
всё правильно, это шаблоны.. у студии в этом месте по умолчанию включено толерантное расширение языка (по-моему можно отключить).
по моему опыту clang более строгий в плане стандарта чем gcc
P>>6) автотрансляция кода с С99 в более старую версию RSA>меня гложут смутные сомнения что в этой области неба безоблачно...
а вообще возвращаясь к исходному:
P>>>>А зачем вообще может понадобится использовать C, когда есть C++ ? RSA>>>Существуют Open Source проекты написаные на с99, иногда хочется их портировать под винду для использования в каких либо проектах. Яркий пример ffmpeg.
то к выделенному эта проблема никак не относится, так как даже если бы вы использовали MSVS C (не C++), то проблема бы никуда не делась.
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>>>Ну, по причине неадекватной сложности, ведущей к постоянной борьбе с языком, и постоянного вынужденного скатывания к синтаксическому онанизму. Плюс к тому ещё и высокая сложности разбора крешей в случае использования 'правильных' либ. AS>>>Привело к серьёзному упрощению кода, который теперь можно понять не изучая в течении нескольких лет методы высокой магии и прорицания в пространствах синтаксических подсластителей.
P>>Синтаксический онанизм говоришь? методы высокой магии? прорицание в пространствах синтаксических подсластителей? серьёзное упрощение кода? P>>ну-ну :
AS>Ох, порвал как тузик грелку!
ну да
AS>Мне из какого файла STL привести кусок кода в качестве примера? ИМХО из любого.
о каких файлах STL ты вообще говоришь? есть стандарт, есть интерфейс, и да, есть реализации некоторые из которых могут быть кривыми.
AS>Я уж не говорю про силиконовый (или какой другой) протез, без которого писать на плюсах по человечески невозможно.
AS>Я согласен что для идиотов, что не знают самого языка, но с упоением спорят о метафизики и шаблонах, пара свичей ещё тот бетхерт, но вот проблема — содержимое продукта лихорадочного бреда Степанова сих индивидуумов ваще вгонит в глубокий когнитивный диссонанс, а силиконовые сиськи порвут как капля никотина хомяка. Но кто же лазит разбираться как устроены сиськи?
опять какой-то понос и батхёрт
а так, Степанов — крутой мужик
AS>В остальном, можно по существу что напрягает адепта двух плюсов в этом коде? Макросы? Это как бы прямой путь реализации многих вещей в С, и не надо тащить своё табу ни них из плюсов. Минимальное знание самого языка, а не приёмов построения рекурсивного шаблонного бреда... ну, ё-моё, избавляйтесь от вредных привычек и учите синтаксис.
Ещё раз, ты говорил о синтаксическом онанизме. Я тебе привёл код (который по всей видимости ты и используешь), который и есть сплошной синтаксический онанизм.
Теперь же ты сменил пластинку, и говоришь "учите синтаксис"
AS>Хотя мы вроде как не о реализации рантайма спорили, а о том можно ли написать на С код с автоматическим управлением ресурсами толерантный к исключениям, я привёл РАБОЧИЙ (в отличии от тебя) пример что можно, и очень просто.
а я с тобой и не спорил:
AS>>И да, на С, но с исключениями, автоматическим управлением ресурсами и объектной моделью. С++ для всего этого не особенно и не нужен. P>Я не совсем понял, вы используете подмножество C++ ? P>Или просто C? Как объектную модель можно на C сэумлировать — мне понятно. Но вот исключения и автоматическое управление ресурсами на С — сходу не соображу как сделать.
я спросил как это можно сделать..
как пример ты привёл трёхэтажный синтаксический препроцессорный онанизм, против которого ты сам высказывался ранее
AS>На больших объёмах кода проще чем в плюсах, между прочим.
ну понятно, на C++ у тебя не срослось, на С что-то получилось, теперь ты рассказываешь что проще
AS>Но уж коли мы пошли в реализацию ... ты можешь менять реализацию под конкретную платформу в С++, ой а шо так? Или хотя бы иметь гарантии по способу реализации механизмов, или хотя бы гарантии что они вообще реализованы? Вопрос типа риторический. )
Реализацию чего? Вызова деструкторов?
А ты можешь менять реализацию if/while/for/goto на C? "ой, а шо так?".
парень, ты уже что-то совсем желчью исходишь.. [зевок] уже совсем не интересно..
C:\Projects\13>g++ 1.cpp -o 1
C:\Projects\13>1
que paso?
Как бы для того шоб горить про простоту и лёгкость, неплохо бы для начала пройти хотя бы по некоторым хитро замаскированным граблям. А уж про auto_ptr, что я убрал, вообще отдельный трактат написать можно.
Здравствуйте, Piko, Вы писали:
P>о каких файлах STL ты вообще говоришь? есть стандарт, есть интерфейс, и да, есть реализации некоторые из которых могут быть кривыми.
Дык можно взять любую.
AS>>В остальном, можно по существу что напрягает адепта двух плюсов в этом коде? Макросы? Это как бы прямой путь реализации многих вещей в С, и не надо тащить своё табу ни них из плюсов. Минимальное знание самого языка, а не приёмов построения рекурсивного шаблонного бреда... ну, ё-моё, избавляйтесь от вредных привычек и учите синтаксис. P>Ещё раз, ты говорил о синтаксическом онанизме. Я тебе привёл код (который по всей видимости ты и используешь), который и есть сплошной синтаксический онанизм. P>Теперь же ты сменил пластинку, и говоришь "учите синтаксис"
Дык что именно в мём коде синтаксический онанизм? Несколько тривиальных макросов выполняющих постдействие? Да, они с многими конструкциями из STL рядом не стояли по сложности. Или авторелиз пула? Ну тут вообще не понятно в чём проблема. В том что ты не понял как это работает? Ну мои сожаления. )
P>я спросил как это можно сделать.. P>как пример ты привёл трёхэтажный синтаксический препроцессорный онанизм, против которого ты сам высказывался ранее
Я привёл рантайм и один макрос который избавляет от необходимост закрытия TRY блока. Несколько тривиальных инстркуций на всю прорамму свёрнутые в ключевое слово с одназначно прозрачной семантикой ... ну видимо ты плохо знаком с проблемами С++. Возможно всего лишь в рамках букваря.
AS>>На больших объёмах кода проще чем в плюсах, между прочим. P>ну понятно, на C++ у тебя не срослось, на С что-то получилось, теперь ты рассказываешь что проще
Гы, ещё раз послать почитать избранное?
P>Реализацию чего? Вызова деструкторов?
Например реализацию исключений. Да ладно менять, хотя бы гарантировать что она есть. Про шаблонные же выверты можно просто скромно промолчать.
P>А ты можешь менять реализацию if/while/for/goto на C? "ой, а шо так?".
Шутку понял, смешно. Теперь осталось тебе понять о чём говорил я, но для этого правда надо написать несколько лямов строк кода на С++ и наступить хотя бы на основные грабли.
P>парень, ты уже что-то совсем желчью исходишь.. [зевок] уже совсем не интересно..
Гы, ну дык, ты даже не смог пример привести без очевидных ляпов, конечно не интересно. Как малышу в универе.
только сначала скажи зачем, и приведи аналог на C. Я ведь изначально просил псевдокод.
AS>Как бы для того шоб горить про простоту и лёгкость, неплохо бы для начала пройти хотя бы по некоторым хитро замаскированным граблям.
говори конкретно про грабли, не томи...
диалог с тобой совсем не конструктивный получается, и утомляет [зевок], у меня почти нет желания продолжать тратить своё время(которое есть деньги).. так что давай поконкретнее.
AS>А уж про auto_ptr, что я убрал, вообще отдельный трактат написать можно.
в примере где я его использовал — он безобиден
да, auto_ptr не идеален, есть пара моментов о которых нужно знать, но как бы всё вытекает из интерфейса, хитрости реализации знать не надо..
вообще smart-поинтеры в C++ нужны далеко не всегда..
AS>>а давай дополним это до работающего кода?! P>только сначала скажи зачем, и приведи аналог на C. Я ведь изначально просил псевдокод.
Зачем приводить рабочий код? Ну я даже как то в растерянности. Объяснять столь очевидные вещи человеку с претензиями... Ты меня чеслово удивляешь.
Свой аналог я уже привёл. Как на С сделать обработку синхронизации, если ты про это, есть у меня в избранном, там довольно подробно всё разжованно. Сам же я давно уже не пишу многопоточный код, только асинхронный.
AS>>Как бы для того шоб горить про простоту и лёгкость, неплохо бы для начала пройти хотя бы по некоторым хитро замаскированным граблям. P>говори конкретно про грабли, не томи... P>диалог с тобой совсем не конструктивный получается, и утомляет [зевок]
О неее, я не благотворительная организация помогающая слабоумным. Не видишь, ну что же, это твои проблемы ))) Просто так и запишем, клиент знает С++ из букваря. Для тех кто знает чуть больше это будет самоочевидно, остальные значения не имеют. Могу лишь добавить что С++ язык множества тонких нюансов, если ты их не чувствуешь, ты можешь хоть наизусть заучить стандарт, страуса, саттера, меерса, александреску ... и всё равно писать хреновые программы.
А относительно конструктива — кто сказал что мне нужен конструктив? Я сюда потроллить прихожу, постебаться.
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>Мне из какого файла STL привести кусок кода в качестве примера? ИМХО из любого. Я уж не говорю про силиконовый (или какой другой) протез, без которого писать на плюсах по человечески невозможно.
А что конкретно в реализации СТЛ вызывает затруднения?
AS>В остальном, можно по существу что напрягает адепта двух плюсов в этом коде? Макросы? Это как бы прямой путь реализации многих вещей в С, и не надо тащить своё табу ни них из плюсов. Минимальное знание самого языка, а не приёмов построения рекурсивного шаблонного бреда... ну, ё-моё, избавляйтесь от вредных привычек и учите синтаксис.
М... Ты уже научил интеловский компилер синтаксису С?
Ну и проверять, справляется ли оптимизатор с такими построениями -- не самая интересная задача.
AS>Хотя мы вроде как не о реализации рантайма спорили, а о том можно ли написать на С код с автоматическим управлением ресурсами толерантный к исключениям, я привёл РАБОЧИЙ (в отличии от тебя) пример что можно, и очень просто. На больших объёмах кода проще чем в плюсах, между прочим. Но уж коли мы пошли в реализацию...
_>Только законченному идиоту придет в голову писать ОС, или упаси бог, ядро этой ОС на С++, используя концепцию ООП, особенно в CLI нотации.
Так ведь пришло в голову написали пишут. BeOS была на C++ написана, сейчас Haiku тоже пилят на C++, причём именно ядро. И что-то на идиотов там никто не похож.
AS>>Мне из какого файла STL привести кусок кода в качестве примера? ИМХО из любого. Я уж не говорю про силиконовый (или какой другой) протез, без которого писать на плюсах по человечески невозможно.
NB>А что конкретно в реализации СТЛ вызывает затруднения?
Найти людей которые могут не только читать код, активно его пользующий, но и как то его менять. Причём желательно за адекватные деньги.
Основная проблема С++ в том, что сопровождение кода стоит дороже его написания, и требует квалификации существенно выше чем у того, кто его писал. Такая вот парадоксальная зависимость. При условии же что чем программер лучше, тем меньше он хочет сопровождать чужой код... очевидно неинтересная.
От собственно это в реализации STL у меня и вызывает затруднения.
Кстати, то что я делаю на С с ресурсами и исключениями, вообще достаточно распространённая практика, существующая хрен знает сколько времени, но явно больше чем мой стаж программера. Я лишь обернул это в удобные макросы и определил несколько правил кодирования, однако сколько это воплей вызвало... ))) Причём никакой скрытой логики я в общем-то не добавил.
Это всё к тому, что те кто упорно твердят — на С закат солнца делается сугубо только руками, несколько заблуждаются. Как и те кто убеждены что C++ всё сделает за них и бесплатно.
Сколько бы клинап автопула не стоил, он позволяет работать с обычными указателями не заботясь о их правильном удалении. Иначе говоря писать совершенно прозрачный код без всяких шаблонных выкрутасов в каждой строчке кода и кучи скрытой логики. В С нет скрытой логики, она вся на поверхности, это и есть его основное преимущество. В С++ же такое сделать в принципе невозможно, в силу концепции языка, а если бы и можно было это пошло бы в разрез с Единственным Истинно Верным Способом Программировать. )))
Однако если тебе нужно точно знать кто кому сливает, дык возьми да проверь ))) Делов то.
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>>>Мне из какого файла STL привести кусок кода в качестве примера? ИМХО из любого. Я уж не говорю про силиконовый (или какой другой) протез, без которого писать на плюсах по человечески невозможно.
NB>>А что конкретно в реализации СТЛ вызывает затруднения?
AS>Найти людей которые могут не только читать код, активно его пользующий, но и как то его менять. Причём желательно за адекватные деньги. AS>Основная проблема С++ в том, что сопровождение кода стоит дороже его написания, и требует квалификации существенно выше чем у того, кто его писал. Такая вот парадоксальная зависимость. При условии же что чем программер лучше, тем меньше он хочет сопровождать чужой код... очевидно неинтересная.
AS>От собственно это в реализации STL у меня и вызывает затруднения.
ты несколько сгущаешь краски.
думаю, то же самое можно сказать и про твой код.
тут проблема не в шаблонах или макросах, а в программистах.
AS>Это всё к тому, что те кто упорно твердят — на С закат солнца делается сугубо только руками, несколько заблуждаются. Как и те кто убеждены что C++ всё сделает за них и бесплатно.
если не хочешь за удобство платить в рантайме, то именно что руками как бы не хотелось обратного.
и дело не только в исключениях.
у тебя, допустим, наследование используется? делать касты к базе приходится?
AS>Однако если тебе нужно точно знать кто кому сливает, дык возьми да проверь ))) Делов то.
ну, то есть тебя этот вопрос не сильно интересует? пинятно.
Здравствуйте, 11molniev, Вы писали:
P>>>>>>>>а чем принципиально indirect call отличается от virtual call в контексте runtime decision? и то и то получается посредством усилий разработчика 1>>>>>>>В С эти усилия всегда в явном виде. С++ можно и без усилий получить их по дефолту. Проще говоря на чистом Си тормоза всегда являются результатом осознанного решения разработчика. Только то и всего. P>>>>>>а где в C++ их можно получить по дефолту, да так чтобы не знать об этом? P>>>>>>я когда пишу virtual — всегда осознаю, что в 99% случаев это будет indirect call через vtable 1>>>>>Сама концепция объекта как черного ящика их предполагает. P>>>>поясните что именно вы имеете ввиду, в данном контексте 1>>>То что сама концепция ООП с классами как черными ящиками подразумевает неизвестность будут тормоза или нет. Это "детали скрытые конкретной реализацией". Одновременно и ирония и правда. P>>тоже самое можно сказать о функции — вот смотришь на декларацию — и не поймёшь — будут тормоза или нет. 1>Дык функция то и есть конкретная реализация)) Ничего не скрывается за абстракцией)) Я говорю о том, что в случае с ООП сама парадигма противоречит "я когда пишу virtual — всегда осознаю, что в 99% случаев это будет indirect call через vtable". Ничего более.
тоже самое можно сказать и о простом вызове функции по указателю: когда я делаю вызов функции по указателю в 99% случаев это будет indirect call
P>>Простое переписывание вручную на ассемблер ничего не даст, а зачастую наоборот замедлит. 1>Ну дык смотря кто переписывает. P>>Многие верят в миф, что просто ручное написание на ассемблере даст ускорение — это bullshit. Простого переписывания не достаточно для обгона компилятора. 1>Да просто недостаточно. Надо ещё думать головой, иметь соответствующий опыт, хоть минимальные знания и пользоваться профайлером — и тогда код будет быстрей.
при грамотной оптимизации, ассемблерный код, intrinsic и т.п., как я уже сказал будут обвёрнуты в небольшие абстракции.
Это далеко не тоже самое, что многие подразумевают под "переписывание вручную на ассемблер"
P>>>>Понимаете, для сортировки есть разные алгоритмы, разные реализации std::sort 1>>>Ну я то тут причем? Это вы ведь приводите исследование их сравнивающее. Причем уже во второй раз. На Си там быстрая сортировка. P>>я согласен, просто сравнение скорости std::sort и qsort из какой-нибудь реализации не полностью честно. P>>Но, идея в том, что если взять одинаковые алгоритмы, один из которых обвернуть в qsort, другой в std::sort, std::sort будет быстрее. 1>Но это си. Здесь нельзя ничего обернуть не получив проигрыша в скорости. Но если взять одинаковые алгоритмы, хорошо написанные, то скорость либо будет одинаковой либо у С больше.
если алгоритмы одинаковые, хорошо написанные, почему вы не сказали про вариант, когда скорость у C++ больше?
Если это по вашему мнению не возможно, то с чего вообще есть вариант когда код C быстрее?
1>>>>>>>>>Если хотите скину код, состряпанный на скорую руку. P>>>>>>>>если не трудно — то скиньте, мне будет интересно. можно сюда, а можно в http://ideone.com/ 1>>>>>>>http://pastebin.com/YsGRBtZ0 — только #include "stdafx.h" уберите, я забыл 1>>>>>>>http://ideone.com/iL6Gb 1>>>>>>>На скорую рука, так что не очень, но общий подход иллюстрирует. P>>>>>>http://pastebin.com/QXPU0zWC P>>>>>>test_c2 и test_cplusplus3 по скорости примерно одинаковы. 1>>>>>На N=100000000, qsort: 28.758331, std::sort: 20.791297, c: 17.333931 соотношение 1,38 и 1,199 1>>>>>На N=10000000 qsort: 2.567289, std::sort: 1.824936, c: 1.510803 соотношение 1,40 и 1,20 1>>>>>т.е. то о чем я говорю: переписывания куска кода на чистый с раздуло этот код и ускорило его работу на ~20 процентов. В два раза меньше чем использование std::sort вместо qsort — так что цифры увеличения скорости вполне сопоставимы. 1>>>>>Единственный момент: это 64 разрядный код, std::sort при N=100000000 на 32 битах вылетело с исключением)). Для 32 qsort vs std::sort получается в районе 1,6. P>>>>Вы видели test_cplusplus3 ????? У вас там есть разница в скорости? 1>>>Опечатался. Разумеется просто "test_cplusplus". Разница в скорости есть, код у вас есть — можите сравнить. P>>Вы видели test_cplusplus3 (цифра три на конце) ? выделенная жирным ссылка на pastebin 1>Перепутал ваши и свои слова. Теперь видел. Разницы нет. Равно как и разницы между вариантом на С и на С++, за исключением возможности применения последнего к любым объектам реализующим соответствующий интерфейс. Это фактически то о чем я и говорю — на С++ можно написать код идентичный С (когда то С с классами)) ). И получить идентичную скорость. Быстрей сделать нельзя. Вот и все. При этом С++ кода будет меньше.
Я говорил:
P>ещё раз, вы говорите, что скорость C++ достигается за счёт legacy C.
P>std::sort это legacy С?
P>или вы имеете ввиду то, что для любого C++ кода можно написать аналогичный C код? если да, то я и не спорю — да можно, есть даже авто трансляторы с C++ на C. вот только размер аналогичного С кода будет не меньше, а в большинстве случаев больше в разы.
1. Вы понимаете, что этот аналогичный код на C, зачастую не пишется и оставляется не оптимальная версия, как раз из-за размера кода?
2. Для создания оптимального кода на C++, делать реализацию на legacy C нет необходимости(как считают многие), так как есть возможность реализовать это в разы, а то и на порядки меньшим кодом.
вы согласны с этими пунктами?
P>>Вы не поняли меня. В ваших тестах (да и в тех что я добавил, основываясь на вашем подходе), производится сравнение скорости сортировки на разных случайных наборах. А нужно делать сравнение на одинаковых, но при это всё равно случайных наборах. 1>1. Это компенсируется несколькими прогонами вот и все. Получаем медиану. Нам же ведь нужна примерное соотношение скорости, а не десятые доли процента скорости.
вы уверены, что это десятые доли процента, а не проценты или десятки процентов?
1>2. У нас довольно большой массив элементов, а диапазон их изменения не настолько велик. Фактически статистика сглаживается для таких массивов. 1>Поэтому я позволил себе каждый раз генерировать последовательность заново.
использовать одну и ту же последовательность совсем не трудно.. даже необходимо в контексте этого теста
1>>>>>>>И? Померились? P>>>>>>?? я с вами мерится не собирался, мне интересно сравнение C vc C++, без личностей... 1>>>>>Извините, если восприняли, как переход на личности (хотя подтекст не скрою)) ). Просто очевидно, что С предоставляет меньшие возможности по инициализации/освобождению ресурсов и в подобных сравнениях кода на С будет больше, чем на плюсах. P>>>>я думаю при создании функции с 10 ресурсами, как минимум большинство программистов сделает ошибку, а то и не одну. P>>>>Зачем вообще надрываться и использовать C, когда есть C++? (естественно, кроме тех случаев когда использование C++ невозможно из-за отсутствия компилятора) 1>>>Как минимум у разных людей разные предпочтения. Ну действительно — зачем надрываться и сажать картошку, если можно есть саранчу, которая сама вырастит. P>>тут я не спорю — вкусы у всех разные. P>>Но, зачастую "отрекание" от C++ в сторону C, происходит на основе неправильной интерпретации опыта. 1>Могу лишь развести руками. В сущности главное качественный конечный результат. И если человек не умеет правильно интерпретировать опыт — то пусть лучше пишет на С . Это будет выглядеть не так ужасно, как на С++.
интересные у нас с вами получаются заключения:
И если человек не умеет правильно интерпретировать опыт — то пусть лучше пишет на С
хорошо, я согласен, давайте запихаем всех неадекватов в загон "Язык C". некоторые из этого топика уже сами себя загнали
1>>>>>Ну и насчет безопастности — все таки это больше зависит от опыта. Я вот в коде допустил такую дуратскую ошибку, а в реальном коде как в Enter/Leave оборачиваются очень небольшие участки, внутри которых нет переходов за них. И участки эти в голове прокручиваю. А тут просто набросал как пример и даже не задумался, будет работать или нет. Хотя я склонен думать, что программист с малым опытом на С++ допустит меньше ошибок чем на С. Но только если будет следовать RAII, а не писать legacy. Но понимание всей прелести RAII приходит только с опытом. P>>>>Тут проблема в образовании, многие начинают учить C++ начиная с legacy C, приобретают вредные привычки, и часто далеко не выходят за пределы legacy C. Прочитайте статью http://www2.research.att.com/~bs/new_learning.pdf — мне понравилось. 1>>>Тут проблема в том что С проще и его проще учить. Ну или по крайней мере так полагает большинство авторов. P>>в статье как раз говорится что C++ легче учить (хотя бы до определённого уровня) 1>Может легче. Понятия не имею. Испытать не на ком.
будет время, прочитайте статью, с начала (а не просто сравнение сортировок)
1>>>Насчет статьи: 1>>>Я не перепечатывал код полностью — но пример данный мной в прошлом сообщении взят именно из этой статьи. И он хорошо показывает, что статья не в полне объективна. Она показывает выигрыш С++ в скорости над С. Но написав сишный код чуть-чуть подругому мы получаем диаметрально противоположный результат.
1>>>Мне очень не нравиться попытка сравнить std::sort и qsort. Как я уже сказал, qsort — это нечто вроде wchar_t под unix. Да она есть — но ей в большинстве случаев не пользуются. И она априорно медленней std::sort — что там можно сравнивать, тестировать и как на основе этого теста можно говорить, что С++ быстрей. И утверждение, что более высокий уровень абстракции и защиты от ошибок при этом дает увеличение скорости не лезет ни в какие ворота. P>>почему, по-моему как раз таки лезет. P>>1) есть две обощённые(в вашем понимании функции) qsort и std::sort 1>Причем заведомо известно, что qsort медленней std::sort P>>2) интерфейс std::sort более безопасен и менее подвержен ошибкам чем qsort 1>Верно. P>>3) при равный используемых алгоритмах сортировки std::sort будет быстрее qsort 1>Ну да. Вот я и не понимаю — что можно сравнивать. Автор этой статьи не знает как работают шаблоны? Или что? Если человек ну хоть капельку знает С и С++, то он знает правильный ответ и без этих исследований.
подождите, ну буквально чуть выше вы написали:
И утверждение, что более высокий уровень абстракции и защиты от ошибок при этом дает увеличение скорости не лезет ни в какие ворота.
давайте ещё более конкретней, прям по этому высказыванию:
std::sort vs qsort:
1) std::sort — более высокий уровень абстракции ?
2) более высокий уровень защиты от ошибок ?
3) дает увеличение скорости ?
P>>с чем из этого вы не согласны? 1>Ну если бы высокий уровень абстракции и защиты от ошибок увеличивал скорость самыми быстрыми языками были бы Lsip-подобные. Здравый смысл.
вы понимаете, что абстракции могут иметь разные реализации. и да, некоторые могут быть медленней.
но, у нас как бы разговор, и есть определённый контекст.
Конкретно я имею ввиду, что C++ позволяет писать более абстрактный, более безопасный, и более быстрый код — и всё это одновременно.
NB>ты несколько сгущаешь краски. NB>думаю, то же самое можно сказать и про твой код. NB>тут проблема не в шаблонах или макросах, а в программистах.
Проблема всегда в программистах, языки без оных не существуют.
AS>>Это всё к тому, что те кто упорно твердят — на С закат солнца делается сугубо только руками, несколько заблуждаются. Как и те кто убеждены что C++ всё сделает за них и бесплатно. NB>если не хочешь за удобство платить в рантайме, то именно что руками как бы не хотелось обратного.
Плата бывает очень разная. Скорость и удобство это самые дешёвые её варианты.
NB>и дело не только в исключениях. NB>у тебя, допустим, наследование используется? делать касты к базе приходится?
Да, Нет, а вот так )
AS>>Однако если тебе нужно точно знать кто кому сливает, дык возьми да проверь ))) Делов то. NB>ну, то есть тебя этот вопрос не сильно интересует? пинятно.
Естественно. Неужели для тебя новость что как минимум 80% программы никак не влияет на её скорость исполнения?! Да, не, не верю.
Здравствуйте, Alexéy Sudachén, Вы писали:
NB>>и дело не только в исключениях. NB>>у тебя, допустим, наследование используется? делать касты к базе приходится?
AS>Да, Нет, а вот так )
остается только за тебя порадоваться
AS>>>Однако если тебе нужно точно знать кто кому сливает, дык возьми да проверь ))) Делов то. NB>>ну, то есть тебя этот вопрос не сильно интересует? пинятно.
AS>Естественно. Неужели для тебя новость что как минимум 80% программы никак не влияет на её скорость исполнения?! Да, не, не верю.
хз. почему бы тогда не писать на питоне, допустим.
я вот когда писал "еще одну либу для матриц" не поленился сравнить производительность с ручным кодом.
тогда и понял что разговоры о умении компилеров оптимизировать шаблонный код немного преувеличены (хотя, надо отдать должное, с лямбдами они справились)
NB>>>ну, то есть тебя этот вопрос не сильно интересует? пинятно. AS>>Естественно. Неужели для тебя новость что как минимум 80% программы никак не влияет на её скорость исполнения?! Да, не, не верю. NB>хз. почему бы тогда не писать на питоне, допустим.
Ну дык у меня используются ровно два языка. С и питон. К сожалению, второй ни везде можно с собой утянуть, да и другие проблемы с ним имеются.
NB>я вот когда писал "еще одну либу для матриц" не поленился сравнить производительность с ручным кодом. NB>тогда и понял что разговоры о умении компилеров оптимизировать шаблонный код немного преувеличены (хотя, надо отдать должное, с лямбдами они справились)
Те несколько процентов, что реально требуют производительности, можно очень тщательно вылизать. Однако проблема в том, что не всегда можно заранее сказать какой именно кусок кода будет тормозить. Иногда бывают очень удивительные открытия, уж больно хитрое современное железо стало.
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>>>В остальном, можно по существу что напрягает адепта двух плюсов в этом коде? Макросы? Это как бы прямой путь реализации многих вещей в С, и не надо тащить своё табу ни них из плюсов. Минимальное знание самого языка, а не приёмов построения рекурсивного шаблонного бреда... ну, ё-моё, избавляйтесь от вредных привычек и учите синтаксис. P>>Ещё раз, ты говорил о синтаксическом онанизме. Я тебе привёл код (который по всей видимости ты и используешь), который и есть сплошной синтаксический онанизм. P>>Теперь же ты сменил пластинку, и говоришь "учите синтаксис" AS>Дык что именно в мём коде синтаксический онанизм? Несколько тривиальных макросов выполняющих постдействие? Да, они с многими конструкциями из STL рядом не стояли по сложности. Или авторелиз пула? Ну тут вообще не понятно в чём проблема. В том что ты не понял как это работает? Ну мои сожаления. )
(имхо, вопрос задан чётко и лаконично, и контекста предостаточно)
"Является ли приведённый ниже фрагмент кода синтаксическим онанизмом?: Да 21; Нет 3".
AS>Ну, по причине неадекватной сложности, ведущей к постоянной борьбе с языком, и постоянного вынужденного скатывания к синтаксическому онанизму.
То есть ты как на C++ скатывался к синтаксическому онанизму, так и на C.
Кэп mode on: Может дело не в языках, а в тебе?
P>>я спросил как это можно сделать.. P>>как пример ты привёл трёхэтажный синтаксический препроцессорный онанизм, против которого ты сам высказывался ранее
AS>Я привёл рантайм
а где именно ты привёл runtime?
AS>и один макрос который избавляет от необходимост закрытия TRY блока. Несколько тривиальных инстркуций на всю прорамму свёрнутые в ключевое слово с одназначно прозрачной семантикой ... ну видимо ты плохо знаком с проблемами С++. Возможно всего лишь в рамках букваря.
то есть когда результаты твоего синтаксического онанизма на C обвёрнуты во что-нибудь, то они уже допустимы?
Может тебе стоило попробовать делать тоже самое на C++ ?
P>>Реализацию чего? Вызова деструкторов? AS>Например реализацию исключений. Да ладно менять, хотя бы гарантировать что она есть. Про шаблонные же выверты можно просто скромно промолчать.
какого рода гарантии тебе нужны?
P>>А ты можешь менять реализацию if/while/for/goto на C? "ой, а шо так?". AS>Шутку понял, смешно. Теперь осталось тебе понять о чём говорил я, но для этого правда надо написать несколько лямов строк кода на С++ и наступить хотя бы на основные грабли.
То есть ты намекаешь, что сам, лично написал пару лямов строк кода?
За сколько лет?
И сколько конкретно "лямов"?
P>>парень, ты уже что-то совсем желчью исходишь.. [зевок] уже совсем не интересно.. AS>Гы, ну дык, ты даже не смог пример привести без очевидных ляпов, конечно не интересно. Как малышу в универе.
(имхо, вопрос задан чётко и лаконично, и контекста предостаточно) P>"Является ли приведённый ниже фрагмент кода синтаксическим онанизмом?: Да 21; Нет 3".
Пошутил да. )))) Вообще-то ровно в том же объёме что и RAII, иначе говоря нет, не является. А то что миллионы мух... ну ты сам знаешь, дык вот мне это сугубо фиолетово. Кстати, показательно что 3 человека язык таки знают.
AS>>Ну, по причине неадекватной сложности, ведущей к постоянной борьбе с языком, и постоянного вынужденного скатывания к синтаксическому онанизму. P>То есть ты как на C++ скатывался к синтаксическому онанизму, так и на C. P>Кэп mode on: Может дело не в языках, а в тебе?
Может быть, а может и в том, что ты не знаком с разными методами писания кода на C недостойном внимания настоящих мачо, ограничившись вузовским введением перед прыжком в гламурно-сахарный С++?
P>>>я спросил как это можно сделать.. P>>>как пример ты привёл трёхэтажный синтаксический препроцессорный онанизм, против которого ты сам высказывался ранее
В макросах, количество которых можно пересчитать по пальцам? Кстати, ты уж разъясни в чём именно там онанизм? В использовании препроцессора? Может некоторое неоднозначное поведение, сложная логика, комплексное использование нетривиальных приёмов программирования без особой надобности? Или может быть это можно сделать как-то существенно проще, прямо в коде без расписывания на каждый чих что потом делать с созданным объектом. Дык это, продемонстрируй свой интеллект и глубокое знания языка. Только пожалуйста без упоминание в КАЖДОЙ строчки кода неких этажных конструкций с отсылкой на скрытое поведение. И да, не попади при этом под анальные кары адептов двух плюсов, они же таки шалуны, начинают кипятиться только от одного упоминания new в коде, а сырые касты их вообще взрывают. Так что осторожнее там. Сисиек побольше или всякого там std:: хлама, ну и вообще шоб компилер заценил... минуты так на две минимум )))
P>а где именно ты привёл runtime?
Это ты привёл кусок моего рантайма. Весь yoyo и фактически и есть рантайм.
Плюс несколько макросов расширяющих язык специальными конструкциями, которые локальны и на написание остального кода практически не влияют. Есть ровно одно правило — всё что осталось на пуле будет освобождено при выходе из маркированного блока, и никаких магических заклинаний. Макрос лишь просто вставка очистки пула в конец блока. В этом и есть существенный плюс в сравнении с двумя плюсами.
P>то есть когда результаты твоего синтаксического онанизма на C обвёрнуты во что-нибудь, то они уже допустимы? P>Может тебе стоило попробовать делать тоже самое на C++ ?
А ты вот попробуй. ))) Покажи своё владение силой, Люк. Напиши ровно то же что и я, только на С++, хоть с STL, хоть с сиськами, с чем угодно. Давай сравним простоту, понятность кода и конечно же количество использованных сущностей и их внутреннюю сложность. Только рабочий пример, а не сферического коня в вакууме.
AS>>Например реализацию исключений. Да ладно менять, хотя бы гарантировать что она есть. Про шаблонные же выверты можно просто скромно промолчать. P>какого рода гарантии тебе нужны?
Хотя бы просто то что я МОГУ их использовать. Я знаешь ли уже не раз сталкивался с случаями когда каменный цветок упорно отказывался выходить.
P>То есть ты намекаешь, что сам, лично написал пару лямов строк кода? P>За сколько лет?
Больше ))) Много больше ляма только в своих собственных проектах, для души так сказать. В рамках эксперимента, посмотреть что будет если делать так, и вот так, и ещё вот так, если это вообще работать будет. Но куда тебе такое понять, если для тебя даже работающий пример написать проблема непреодолимой сложности.
Коли пошёл такой разговор, вот вы товарищ аноним, вы ваще кто будете?
AS>>Гы, ну дык, ты даже не смог пример привести без очевидных ляпов, конечно не интересно. Как малышу в универе. P>Какие ляпы, ты о чём?
От твоём сферическом коне в вакууме. Сходи что ли к старшим товарищам, попроси их объяснить что именно я тебе показал в расширенном варианте. ))) Я же уже говорил — благотворительность не занимаюсь.
:
как бы не хотелось обратного.
