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

AS>Мне из какого файла STL привести кусок кода в качестве примера? ИМХО из любого. Я уж не говорю про силиконовый (или какой другой) протез, без которого писать на плюсах по человечески невозможно.

А что конкретно в реализации СТЛ вызывает затруднения?

AS>В остальном, можно по существу что напрягает адепта двух плюсов в этом коде? Макросы? Это как бы прямой путь реализации многих вещей в С, и не надо тащить своё табу ни них из плюсов. Минимальное знание самого языка, а не приёмов построения рекурсивного шаблонного бреда... ну, ё-моё, избавляйтесь от вредных привычек и учите синтаксис.

М... Ты уже научил интеловский компилер синтаксису С?
Ну и проверять, справляется ли оптимизатор с такими построениями -- не самая интересная задача.

AS>Хотя мы вроде как не о реализации рантайма спорили, а о том можно ли написать на С код с автоматическим управлением ресурсами толерантный к исключениям, я привёл РАБОЧИЙ (в отличии от тебя) пример что можно, и очень просто. На больших объёмах кода проще чем в плюсах, между прочим. Но уж коли мы пошли в реализацию...

Пару вопросов.
1. на сколько это

while ( nfo->auto_top >= L )
   q->cleanup(q->ptr);

сливает плюсовым исключениям?

2.как у тебя реализована такая штука:

{
   ObjectWithDestructor array[256];
}

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

E>Просто ему статья Страуст. слегка помыла мозг примером qsort vs std::sort.
Не думаю. Пример на самом деле отлично демонстрирует разницу между обычной функцией с callback и шаблонной функцией с предикатом.

E> Он даже не верит, что может быть ситуация, когда qsort гибче и когда qsort быстрее
Дык я тоже не верю, мне доказательства нужны.

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

CC>>Сколько бы у тебя опыта не было — недостаток автоматики в С это никак не исправляет. С этим можно только смириться и писать всё руками.
E>Обсуждалось совсем другое, вроде как.
Да тут уже такой срач развели что тяжко отследить что там на самом деле обсуждали.
Надо всю ветку сносить к троллям в КСВ .

E>А так, да, можешь считать, что С-программы намного в болььшей степени hand-made
Да чего там считать, я на plain C пописал достаточно чтоб за это его недолюбливать.

E> потому и хороши.
Не соглашусь. Как только надо писать что либо относительно крупное то это становится нефиговым недостатком. Очень много времени уходит на восходы и закаты небесных светил вручную. Особенно ощущается когда с другого языка приходишь.

E>Выписанность кода руками вообще не считается недостатком, это достоинство.
Вот тока когда сам эти художества выписываешь, причём дофига выписываний это то, что в том же С++ работает автоматически, то как то заколёбывает. Хочется воткнуть нормальные классы, операторы, контейнеры и прочие радости жизни.

P>>>>>>Я не совсем понял, вы используете подмножество C++ ?
P>>>>>> Или просто C?
AS>>>>>С и С++ разные языки. Считать один подмножеством другого — большая ошибка, говорящая о незнании одного из языков, ну или обоих.
P>> это был не вопрос, а цитата, с целью ткнуть тебя в то, что я знаю что С — не полностью входит в C++. а ты распетушился...

Молодец, ткнул. Возьми конфетку )))

С примером, в котором очевидно где 'видно что безопасней и легче', когда тыкать будешь?! А то мне прям как-то интересно даже. Чувствую во мне тролль просыпается и жрать хочет. Надо ещё наверное C-стайл пример с сортировкой привести, шоб ваще весело стало )))) Хотя не, давай сначала с управлением ресурсами разберёмся.

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

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

Дабы завершить наши препирательства:
Изначально я и обратил ваше внимание, на то, что С++ не позволяет писать более быстрые приложения, чем С.
http://www.rsdn.ru/poll/3562.aspx

Автор: m2l
Дата: 13.05.12
Вопрос: Товарищь Piko полагает, что С++ позволяет писать более быстрый код, чем С. Цитата:
"Конкретно я имею ввиду, что C++ позволяет писать более абстрактный, более безопасный, и более быстрый код — и всё это одновременно."
В связи с чем мне интересно, кто ещё думает, что С++ позволяет писать более быстрый код, чем С. (Не меньше кода, не больше абстракций, не быстрей, а именно более быстрый).
Вопрос: С++ позволяет писать более быстрый код чем С?

К моей радости, большая часть аудитории данного форума это понимают. И я даже не знаю, как объяснить это вам, потому, что это фундаментальное знание — и если вы знаете С++, вы понимаете, почему так.
Могу лишь понадеется, что в будущем, когда у вас будет больше опыта вы поймете, почему были неправы.

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

P>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.
Слушай, чего ты разоряешься? Хотят писать на С — хай пишут. Это их геморрой.

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

1>Если вы знаете, что токае ассемблерный листинг, то уж должны то понимать, почему на С++ нельзя писать код более быстрый, чем на С. Равный да. Медленней да. Быстрей нет.

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

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

E>Суть в том, что на С и С++ пишут ПО РАЗНОМУ.
Капитан на линии?

E>Но прикольно тут не это, а то, что вам с Пико было не очевидно, как получить пример тормозов std::sort'а...
Конкретно сам std::sort алгоритмически не идеален, факт. Я прекрасно понял на что ты намекаешь — на использование оператора сравнения c семантикой bool operator < (), т.е. чтоб проверить на == надо его вызывать дважды.
Вот только разговор шёл не об этом. А о темплейтном коде с предикатом.
Берём твой тест счётчик вызовов компаратора.
Лёгким движением руки делаем простой тест: клонируем std::sort, и меняем там предикат так, чтоб он принимал int (< 0, == 0, > 0).
Меняем соответственно вызывающий код.

#include <CrayLib.h>
#include <stdlib.h>
#include <algorithm>
#include <vector>

class RandNum {
    int body;
    static int countCpp;
    static int countC;
public:
    RandNum() : body( rand() ) {}

    static int CmpImpl( const RandNum* arg1, const RandNum* arg2 )
    { countC++; return arg1->body - arg2->body; }
    static int CPPCmpImpl( const RandNum& arg1, const RandNum& arg2 )
    { countCpp++; return arg1.body - arg2.body; }
    static int Cmp( const void* arg1, const void* arg2 ) { return CmpImpl( (const RandNum*) arg1,  (const RandNum*) arg2 ); }

    static const int CppCount() { return countCpp; }
    static const int CCount() { return countC; }
};

int RandNum::countC = 0;
int RandNum::countCpp = 0;

void RN_test( int n = 1000 )
{
    std::vector<RandNum> arrCpp;
    for( int i = 0; i < n; i++ ) {
        arrCpp.push_back( RandNum() );
    }
    std::vector<RandNum> arrC( arrCpp );

    qsort( &arrC[0], arrC.size(), sizeof( RandNum ), RandNum::Cmp );
    mod_sort( arrCpp.begin(), arrCpp.end(), [] (const RandNum& a, const RandNum& b)    {return RandNum::CPPCmpImpl (a, b);});

  printf ("C: %u : C++: %u\n", RandNum::CCount(), RandNum::CppCount());
    printf ("%u\n", RandNum::CppCount() * 100 / RandNum::CCount());
}

int main ()
{
    RN_test ();
}

И внезапно получаем:
C: 12048 : C++: 11866
98

E>вы и правда не видите, что std::sort пессимизирован в угоду красоте и реюзабельности кода, я просто показал вам код и пример.
Мы не обсуждаем конкретную реализацию std::sort. Мы обсуждаем подход: шаблонный код с вкомпиливаемым компаратором vs отдельный заранее скомпиленный код с функцией-компаратором.

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

P>Я вопрос задал не ради предубеждения или холивара.
P>Мне действительно интересно, где сейчас реально может понадобится чистый C, и не подойдёт использование C++ (какого-либо его подмножества).

Речь не идет о "чистом Си", речь идет о его "осовремененном" диалекте — формально, о "стандарте" 99 года.
Только законченному идиоту придет в голову писать ОС, или упаси бог, ядро этой ОС на С++, используя концепцию ООП, особенно в CLI нотации.
Я успешно использую Си и С99 в двух "почти" своих проектах, ( не могу сказать каких, в виду подписанного мною NDA ).
И в 80-90% случаев предпочитаю использовать С99 при создании игр, и ОС RMOS для своего парка техники ( роботроника )

P.S. Я не отказываюсь от ООП, если вы это имели ввиду. Просто у нас с Б. Страуструпом разные точки зрения по этому поводу

AS>>Ну, по причине неадекватной сложности, ведущей к постоянной борьбе с языком, и постоянного вынужденного скатывания к синтаксическому онанизму. Плюс к тому ещё и высокая сложности разбора крешей в случае использования 'правильных' либ.
P>если какие-то средства языка сложны для вас в использовании — не используйте их, если какие-то либы для вас не удобны — не используйте их, но это не причины баннить весь язык и все либы.

Дык, он же весь такой )))

P>что привело? переписывание на C? Так может если бы второй раз на C++ переписали, получилось бы не хуже?
P>Я не совсем понял, вы используете подмножество C++ ?
P>Или просто C? Как объектную модель можно на C сэумлировать — мне понятно. Но вот исключения и автоматическое управление ресурсами на С — сходу не соображу как сделать.

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

Тут нельзя сказать хуже/лучше. Проще, понятнее, удобнее ... всё субъективные характеристики.

Вот вам как пример одного из аспектов (а их много...), кошмарный сон — представьте себе что вы такой крутой С++ программер, ну скажем, один такой крутой на целый на город. Александреску там вкуриваете с полпинка, на шаблонах не материтесь, а прямо таки излагаете. И в коде у вас прямо таки полный фашизм контроль и порядок, все байты по струнке ходють. Круто да? И вдруг вам нужно часть своей работы делегировать кому-то ещё... упс, да?

AS>>Как бы для уточнения, я использую С не по тому что не знаю или не умею готовить С++, но именно по тому что неплохо умею готовить и тот и другой. Дык вот, старый добрый С оказался на практике гораздо приятнее.
P>ну — дело ваше, кому-то на ассемблере приятней.

Ну вот и ладненько )

AS>>То что С++ как-то сильно влияет на обнаружение ошибок в отличии от С — миф.
P>Как реализовать на C: ....

А зачем? Вам это как-то РЕАЛЬНО хоть раз помогло? Мне нет. А с поправкой на весь синтаксический онанизм что с этим связан, это ваще бессмысленно и даже вредно.

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

AS>>С и С++ разные языки. Считать один подмножеством другого — большая ошибка, говорящая о незнании одного из языков, ну или обоих.
P>Что мешает использовать то подмножество C++, которое комфортно вам? (я знаю что множество C не полностью входит в C++)

Тем что это не даёт возможности решать задачу в терминах С. Недоступны принципиальные возможности, дико порицаемые адептами двух плюсов. Если вы сможете компилировать свой C код C++ компилятором, то вам просто кажется что вы пишете на С, но на самом деле лишь на подмножестве С++.

Ну и самое важное, человек будет писать на кастрированном С++! Чётко понимать это и постоянно донимать работодателя на тему разрешить от эту и от эту фишку С++, что в конечном случае приведёт к тому к чему всегда приводит — вместо решения задачи, будет решаться задача как это правильно сделать на С++. Иначе говоря люди будут вместо работы заниматься синтаксическим онанизмом, результат которого для понимания будет требовать ещё большей квалификации чем та которая была у аФФтАра.

ИМХО, но страус просто неАсилил научится писать на С )))

AS>>То что вы чего-то не видите или не соображаете, означает ровно то что означает. Как сделать я уже не раз писал.
P>если вам трудно описать как вы используете автоматическое управление ресурсами на C и исключения, хотя бы в паре предложений, я не вижу смысла продолжения моего общения с вами

Дык, сделайте усилие, небольшое такое, гляньте хотя бы в избранное что ли. На КЫВТ'е все такие гордые, что даже брезгают посмотреть чего до этого писал их собеседник. ))) То что вы смысла не видите, дык енто дело сугубо ваше. Неужто вы думаете, меня сколь бы то ни было расстроит, что вы сужаете своё восприятие действительности?!

P.S.

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

Здравствуйте, 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, Вы писали:

AS>>Ну, по причине неадекватной сложности, ведущей к постоянной борьбе с языком, и постоянного вынужденного скатывания к синтаксическому онанизму. Плюс к тому ещё и высокая сложности разбора крешей в случае использования 'правильных' либ.
AS>>Привело к серьёзному упрощению кода, который теперь можно понять не изучая в течении нескольких лет методы высокой магии и прорицания в пространствах синтаксических подсластителей.

P>Синтаксический онанизм говоришь? методы высокой магии? прорицание в пространствах синтаксических подсластителей? серьёзное упрощение кода?
P>ну-ну :

Ох, порвал как тузик грелку!

Мне из какого файла STL привести кусок кода в качестве примера? ИМХО из любого. Я уж не говорю про силиконовый (или какой другой) протез, без которого писать на плюсах по человечески невозможно.

Я согласен что для идиотов, что не знают самого языка, но с упоением спорят о метафизики и шаблонах, пара свичей ещё тот бетхерт, но вот проблема — содержимое продукта лихорадочного бреда Степанова сих индивидуумов ваще вгонит в глубокий когнитивный диссонанс, а силиконовые сиськи порвут как капля никотина хомяка. Но кто же лазит разбираться как устроены сиськи?

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

Хотя мы вроде как не о реализации рантайма спорили, а о том можно ли написать на С код с автоматическим управлением ресурсами толерантный к исключениям, я привёл РАБОЧИЙ (в отличии от тебя) пример что можно, и очень просто. На больших объёмах кода проще чем в плюсах, между прочим. Но уж коли мы пошли в реализацию ... ты можешь менять реализацию под конкретную платформу в С++, ой а шо так? Или хотя бы иметь гарантии по способу реализации механизмов, или хотя бы гарантии что они вообще реализованы? Вопрос типа риторический. )

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

P>>>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.
CC>>Слушай, чего ты разоряешься? Хотят писать на С — хай пишут. Это их геморрой.

P>Если честно, хотелось услышать аргументы против. В ответ услышал старые перепетые мифы, и ни одного аргумента

[надевая пенсне]
Ой ну ви таки послушайте наконец старого одесского тролля жителя: таки ничего вам тут нового не скажут! Все их стереотипы провоняли нафталином, ну так и хай они себе дальше грызут свой кактус, если они считают что по вкусу он аккурат как текила.
[снимая пенсне]

Забей. Проще пристрелить чем добиться аргументированного ответа.

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

Ты не улыбки ставь а на вопросы ответь.
А то блаблабла ты умеешь, как насчёт аргументированного и развёрнутого ответа, базирующегося исключительно на проверяемых фактах?

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

E>Не затруднит пояснить с чем конкретно ты не согласен и почему? Ну кроме тона...
С формулировкой в стиле "первые 10 лет в тюрьме тяжело, а потом привыкнешь".
Сколько бы у тебя опыта не было — недостаток автоматики в С это никак не исправляет. С этим можно только смириться и писать всё руками.

CC>>Советовать.
E>IMHO, советую как-то иначе, в иных тонах и наклонениях и т. п...
Тон бывает в устной речи. Как его углядеть в тексте —

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

E> у меня, например, возвращает 182%
98
Читай рядом как так вышло.
PS. STL — на помоечку, я давно это говорю!

P>А зачем вообще может понадобится использовать C, когда есть C++ ?
В С99 есть киллер фича — динамические массивы. Сразу, пока меня не ткнули в вектор — их можно создавать на стеке, и тогда они
а. быстрее
б. не приводят к фрагментации памяти.

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

И наконец, сообщения об ошибках от С компилятора, как правило, в разы более вменяемые.

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

Здравствуйте, Piko, Вы писали:
P>Конкретно я имею ввиду, что C++ позволяет писать более абстрактный, более безопасный, и более быстрый код — и всё это одновременно.

Но очень мало кто умеет это делать. Кроме того, если вернуться к реальности, то кодер. который хреначит тысячи строк простого С-подобного кода в день и выдаёт приемлемое качество, намного дешевле мегаперца, который вам всё супер-пупер спроектирует и реализует, так, что это будет более абстрактный, безопасный и быстрый код одновременно, и не write-only при этом

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

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

C>не лажает, просто у нет такой у неё цели, еще в момент появления С99 они открыто сказали, что цель поддерживать С99 перед собой не ставят, концентрируя своё внимание на С++.

Эх, если бы... Все же видели, как они C++11 продвигают, в VC11 кроме библиотеки почти ничего не поменяли, default-delete, enum class, да range-based for, который у них и так был в виде for each(a in b), только синтаксис переделали.

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

AD>>Здравствуйте, org_256, Вы писали:
_>>>А мое сугубо субъективное мнение, многократно подтверждаемое моим субъективным опытом,
_>>>вряд ли вам будет интересно...

AD>>Нет, нет. Мне очень интересно.

_>Тогда объясните, чего конкретно вы от меня желаете услышать???

Примеры из вашего субъективного опыта, подтверждающие ваше высказывание. Достаточно одного примера.

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

_>Какое именно высказывание? Хотелось бы побольше конкретики... ( Выделенное жирным вырвано из контекста )

Вот это:

_>Речь не идет о "чистом Си", речь идет о его "осовремененном" диалекте — формально, о "стандарте" 99 года.
_>Только законченному идиоту придет в голову писать ОС, или упаси бог, ядро этой ОС на С++, используя концепцию ООП, особенно в CLI нотации.

в сообщении http://www.rsdn.ru/forum/cpp.applied/4730945.1.aspx

Автор: org_256
Дата: 09.05.12

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

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

_>>Какое именно высказывание? Хотелось бы побольше конкретики... ( Выделенное жирным вырвано из контекста )

AD>Вот это:

_>>Речь не идет о "чистом Си", речь идет о его "осовремененном" диалекте — формально, о "стандарте" 99 года.
_>>Только законченному идиоту придет в голову писать ОС, или упаси бог, ядро этой ОС на С++, используя концепцию ООП, особенно в CLI нотации.

AD>в сообщении http://www.rsdn.ru/forum/cpp.applied/4730945.1.aspx

Автор: org_256
Дата: 09.05.12

Вы ожидаете от меня услышать что то что можно оспорить. Я повторяю, ничего объективного, т.е. фактического, обусловленного объяснением за пределами конкретной личности ( индивида ), вы от меня не услышите, потому-что просто не захотите слушать. А мое субъективное мнение( т.е. мнение, сформировавшееся за счёт личного, субъективного опыта, характерного только для меня) вас вряд ли порадует. За сим не вижу смысла в вашем вопросе.

Если вы действительно просто желаете спорить, или убедить меня в чем-то ( подозреваю собака тут покопалась ), то боюсь к сожалению вам придется указать мне успешные конкурентноспособные ОС преимущественно ядро которых написано на С++... если таких нет, какой смысл дальше препираться?

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

_>Если вы действительно просто желаете спорить, или убедить меня в чем-то ( подозреваю собака тут покопалась ), то боюсь к сожалению вам придется указать мне успешные конкурентноспособные ОС преимущественно ядро которых написано на С++... если таких нет, какой смысл дальше препираться?

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

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

P>Здравствуйте, 11molniev, Вы писали:

_>>>>>>1. Большую часть времени я пишу для платформы с большим ограничением по пространству-времени. ( робототехника )
P>>>>>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.
1>>>>Вы можите аргументировать, почему С++ позволяет писать более оптимальные программы? Равные — безусловно. При равном объеме кода — тоже. Но в общем случае "более", звучит довольно странно.
P>>>http://www.rsdn.ru/forum/cpp/4731645.1.aspx

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

P>>>пример qsort vs sort.
P>>>В qsort — runtime decision, в sort — compile-time, отсюда и скорость. И это не единственный пример.
1>>Я то понимаю разницу между ними, но в том то и дело, что в чистом Си обычно именно compile-time.
P>Ну так там где в C возможно compile-time, оно возможно и в C++, причём в C++ — оно достигается намного легче/лучше/красивее. Я не призываю раздувать иерархии классов с виртуальным методами, там где возможно compile-time, и да я признаю что многие C++ проекты страдают от этого (из-за низкой квалификации разработчиков, и из-за слепого применения методов из других языков и т.п.)
Дык о том речь, что runtime decision получаеться в Си только посредством усилий разработчика, а в плюсах и без оных.

_>>>>>>7. Если бы все мои задачи требовали быстрого решения и реализации и не были бы требовательны к скорости выполнения и размерам кода, то да, я бы стал использовать С++ постоянно, даже не смотря на то, что этот язык просто чисто физически не возможно выучить на все 100%.
P>>>>>даже выучив 50% C++, вы сможете делать более быстрые программы чем на C, либо более компактные чем на C (вообще одновременно максимальная компактность и максимальная скорость почти никогда не достигаются одновременно, в том числе и на C)
1>>>>Вопрос к пункту один.
P>>>ну так я не говорил что всегда одновременно получается достигнуть и скорость и компактность. либо то, либо другое, причём на C++ обе цели (по отдельности) достигаются легче чем на C.
1>>ОК. Компактность — безусловно. Но скорость то на С++ достигается за счет legacy C.
P>это заблуждение. std::sort — это legacy C? expression templates — это legacy C? и т.п.
std::sort, expression templates, это способ уменьшить объем кода, а не ускорить его выполнение. В чем заблуждение?

P>>>Вы понимаете почему std::sort быстрее? Посмотрите на ссылки которые я дал — там sort в несколько раз быстрее.
1>>Быстрей, потому что qsort делает вызовы функции сравнения. Лишние call/ret + использование стека по сравнению с С++.
P>даже если вызов функции сравнения в C++ не заинлайнится (то есть будет call/ret + stack), sort всё равно будет быстрее, так как прямой вызов.
qsort из Си будет медленней, чем std::sort. std::sort будет медленней алгоритма сортировки для double*. C++ выигрывает в скорости при одинаковом объеме кода, проигрывает при разном.

1>>Реализация qsort под массив float без callback-a будет быстрей std::sort.
1>>И таки не в несколько раз: 1,7 для 32 и 1,4 для 64 кода.
P>Это ещё почему? для std::sort callback'и как правило инлайнятся.
Потому что оверхейд больший. Если хотите скину код, состряпанный на скорую руку. Для qsort кстати функция сравнения не инлайница — разница в скорости 32/64 скорей всего объединяться разной формой передачи аргументов по умолчанию (не проверял, могу ошибаться).

P>>>не согласен: во-первых больше кода — больше ошибок, во-вторых такие штуки как RAII исключают возможность целых классов ошибок — то есть если вы знаете и используете RAII, то вы чисто технически не сможете сделать целую кучу ошибок.
1>>Это (в том числе и RAII) компенсируется в Си стандартом кодирования + выделением отдельного слоя api. Гарантия конечно не такая надежная, люди ошибаются чаще машин — но вполне себе работает.

P>так я не говорю что оно "вообще не работает". оно работает, но на C++ оно получается быстрее и безопасней.
P>ну вот пример, в блоке кода, пусть в функции, нужно при входе захватить мьютекс, открыть файл, и выделить память, при выходе соответственно нужно всё убрать.
P>Вы можете показать как это делается на C (в более-менее псевдокоде, 100% компилируемый исходник не нужен. просто используйте C-style), причём безопасно, с обработкой ошибок. + показать вызов такой функции.

ОК, я не стал все копировать, но общие моменты я думаю будут ясны.
В stdafx.h:
#define MALLOC(x) (x*)memalloc(sizeof(x))
#define ZEROPTR(x) memset(x, 0, sizeof(*x))
#define SAFEALLOC(xpointer, xtype) { xpointer = MALLOC(xtype); RETNULL(xpointer); ZEROPTR(xpointer); }
#define RETNULL(x) if (NULL == (x) ) goto ret;
#define CODE_ERROR SIZE_MAX
#define CODE_SUCCESS 0
#define RETERROR(x) { if (CODE_SUCCESS != x) goto ret; }
#define RETEQU(x, y) if ( (y) == (x) ) goto ret;

В коде:
t_error function name(...) {
HANDLE h = INVALID_HANDLE_VALUE;
struct name *name;
void * p = NULL;
t_error = CODE_ERROR_BAG...;
....
EnterCriticalSection(&cs);
SAFEALLOC(name, struct name);
RETEQU(INVALID_HANDLE_VALUE, h = CreateFile(...) );
RETNULL( p = memalloc( ... ) );

LeaveCriticalSection(&cs);
r = CODE_SUCCESS;
ret:
memfree(name);
memfree(p);
CloseHandle(h);
return r;
}

Вызов:
RETERROR( name(...) );


1>>В качестве примера можно привести nginx — чистый Си, ничего не течет.

P>вообще не аргумент.
P>можно что угодно написать хоть на ассемблере без протечек...
И да и нет. Подобный пример опровергает утверждение, что больше кода — больше ошибок. Есть ещё человеческий фактор.

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

P>Здравствуйте, 11molniev, Вы писали:

P>>>а чем принципиально indirect call отличается от virtual call в контексте runtime decision? и то и то получается посредством усилий разработчика
1>>В С эти усилия всегда в явном виде. С++ можно и без усилий получить их по дефолту. Проще говоря на чистом Си тормоза всегда являются результатом осознанного решения разработчика. Только то и всего.
P>а где в C++ их можно получить по дефолту, да так чтобы не знать об этом?
P>я когда пишу virtual — всегда осознаю, что в 99% случаев это будет indirect call через vtable
Сама концепция объекта как черного ящика их предполагает.

P>>>или вы имеете ввиду то, что для любого C++ кода можно написать аналогичный C код? если да, то я и не спорю — да можно, есть даже авто трансляторы с C++ на C. вот только размер аналогичного С кода будет не меньше, а в большинстве случаев больше в разы.
1>>Нет. Я имею в виду, что получить максимальную скорость в плюсах можно используя для критичных участков кода чистый Си. Если вместо вызова std::sort вы напишите быстрою сортировку на си, она будет работать быстрей.
P>надо попробовать в эту ручную сортировку привести к интерфейсу std::sort, может разность в скорости обуславливается разными алгоритмами?
Разница обусловлена только тем, что std::sort будучи функцией с большей функциональностью (в плане данных над которыми она применяется) за эту функциональность платит скоростью. Более общее решение всегда медленней частного.
Я честно сказать не совсем улавливаю о чем мы спорим: С++ даст более компактный код. С даст более быстрый код. С++ со вставками legacy в нужных местах даст скорость, во всех остальных — компактность. Если пропихнуть вместо legacy С asm — будет ещё быстрей (если конечно есть опыт программирования на нем и время на профайлер).

1>>Ещё раз — qsort, это быстрая сортировка на Си для произвольных структур. Она заведомо проигранная в скорости. Осознанный выбор, когда в этом месте программы на её скорость можно наплевать.
1>>Да размер кода будет больше. Я собственно везде об этом и говорю. Лично для меня основное преимущество С++, когда я использую его, вместо С — это объем кода.
P>ну да, на С можно сделать тоже самое, но кода почти всегда будет больше. И вот этот дополнительный код на C, который автоматом генерируется на C++, зачастую и не пишется.
Да вы правы. Но у меня сложилась мнение, что вы считаете это только недостатком. Я же полагаю, что иногда это недостаток, а иногда достоинство.

1>>>>std::sort будет медленней алгоритма сортировки для double*.

P>>>вы имеете ввиду специальные алгоритмы (типа Radix sort) отличные от quicksort?
P>>>ну так C++ и в этом месте лучше — можно сделать специализацию для double*, либо вообще для T* — причём интерфейс не поменяется.
1>>Да нет же. И шаблоны я знаю.
1>>>>C++ выигрывает в скорости при одинаковом объеме кода, проигрывает при разном.
P>>>вы имеете ввиду использование специальных алгоритмов, для специальных случаев?
1>>Нет.
P>я просто пытался понять, что вы имели ввиду...
В коде образец. Я постараюсь объяснить, если вы сформулируете вопрос.

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 по скорости примерно одинаковы.
На N=100000000, qsort: 28.758331, std::sort: 20.791297, c: 17.333931 соотношение 1,38 и 1,199
На N=10000000 qsort: 2.567289, std::sort: 1.824936, c: 1.510803 соотношение 1,40 и 1,20
т.е. то о чем я говорю: переписывания куска кода на чистый с раздуло этот код и ускорило его работу на ~20 процентов. В два раза меньше чем использование std::sort вместо qsort — так что цифры увеличения скорости вполне сопоставимы.
Единственный момент: это 64 разрядный код, std::sort при N=100000000 на 32 битах вылетело с исключением)). Для 32 qsort vs std::sort получается в районе 1,6.

1>>>>Для qsort кстати функция сравнения не инлайница
P>>>браво
1>>Я обратил ваше внимание на то, почему в приведенном вами сравнении выигрывает С++. И как это исправить.
P>да, именно, не инлайница/indirect call это основные факты почему быстрее..
Но неинлайница, потому как qsort — функция "обобщенная". И по факту в коде она не используется. Ну как wchar_t под unix. Наверное самая близкая аналогия.

P>>>>>Вы можете показать как это делается на C (в более-менее псевдокоде, 100% компилируемый исходник не нужен. просто используйте C-style), причём безопасно, с обработкой ошибок. + показать вызов такой функции.
1>>>>ОК, я не стал все копировать, но общие моменты я думаю будут ясны.

P>>>вот буквально за 10 секунд увидел:
P>>>Я правильно понимаю, если это сфейлится
1>>>> RETNULL( p = memalloc( ... ) );
P>>>то это
1>>>> LeaveCriticalSection(&cs);
P>>>не вызовется?
1>>Да. Её следовало вынести за ret.
P>с указателями конечно немного легче тем, что free ничего не делает для для нулевых указателей.
P>Но вот чтобы вы сделали если бы было 3 совершенно абстрактных ресурса? Делали бы 3 метки?
Нет, никогда. Обращаю внимание на макросы — в них забита одна ret. В том то и смысл, что есть инициализатор. Если бы free и CloseHandle не делали этого по умолчанию сами, это выгладило бы как:
if (p) free(p);
if (INVALID_CLOSE_HANDLE != h) CloseHandle(h);
Но обычно в этом нет необходимости.

1>>И? Померились?
P>?? я с вами мерится не собирался, мне интересно сравнение C vc C++, без личностей...
Извините, если восприняли, как переход на личности (хотя подтекст не скрою)) ). Просто очевидно, что С предоставляет меньшие возможности по инициализации/освобождению ресурсов и в подобных сравнениях кода на С будет больше, чем на плюсах. Особенно если классы выносить из описания)). Поэтому я лично слабо улавливаю, что вы хотите показать этим сравнением. Код на С++ компактней. Ну так в этом то наши мнения совпадают.
Я кстати как то не обращал внимания на такой способ захвата объектов синхронизации, так что спасибо за ваш пример.

P>>>причём try, может быть намного выше в call hierarchy, когда в C надо сравнивать код всё время.
1>>И ещё чаще его там в итоге не будет для выбрасываемого типа исключения)))
P>catch(std::exception const& e){}
P>catch(...){}
Это то да. Просто некоторые "программисты" как то не удосуживаются об этом задумываться. Пихают везде буст, а исключения его нигде не ловят. Но это разуметься не в коей мере не относиться к языку.

P>>>Я думаю даже без причёсывания вашего C-style варианта, видно что безопасней и легче.
1>>Чем меряете безопасность и легкость кода? Всетаки субъективные критерии. Помимо наличия конструкторов и деструкторов.

P>легкость: кода меньше. код лаконичней. вообще не надо парится об корректном сборе ресурсов.
P>безопасность: кода меньше. код лаконичней. вообще не надо парится об корректном сборе ресурсов.

P>вы в своём коде сделали ошибку, я думаю наверняка не одну. проблема не в вас, а в самом подходе, я бы тоже сделал ошибку в вашем случае, потому что код намного сложнее.
Отчасти я с вами согласен. Но и вы отнеситесь с пониманием: С язык очень простой. Фактически — простыня вызова функций. Поэтому когда сложный алгоритм предварительно просчитан, разбит на составляющие, использование си приводит к тупому переносу алгоритма с одного языка на другой. И это тоже уменьшает ошибки. Да на С++ кода меньше и он лаконичней, но это достигается его большей информационной емкостью, а значит повышает сложность. Смотрите сами: есть класс — значит есть конструктор/деструктор, есть операция — может быть перегружена и так далее. Это уменьшает объем кода, но дизассемблерный листинг то остается один и тот же (я утирирую) — а значит на одну строчку кода в С++ приходиться больше информации, чем в С. А значит он на некую абстрактную производную от этой информации сложней.

Это безусловно довольно субъективный подход — но согласитесь, у разных людей разные вкусы. Кому то нравиться одно, кому то другое. Поэтому людям которые предпочитают чистый Си с вами согласиться тяжело — для них меньше кода отнюдь не значит безопасней и стопроцентно не значит легче.
Ну и насчет безопастности — все таки это больше зависит от опыта. Я вот в коде допустил такую дуратскую ошибку, а в реальном коде как в Enter/Leave оборачиваются очень небольшие участки, внутри которых нет переходов за них. И участки эти в голове прокручиваю. А тут просто набросал как пример и даже не задумался, будет работать или нет. Хотя я склонен думать, что программист с малым опытом на С++ допустит меньше ошибок чем на С. Но только если будет следовать RAII, а не писать legacy. Но понимание всей прелести RAII приходит только с опытом.

AS>>а давай дополним это до работающего кода?!
P>только сначала скажи зачем, и приведи аналог на C. Я ведь изначально просил псевдокод.

Зачем приводить рабочий код? Ну я даже как то в растерянности. Объяснять столь очевидные вещи человеку с претензиями... Ты меня чеслово удивляешь.

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

AS>>Как бы для того шоб горить про простоту и лёгкость, неплохо бы для начала пройти хотя бы по некоторым хитро замаскированным граблям.
P>говори конкретно про грабли, не томи...
P>диалог с тобой совсем не конструктивный получается, и утомляет [зевок]

О неее, я не благотворительная организация помогающая слабоумным. Не видишь, ну что же, это твои проблемы ))) Просто так и запишем, клиент знает С++ из букваря. Для тех кто знает чуть больше это будет самоочевидно, остальные значения не имеют. Могу лишь добавить что С++ язык множества тонких нюансов, если ты их не чувствуешь, ты можешь хоть наизусть заучить стандарт, страуса, саттера, меерса, александреску ... и всё равно писать хреновые программы.

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

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

AS>>>Мне из какого файла STL привести кусок кода в качестве примера? ИМХО из любого. Я уж не говорю про силиконовый (или какой другой) протез, без которого писать на плюсах по человечески невозможно.

NB>>А что конкретно в реализации СТЛ вызывает затруднения?

AS>Найти людей которые могут не только читать код, активно его пользующий, но и как то его менять. Причём желательно за адекватные деньги.
AS>Основная проблема С++ в том, что сопровождение кода стоит дороже его написания, и требует квалификации существенно выше чем у того, кто его писал. Такая вот парадоксальная зависимость. При условии же что чем программер лучше, тем меньше он хочет сопровождать чужой код... очевидно неинтересная.

AS>От собственно это в реализации STL у меня и вызывает затруднения.

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

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

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

AS>Однако если тебе нужно точно знать кто кому сливает, дык возьми да проверь ))) Делов то.

ну, то есть тебя этот вопрос не сильно интересует? пинятно.

AS>>Причём никакой скрытой логики я в общем-то не добавил.
E>Ну логики не добавил, а запутанности добавил... Это большой шаг в сторону write-only плюсов от сурового, но справедливого С! бойся, комрад! Программисты уже один раз ошиблись, отойдя от православного FORTRAN в сторону всяких богомерзких MODULA, PASCAL и С... Не повторяй ошибок прошлого! Стойко держись С! И выкини все эти макросы, они делают из твоего С жалкое подобие С++. Истина состоит в том, что автоматический RAII не нужен, а не в том, что путём кучи трюков его можно воспроизвести в С1

Аминь, камрад.

AS>>С++ же такое сделать в принципе невозможно, в силу концепции языка, а если бы и можно было это пошло бы в разрез с Единственным Истинно Верным Способом Программировать. )))
E>Тут ты не прав. Как учит самый главный страус-гуру, С++ -- он мультипарадигменный, там нет единственно-верного способа. Это один из его недостатков. Менеджер проекта должен ещё и парадигму выбрать, и как-то отследить, что кодеры ей следуют

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

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


1>Изначально я и обратил ваше внимание, на то, что С++ не позволяет писать более быстрые приложения, чем С.
1>http://www.rsdn.ru/poll/3562.aspx

Автор: m2l
Дата: 13.05.12
Вопрос: Товарищь Piko полагает, что С++ позволяет писать более быстрый код, чем С. Цитата:
"Конкретно я имею ввиду, что C++ позволяет писать более абстрактный, более безопасный, и более быстрый код — и всё это одновременно."
В связи с чем мне интересно, кто ещё думает, что С++ позволяет писать более быстрый код, чем С. (Не меньше кода, не больше абстракций, не быстрей, а именно более быстрый).
Вопрос: С++ позволяет писать более быстрый код чем С?

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

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

1>Позволю себе частично с вами не согласиться, все достаточно сильно зависит от решаемых задач. Бесспорно, грамотный код на С++, при реализации дублирующихся функций будет компактней, безопасней и во всех остальных отношениях (кроме, возможно сложности) лучше. Но если функциональность не дублируется или дублируется с мелкими изменениями, выходит, что приплюснутого кода получается больше, иногда ещё и с ущербом для скорости и читабельности.

Не понимаю, в чём тут отличие С и С++ даже, а не С и С-подобного подмножества С++
Мне так кажется, что у всех сторонников С в голове всё время сидят С++-темплейты. А их можно вообще не использовать, ну или использовать очень очень ограниченно, там где они реально рулят и дают огромные преимущества, например...

С++ намного больше, чем шаблоны и ООП. Там ещё есть строгая типизация, перегруженные функции, тип CComplex, можно написать нормальную строчку или класс данных, содержащий изображения, например, и т. д...
Опять же RAII и исключения всякие могут рассматриваться...
То есть есть некоторый даже не "С с классами", а "С с классами, но не с объектами". И он вроде как таки лучше С, при этом он позволяет писать всё то же, что и на С, и в общем-то так же, только проще, безопаснее, выразительнее и т. д...

Плохо, что мало есть средств автоматического ограничения С++ таким образом.

Я бы, например, как менеджер, хотел бы иметь в С++ проекте какой-то профиль, в котором было бы размечено, чего из зыка можно юзать, а чего нет. И на выход в каком-то куске кода в продакшен-сборке, требовалась бы цыфровая подпись куска каким-то начальником или экспертом...

Но такого рода инструментов в С++ вообще нет...

1>Если уж совсем грубо, то плюсы можно сравнить с архиватором — сжатие (улучшение параметров) зависит от контента и результат может оказаться больше оригинала (при этом ещё и время на распаковку будет тратиться).

Ну так это только при бездумном использовании инструмента. Причём любого. В микроскоп прекрасно видно бактерии, но орехи им колоть неудобно, а соседское окно, так и вовсе не видно...

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

P>>а на счёт скорости разработки — сколько времени этот средний программист C убьёт на отладку?
E>Не факт, что больше, чем С++...
E>У С-шника будет больше строчек, зато ошибки все будут простые, а у С++ника строчек булет меньше, зато ошибки будут заковыристее...

у C-шника будут и простые ошибки, и заковыристые. У C++ника простые ошибки поймает компилятор (при правильном использовании C++).
хотите верьте, хотите нет, имхо таким абстрактным спором мы не убедим друг друга..
думаете на C будут только простые ошибки — ну ваше право

P>>а как вы выразите бизнес логику без абстракций? Как на C, вы выразите сложение двух разряженный матриц?
E>AddBlaBlaBlaMatrix( &matrix1, &matrix2 );

ну вот и я о том же — ну очень выразительно.
а теперь сложите три матрицы, умножьте на четвёртую, потом на вектор. да причём так, чтобы сложение трёх матриц было эффективным, не (первая + вторая)+третья, а именно одновременно.
на C++ можно делать так:
(m1+m2+m3)*m4*v1,
а что будет на C?

P>>А как вы делаете большие и средние проекты, если без абстракций? Каждый уровень абстракции увеличивает на порядок то, что можно выразить
E>С уровням абстракции вроде как не мешает... Вообще, уровни абстракции -- это скорее к голове архитектора, а не к языку...

да, но в C++ больше средств выражения абстракций
и при этом они:

3. абстракции (зачастую абсолютно ничего не стоящие)

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

P>>точно такой же баг возможен и без duck-typing — например есть интерфейс с методом copy, и есть класс который реализует этот copy как move, либо вообще как remove.
E>Это легко формально проверяется и требуется.

как именно?
как проверишь то, что этот метод copy не отформатирует диск?

P>>duck-typing не причём
E>Наверное, а шаблоны С++ при чём...

при чём?

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

P>>что конкретно нужно исправить?
P>>заменить все копирования auto_ptr на move unique_ptr ?
E>Тут конкретно, ничего менять не надо. Это валидный код.
E>Но если у меня есть шаблон karusel<T>, который таки ждёт от T нормальной копируемости, но программист этого явно не выразил, так как не знал как выразить и не имел никакого инструмента заметить, чо ему это свойство надо, так вот, надо выявит, что karusel<auto_ptr<ZZZ>> -- ошибка...

заменяешь auto_ptr на unique_ptr — и смотришь что поломалось

P>>есть STL. А есть C++ Standard Library
E>Это какая-то лингвистическая магия. Типа "Стандартная Библиотека Шаблонов" или "Стандартный библиотечный шаблон"...

нет

P>>потребовать или проверить?
E>Ну вот я написал шаблон какой-то.
E>Теперь мне хорошо бы как-то получить список свойств, которые я от своего аргумента требую + как-то проверить все используемые аргументы, на наличие этих свойств.
E>Ещё бы не кисло было бы заявить требования этих свойств явно, что бы программист сразу же и не пытался бы...

http://www2.research.att.com/~bs/bs_faq2.html#constraints

ЗP>>>>>нет, хотя бы потому, что std::auto_ptr это не STL
P>>>В STL — нет auto_ptr. http://en.wikipedia.org/wiki/Standard_Template_Library
E>>Что говорил там Степанов, или что в вики кто пишет -- это всё интересно в смысле биографии этих персон. Но у С++ есть стандарт, как бы...

ИМХО, что там Cтепанов говорил, сугубо ортогонально всем тем кто пишет на реальном C++, а не на словах Степанова. В референс реализации HP/SGI, которую все в том или ином виде передрали — auto_ptr есть.

P>ну а где в стандарте написано что autp_ptr относится к STL ???

В стандарте ISO/IEC 14882 в разделе 20.4.5 Class template auto_ptr. STL же в стандарте вообще нигде не упоминается. Собственно STL к С++ имеет ровно то же отношение что и MFC. Однако для простоты STL ака Standard Template Library приравнивается к стандартной библиотеке C++. Что как бы очевидно.

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

P>Именно в STL ?
P>http://www.sgi.com/tech/stl/table_of_contents.html

Ну, то есть ты мне хочешь доказать, что в коде, который я перерыл вдоль и поперёк, чего-то нет? И нет именно потому как это не перечислено на какой-то страничке? Будь мужчиной, открой сырки да посмотри. Смотреть надо в файл memory http://www.sgi.com/tech/stl/memory.

P>>>ну а где в стандарте написано что autp_ptr относится к STL ???
AS>>В стандарте ISO/IEC 14882 в разделе 20.4.5 Class template auto_ptr. STL же в стандарте вообще нигде не упоминается. Собственно STL к С++ имеет ровно то же отношение что и MFC.
P>и какой из этого вывод?? то что auto_ptr есть в STL ?

Что auto_ptr есть в стандарте.

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

AS>Ну, то есть ты мне хочешь доказать, что в коде, который я перерыл вдоль и поперёк, чего-то нет? И нет именно потому как это не перечислено на какой-то страничке? Будь мужчиной, открой сырки да посмотри. Смотреть надо в файл memory http://www.sgi.com/tech/stl/memory.

и строки там есть http://www.sgi.com/tech/stl/string .
но главный автор STL — Степанов говорит что в STL нет строк — кому верить?

P>>>>ну а где в стандарте написано что autp_ptr относится к STL ???
AS>>>В стандарте ISO/IEC 14882 в разделе 20.4.5 Class template auto_ptr. STL же в стандарте вообще нигде не упоминается. Собственно STL к С++ имеет ровно то же отношение что и MFC.
P>>и какой из этого вывод?? то что auto_ptr есть в STL ?
AS>Что auto_ptr есть в стандарте.

не спорю — есть в стандарте

AS>>Ну, то есть ты мне хочешь доказать, что в коде, который я перерыл вдоль и поперёк, чего-то нет? И нет именно потому как это не перечислено на какой-то страничке? Будь мужчиной, открой сырки да посмотри. Смотреть надо в файл memory http://www.sgi.com/tech/stl/memory.

P>и строки там есть http://www.sgi.com/tech/stl/string .
P>но главный автор STL — Степанов говорит что в STL нет строк — кому верить?

Верить сыркам — они истина. Да и кому какое дело до того что говорит Степанов?

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

P>и какой из этого вывод?? то что auto_ptr есть в STL ?

Вывод просто. Есть ли auto_ptr в STL зависит от того, как в этой аббривиатуре расшифровывается первая буква. Если, как "степанов", то есть, но наличие не афишируется, а если как "стандартная", то есть и наличие гарантируется стандартом...

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

AS>Вот вам как пример одного из аспектов (а их много...), кошмарный сон — представьте себе что вы такой крутой С++ программер, ну скажем, один такой крутой на целый на город. Александреску там вкуриваете с полпинка, на шаблонах не материтесь, а прямо таки излагаете. И в коде у вас прямо таки полный фашизм контроль и порядок, все байты по струнке ходють. Круто да? И вдруг вам нужно часть своей работы делегировать кому-то ещё... упс, да?

Представьте что вы такой крутой С программер, ну скажем, один такой крутой на целый на город. Суровая рукопашка на макросах для имитации автоматики, goto out; goto cleanup; goto error; и т.п.
Круто да? И вдруг вам нужно часть своей работы делегировать кому-то ещё... упс, да?

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

AS>Если вы сможете компилировать свой C код C++ компилятором, то вам просто кажется что вы пишете на С, но на самом деле лишь на подмножестве С++.
Это позволит там где нужно заюзать удобную фичу из С++ а не имитировать оргазм её на макросах.

AS>Ну и самое важное, человек будет писать на кастрированном С++
И что с того?

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

AS> Иначе говоря люди будут вместо работы заниматься синтаксическим онанизмом.
Мда. У нас уже был Андрей "Синтаксический Оверхед" Губанов, теперь похоже добавился Alexey "Синтаксический Онанизм" Sudachen.

AS>ИМХО, но страус просто неАсилил научится писать на С )))
ИМХО, но ты просто неАсилил научиться писать на С++ )))

AS>Я сюда не для просвещения страждущих хожу, мне сие с некоторого момента сугубо фиолетово, но троллинга и флуда ради. Короче, поразвлекаться.
Ради троллинга вали к троллям в КСВ.

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

1>К моей радости, большая часть аудитории данного форума это понимают.
Аж 27 человек! Большая часть, ага!
Ответ на этот вопрос даст тебе профайлер, но не голосования, в которых далеко не все вообще участвуют.

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

P>>вы хотели подтвердить моё высказывание своим опросом?
1>Что 2/3 посетителей этого форума с вами совсем не согласны.
2/3 из тех, кому не лень было сунуться в это голосование.
Ни о чём, в итоге.

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


P>Действительно:
P>

P>И получаем, что std::auto_ptr не валиден. Грустно плачем и несём С++/STL на помоечку?

P>о чём спорить? если косяк в auto_ptr — для тебя это повод нести C++/stdlib на помоечку

Ты тут рассказывал, как надёжно всё можно в С++ выявить и проверить.
Я показал тебе, что твой тест не пройдёт уже стандартная библиотека С++, так что что-то надо на омоечку, либо тест, либо С++ и его стандартную библиотеку

Предложение нести на помоечку не тест, а язык было сарказмом

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

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

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

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

CC>>Представьте что вы такой крутой С программер, ну скажем, один такой крутой на целый на город. Суровая рукопашка на макросах для имитации автоматики, goto out; goto cleanup; goto error; и т.п.
E>Суть тут в том, что крутой С-программер рукопашкой на макросах страдает только если ОЧЕНЬ надо
Судя по С коду разнообразных проектов, это самое "ОЧЕНЬ надо" случается очень часто. В общем то оно и понятно, не вручную же это всё каждый раз колбасить.

E> а goto cleanup -- стандартный приём в С, примерно такой же стандартный, как RAII в С++
Я ведь не говорю что это пц как плохо. Альтернативы в С очень мало, и goto не самый плохой вариант.

CC>>Круто да? И вдруг вам нужно часть своей работы делегировать кому-то ещё... упс, да?
E>Ну, если проект нормально написан, то делигируешь без проблем.
Если ты не заметил, то мой пост практически цитата того, на что я отвечаю. Это было сделано специально чтоб показать оппоненту на нелепость категоричности его заявлений.

E> Впрочем как и на С++, только если он тоже НОРМАЛЬНО написан, а не как локи с STL...
Вооот! Ты начал подходить к правильному ответу: нормально написанный проект делегируется и поддерживается без проблем, вне зависимости написан он на С или на С++.
А вот защищаемый тобой товарищ этого понимать не желает.

CC>Представьте что вы такой крутой С программер, ну скажем, один такой крутой на целый на город. Суровая рукопашка на макросах для имитации автоматики, goto out; goto cleanup; goto error; и т.п.
CC>Круто да? И вдруг вам нужно часть своей работы делегировать кому-то ещё... упс, да?

Нет не упс.

Если вы за своим страхом шаблонов не заметили, что я как раз таки использую подход без этих симпатичных goto... (а не их имитации), это опять же показатель. Собственно, с той же серии, что и заблуждения про RAII, и фантазии про единственно верную и всё включающую модель ОО в С++. Однако, учить я никого здесь не собираю, как и доказывать что бы то ни было. Зачем? ))) Я сюда прихожу 'палочкой потыкать'.

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

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

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

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

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

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

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

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

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

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

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

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

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

Java.

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

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

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

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

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

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

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

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

CC>В нормальных это в каких? По мне так эта часть достаточно крупная чтоб заколебать через некоторое время. Всё то, что на плюсах делается контейнерами, RAII и прочими простыми упрощениями жизни тут приходится колбасить вручную каждый раз. Или делать на макросах, отлаживать которые потом то ещё развлечение.
А и не надо на макросах. Надо честно писать. а то что работа вообще штука тяжёлая -- ну так тут никто не спорит.
Мало того, ты сейчас написал, только другими словами, что на С++ прогать более ПРИКОЛЬНО, чем на С. Так это и не оспаривается. Просто, насколько я понимаю, есть идея, что когда прогать прикольно, прогеры склонны раздувать код, а когда неприкольно -- склонны сокращать...


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


E>>Я думаю, что он злит коллег, которые обсуждают персоны, а не идеи...
CC>Значит он способствует скатыванию темы в простой срач.
CC>Тем более оставь.
Месье имеет власть мне приказывать?..
тогда предъявите звезду, мой шериф!

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

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

в каких случаях qsort, по твоему мнению, быстрее?

P>>2. что надёжней
E>Зависит от задачи и от программиста

в каких случаях qsort, по твоему, мнению надёжней?

P>>3. что безопасней
E>Зависит от задачи и от программиста

в каких случаях qsort, по твоему, мнению безопасней?

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

CC>>В нормальных это в каких? По мне так эта часть достаточно крупная чтоб заколебать через некоторое время. Всё то, что на плюсах делается контейнерами, RAII и прочими простыми упрощениями жизни тут приходится колбасить вручную каждый раз. Или делать на макросах, отлаживать которые потом то ещё развлечение.
E>А и не надо на макросах. Надо честно писать. а то что работа вообще штука тяжёлая -- ну так тут никто не спорит.
Дык это получается почти копипаст. Что есть error prone и опять таки плохо поддерживаемо.

E>Мало того, ты сейчас написал, только другими словами, что на С++ прогать более ПРИКОЛЬНО, чем на С.
Более удобно. Мне достаточно написать один раз шаблонную обёртку, чтоб потом парой движений обеспечить схожий функционал в сотнях мест, где он нужен. На С для облегчения жизни у меня есть только макросы, у которых дофига ограничений и подводных камней.

E>Просто, насколько я понимаю, есть идея, что когда прогать прикольно, прогеры склонны раздувать код, а когда неприкольно -- склонны сокращать...
У меня таких идей нет. Да и идея мягко говоря странная. Мне когда "прикольно" хочется код написать максимально корректным (читай "без хаков"), простым и понятным. Когда "не прикольно" — абы скорее заработал как надо и забыть про него.

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

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

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

AS>Java.
Хреновый из тебя тролль. Очень уж толсто, на пределе трещания по швам.

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

P>>>>>ок, но сначала ответь, желательно с аргументами: qsort vs std::sЗort
P>>>>>1. что быстрее
E>>>>Зависит от задачи и от программиста
P>>>в каких случаях qsort, по твоему мнению, быстрее?
AS>> X(const X &x) { for( int i=0; i < x.q_.size(); ++i ) q_.push_back(x.q_[i]); }
AS>> qsort(&y[0],y.size(),sizeof(y[0]),(int(*)(const void*,const void*))X_sum_comp);
P>шутник, UB'шник

добавляем

bool operator < (const X& a, const X &b){
  return  N_sum(a.q_) - N_sum(b.q_);
}
void swap(X &l,X &r){
    swap(l.q_,r.q_);
}

и sort рвёт qsort, и при том без UB

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

P>>в каких случаях qsort, по твоему мнению, быстрее?
E>Слушайте, люди, вы меня правда пугаете.
E>Ты сам не можешь написать пример в котором qsort порвёт std::sort?
E>Хочешь совет? Напиши пример где функция сравнения ДОЛГАЯ.
E>Например, у тебя есть массив неотрицательных чисел,
E>чтобы сравнить два, ты от каждого вычисляешь exp( x / x_max ), с точностью 1 000 000 знаков, и потом в лексографическом с конца порядке сортируешь. Ну и чисел тысяч 10 хотя бы в массиве
E>Вот, что бы лучше думалось, попробуй угадать, что вернёт функция RN_test:

class RandNum {
E>

у меня, например, возвращает 182%

идея зачётная но, к дискуссии имеет мало отношения
это уже разница самих алгоритмов(вытекающих из интерфейсов). с тем же успехом, можно имея только предикат less, реализовать через него компаратор для qsort.
с этой точки зрения пример не удачный, имхо очевидно
с тем же успехом можно взять хорошую реализацию qsort, и плохую sort, эта тема уже обсуждалась в начале топика

P>>в каких случаях qsort, по твоему, мнению надёжней?
E>По моему мнению для всех. Ещё надёжнее, будет если её немножко шаблонно обернуть, но даже в чистом С-варианте она неверно работает только если передать не так буфер или напутать с типами.

ога, или с размером массива, или с размерам типа ...

E>Ещё надёжнее, будет если её немножко шаблонно обернуть

то есть ты согласен, что на C++ она была бы надёжней?

E>В std::sort способов накрячится есть просто невообразимое множество

не хочу опять начинать с тобой спорить на эту тему (ты же про duck-typing, отсутствие концепций и т.п.?).
но, вопрос: где по-твоему мнению программисты ошибаются чаще? с qsort или sort?
не количество возможных путей и бла-бла, а именно на практике что надёжней.

P>>>>3. что безопасней
E>>>Зависит от задачи и от программиста
P>>в каких случаях qsort, по твоему, мнению безопасней?
E>А что значит "безопаснее"? Какая модель угроз?

тот же buffer overflow

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

E>Если второе, то это очень неплохая иллюстрация, что С++ код и подхд к программированию СКРЫВАЕТ ОТ ПРОГРАММИСТА СУТЬ ДЕЛА, и это его главный и основной недостаток...

ипать, вот это выводы: в одном случае компаратор tristate — в другом обычный предикат, и ты из этого делаешь вывод, что С++ код и подхд к программированию СКРЫВАЕТ ОТ ПРОГРАММИСТА СУТЬ ДЕЛА

E>2) Про плохую и хорошую реализацию. Мы таки несём STL на помоечку или как? И то и то стандартные средства своих языков, а не поделки криворуких тенденциозных тестеров, вообще-то.

в стандартных use-case'ах sort рвёт qsort
далее, в своём же примере попробуй stable_sort

E>И авторы стандарта С++ и STL, и самого std::sort конечно же понимали, что они пессимизируют свой код примерно в два раза,

бред.
180% — это на каком компиляторе, и в каком режиме? не debug ли случайно?
и сколько выдаёт stable_sort???

E>по сравнению с С, но при этом они вынужденно пошли на это, стыдливо прикрывшись подстановкой функций обмена и сравнения
E>Как ты думаешь, зачем std::sort в STL cделан тормозом?

маразм

P>>ога, или с размером массива, или с размерам типа ...
E>Ну надо контролировать тип, это можно поручить статическому анализатору или макросу, а в С++ ещё и простому шаблону-обёртке.

макрос для контроля типа компаратора в студию. (либо поручение статическому анализатору)

E>>>Ещё надёжнее, будет если её немножко шаблонно обернуть
P>>то есть ты согласен, что на C++ она была бы надёжней?
E>Нет не согласен. На С++ писали бы как на С++ и получили бы в конце std::sort

то есть на C++ нельзя сделать сортировку, которая сортирует только массивы, принимает только указатели на компараторы, и при этом более надёжную?

E>>>В std::sort способов накрячится есть просто невообразимое множество
P>>не хочу опять начинать с тобой спорить на эту тему (ты же про duck-typing, отсутствие концепций и т.п.?).
P>>но, вопрос: где по-твоему мнению программисты ошибаются чаще? с qsort или sort?
P>>не количество возможных путей и бла-бла, а именно на практике что надёжней.
E>Я не согласен с твоим определением надёжности, но я думаю, что в готовом оттестированном коде ошибки с std::sort остаются чаще, чем с qsort...

на выделенное ответишь?

E>Но тут надо учесть, что вызвать std::sort для vector<bool> я считаю ГРУБОЙ ошибкой. Но она на С++ скорее всего никогда не будет выявлена, если только случайно, в то время как на С ей вообще не удастся закодировать...

это не ошибка
сортировка отработает с заявленной сложностью. да, константа будет большой, но во-первых никто не запрещает
сделать специализацию для vector<bool>, никто не запрещает сделать сортировку, которая принимает только обычные массивы — и при этом будет лучше qsort

P>>тот же buffer overflow
E>Очевидно, что неверные границы буфера можно передать в оба алгоритма...

я это и сказал:

в std::sort конечно тоже можно ошибиться с границей,

зачем ты меня повторяешь

но имхо — это намного реже происходит

комментарии будут?

E>Мало того, если в С-шный передают счётчик, что даёт надежду, что он будет сортировать не всю память, а посортирует какой-то кусок и расслабится, то в С++ный передают пару итераторов. Если они будут от разных массивов, то приятной вам отладки

проверка итераторов делается в debug моде, во многих реализациях из каропки

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

E>[/c]у меня, например, возвращает 182%

я тебя поздравляю, _Debug_lt небось

E>2) Про плохую и хорошую реализацию. Мы таки несём STL на помоечку или как? И то и то стандартные средства своих языков, а не поделки криворуких тенденциозных тестеров, вообще-то. И авторы стандарта С++ и STL, и самого std::sort конечно же понимали, что они пессимизируют свой код примерно в два раза, по сравнению с С, но при этом они вынужденно пошли на это, стыдливо прикрывшись подстановкой функций обмена и сравнения

ога, ога.
замени

RandNum() : body( rand() ) {}
на
RandNum() {static int cnt=100000000; body=cnt;--cnt;}

и сравни qsort, sort и stable_sort, раз уж мы об алгоритмах заговорили и об C++way
у stable_sort почти в три раз меньше вызовов предиката чем вызовов компаратора у qsort.
и что теперь?
я жду новых чудесных выводов с твоей стороны

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

P>http://www.rsdn.ru/forum/cpp/4728340.flat.24.aspx

Автор: org_256
Дата: 07.05.12

P>

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

Ну, то есть ты не понимаешь что специфика конструкторов, операторов и ограничений на обработку исключений к алгоритму сортировки не относится, но влияет на скорость и валидность? И никакая 'типа надёжность' тебя не спасёт от тривиальной опечатки или забывчивости. Ровно так же как и в С. По корке же вся эта магия только усложнит поиск проблемы. Я тебе написал пример, и что? Всё что ты увидел это UB, которого в С, с которым мы сравниваем, просто нет. Увидел что можно дописать пару заклинаний... вот только самого примера ты не увидел.

Когда скорость и корректность работы строчки кода зависит от наличия/отсутствия в области видимости неких заклинаний... это нечто, да. )))

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

P>я тебя поздравляю, _Debug_lt небось

Попробуй получить число меньше 100%

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

P>>я тебя поздравляю, _Debug_lt небось
E>Попробуй получить число меньше 100%

то есть всё таки не 180%
так получил ведь, но на stable_sort, которая также является частью стандарта который ты всё пытаешься "выкинуть на помоечку"

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

E>Сначала я думал, что вы прикалываетесь, но когда я понял, что вы и правда не видите, что std::sort пессимизирован в угоду красоте и реюзабельности кода, я просто показал вам код и пример.

ога, взяв подмышку debug_lt

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

P>то есть всё таки не 180%
Ты читаешь невнимательно. 182%...

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

P>какое первоначальное?
P>я говорил "при одинаковых алгоритмах":
P>http://www.rsdn.ru/forum/cpp/4795130.1.aspx

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

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

E>>Не могу не заметить, что это, конечно очень ценное свойство, но reverse вообще в компараторе на этих данных не нуждается и всё прекрасно сортирует

P>шутник
Ну так на тебя сморю и учусь...

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

P>является частью стандарта который ты всё пытаешься "выкинуть на помоечку"

STL вообще то надо бы на помоечку.
По крайней мере некоторые его реализации.
Ну и архитектурно там изъянов полно.

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

CC>И внезапно получаем:
CC>C: 12048 : C++: 11866
CC>98

И теперь этот новый шаблон как ёжки тестируем

CC>Мы не обсуждаем конкретную реализацию std::sort. Мы обсуждаем подход: шаблонный код с вкомпиливаемым компаратором vs отдельный заранее скомпиленный код с функцией-компаратором.

Это понятно, что если функци подставится, то может быть немного быстрее, а если функция тривиальная, то и много.
Беда тут в том, что всё станет сложнее, std::map, std::set, для всяких типов, вроде int работать из коробки не будет, либо надо будет для них функцию сравнения приивинтить и т. д...
И так выходит на круг, что фиг бы с ней, с той эффективностью, главное реюзабельность

MSVC2010 поддерживает С99?
как переключать?

Что то после 7 летней практики Lcc и GCC не могу никак привыкнуть
к С89-like требованию объявлять переменные до первого оператора

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

_>MSVC2010 поддерживает С99?
_>как переключать?

_>Что то после 7 летней практики Lcc и GCC не могу никак привыкнуть
_>к С89-like требованию объявлять переменные до первого оператора

http://connect.microsoft.com/VisualStudio/feedback/details/485416/support-c99

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

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

_>>MSVC2010 поддерживает С99?
_>>как переключать?

_>>Что то после 7 летней практики Lcc и GCC не могу никак привыкнуть
_>>к С89-like требованию объявлять переменные до первого оператора

Ops>http://connect.microsoft.com/VisualStudio/feedback/details/485416/support-c99

угу, так и понял... печалька... тогда попользь опять в DevCpp )))

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

_>MSVC2010 поддерживает С99?
_>как переключать?

_>Что то после 7 летней практики Lcc и GCC не могу никак привыкнуть
_>к С89-like требованию объявлять переменные до первого оператора

http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/

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

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

_>>MSVC2010 поддерживает С99?
_>>как переключать?

_>>Что то после 7 летней практики Lcc и GCC не могу никак привыкнуть
_>>к С89-like требованию объявлять переменные до первого оператора

C>http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/

о как! /TP заработало! спасибки!!! =)
Правда теперь на приведение к void* жалуется )))...

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

_>о как! /TP заработало! спасибки!!! =)
_>Правда теперь на приведение к void* жалуется )))...

Так это в 11, заказчикам такое не отдашь...

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

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

_>>о как! /TP заработало! спасибки!!! =)
_>>Правда теперь на приведение к void* жалуется )))...

Ops>Так это в 11, заказчикам такое не отдашь...

Мои потребители получают только бинарник и интерфейсы...
А так, я сам себе режиссёр ))) игры шароварные )))

так значит /TP просто включает поддержку C++11??? (((

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

_>Мои потребители получают только бинарник и интерфейсы...
_>А так, я сам себе режиссёр ))) игры шароварные )))

Так все-таки бета, даже не RC, мало ли какой там код нагенерит, рантайм, опять же, протухнет скоро.

_>так значит /TP просто включает поддержку C++11??? (((

А с /TC как?

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

_>так значит /TP просто включает поддержку C++11??? (((

нет, /TP /TC это опции переключатели языка компиляции, подробнее здесь. Просто Сатер пишет, что стандарты все более совмещаются, и те кто хочет в будущем использовать фичи С смогут найти некоторые из них в новом стандарте С++, для этого они должны откомпилить исходники С как исходники С++.

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

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

_>>так значит /TP просто включает поддержку C++11??? (((

C>нет, /TP /TC это опции переключатели языка компиляции, подробнее здесь. Просто Сатер пишет, что стандарты все более совмещаются, и те кто хочет в будущем использовать фичи С смогут найти некоторые из них в новом стандарте С++, для этого они должны откомпилить исходники С как исходники С++.

((( Короче опять лажает MS (((
пойду таки в GCC

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

_>((( Короче опять лажает MS (((
_>пойду таки в GCC

не лажает, просто у нет такой у неё цели, еще в момент появления С99 они открыто сказали, что цель поддерживать С99 перед собой не ставят, концентрируя своё внимание на С++.

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

_>>>так значит /TP просто включает поддержку C++11??? (((
C>>нет, /TP /TC это опции переключатели языка компиляции, подробнее здесь. Просто Сатер пишет, что стандарты все более совмещаются, и те кто хочет в будущем использовать фичи С смогут найти некоторые из них в новом стандарте С++, для этого они должны откомпилить исходники С как исходники С++.
_>((( Короче опять лажает MS (((
_>пойду таки в GCC

А зачем вообще может понадобится использовать C, когда есть C++ ?
Что мешает использовать то подмножество C++, которое комфортно вам? (я знаю что множество C не полностью входит в C++)
Единственный более-менее правдоподобный аргумент в пользу чистого C — отсутствие вменяемого C++ компилятора для нужной платформы. Да и то, давно уже есть компиляторы, преобразовывающие C++ код в C код.

http://www.youtube.com/watch?v=KlPC3O1DVcg

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


P>А зачем вообще может понадобится использовать C, когда есть C++ ?

P>http://www.youtube.com/watch?v=KlPC3O1DVcg

Мне удобней С99, проекты небольшие, есть требования к компактности и переносимости.
Я ведь вопрос не ради холливара задавал? давайте каждый останется при своем мнении?

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

P>>А зачем вообще может понадобится использовать C, когда есть C++ ?
P>>http://www.youtube.com/watch?v=KlPC3O1DVcg
_>Мне удобней С99, проекты небольшие, есть требования к компактности и переносимости.
_>Я ведь вопрос не ради холливара задавал? давайте каждый останется при своем мнении?

Я вопрос задал не ради предубеждения или холивара.
Мне действительно интересно, где сейчас реально может понадобится чистый C, и не подойдёт использование C++ (какого-либо его подмножества).

P>Я вопрос задал не ради предубеждения или холивара.

*переубеждения*

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

_>Только законченному идиоту придет в голову писать ОС, или упаси бог, ядро этой ОС на С++

А какие проблемы при этом возникнут?

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

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

_>>Только законченному идиоту придет в голову писать ОС, или упаси бог, ядро этой ОС на С++

AD>А какие проблемы при этом возникнут?

У идиота?

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

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

_>>Только законченному идиоту придет в голову писать ОС, или упаси бог, ядро этой ОС на С++

AD>А какие проблемы при этом возникнут?

И вообще, вырывать из контекста не красиво...

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

_>У идиота?

Пускай даже у идиота. Так какие будут проблемы?

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

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

_>>У идиота?

AD>Пускай даже у идиота. Так какие будут проблемы?

Обыкновенно, у идиотов не бывает проблем.

Коллега, объективного вы ничего НЕ УСЛЫШИТЕ!
А мое сугубо субъективное мнение, многократно подтверждаемое моим субъективным опытом,
вряд ли вам будет интересно...

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

_>Речь не идет о "чистом Си", речь идет о его "осовремененном" диалекте — формально, о "стандарте" 99 года.

под "чистым C" я имел ввиду просто C, один из его стандартов (например C99). "не-чистый C" в данном контексте это подмножество C++.

_>Только законченному идиоту придет в голову писать ОС, или упаси бог, ядро этой ОС на С++, используя концепцию ООП, особенно в CLI нотации.

Вообще-то C++ это далеко не только ООП. Никто не заставляет раздувать иерархию классов в ядре.
И причём тут вообще CLI???

_>P.S. Я не отказываюсь от ООП, если вы это имели ввиду. Просто у нас с Б. Страуструпом разные точки зрения по этому поводу

Да уж:
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Interactive-Panel-The-Importance-of-Being-Native
"Of course C++ is much better for kernel than C. I mean, who be stupid enough to say otherwise" 1:02:50

И дальше там идёт пояснение.

_>Я успешно использую Си и С99 в двух "почти" своих проектах, ( не могу сказать каких, в виду подписанного мною NDA ).
_>И в 80-90% случаев предпочитаю использовать С99 при создании игр

это больше похоже на blub-программиста http://en.wikipedia.org/wiki/Paul_Graham_%28computer_programmer%29#Blub
скорей всего вы просто почти не знаете C++ (без обид).

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

_>А мое сугубо субъективное мнение, многократно подтверждаемое моим субъективным опытом,
_>вряд ли вам будет интересно...

Нет, нет. Мне очень интересно.

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

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


P>Да уж:
P>http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Interactive-Panel-The-Importance-of-Being-Native
P>"Of course C++ is much better for kernel than C. I mean, who be stupid enough to say otherwise" 1:02:50

Я уже писал о расхождении точек зрения с гражданином Б. Страуструппом.

P>это больше похоже на blub-программиста http://en.wikipedia.org/wiki/Paul_Graham_%28computer_programmer%29#Blub
P>скорей всего вы просто почти не знаете C++ (без обид).

Его никто не знает. (без обид). Даже г-н Б. Страуструпп не знает.
Я знаю достаточно много языка С++ чтобы принимать решение, что мне не нужно использовать С++ в моих проектах.
Насчёт blub, не поленился таки, прочитал. Т.е. вы признаете, что раз вы так рьяно защищаете С++ то вы blub по отношению к Java, C#, или VB?

P.S. Опять же, боюсь повториться, но: Я не отказываюсь от ООП и всех исходящих плюшек.
Мне просто не нравится как "реализован" этот подход в С++.

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

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

_>>А мое сугубо субъективное мнение, многократно подтверждаемое моим субъективным опытом,
_>>вряд ли вам будет интересно...

AD>Нет, нет. Мне очень интересно.

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

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

P>>Да уж:
P>>http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Interactive-Panel-The-Importance-of-Being-Native
P>>"Of course C++ is much better for kernel than C. I mean, who be stupid enough to say otherwise" 1:02:50
_>Я уже писал о расхождении точек зрения с гражданином Б. Страуструппом.

ну так и написал "Да уж" как раз после вашего PS.

P.S. там в видео, мнения не только Страуструпа

P>>это больше похоже на blub-программиста http://en.wikipedia.org/wiki/Paul_Graham_%28computer_programmer%29#Blub
P>>скорей всего вы просто почти не знаете C++ (без обид).
_>Его никто не знает. (без обид). Даже г-н Б. Страуструпп не знает.

Я не написал "вы не знаете", а написал "почти не знаете", это разные вещи.

_>Я знаю достаточно много языка С++ чтобы принимать решение, что мне не нужно использовать С++ в моих проектах.
_>Насчёт blub, не поленился таки, прочитал. Т.е. вы признаете, что раз вы так рьяно защищаете С++ то вы blub по отношению к Java, C#, или VB?

Вы ушли куда-то не в ту степь. Я не защищаю C++, я пытаюсь понять, почему люди используют C, в тех случаях когда возможно использование подмножества C++, какие в этом преимущества. И если преимущества действительно есть (которые я сейчас не вижу), то я буду рассматривать C при выборе средства.
Причём вообще здесь все эти vm/managed языки, мы ведь говорим об Native code?
И даже если говорить про эти языки — я не говорил о них ничего, с чего вы взяли что я "blub по отношению" к ним?

_>P.S. Опять же, боюсь повториться, но: Я не отказываюсь от ООП и всех исходящих плюшек.
_> Мне просто не нравится как "реализован" этот подход в С++.

А я вообще не говорил про ООП, вы начали про него. Исходя из того, что вы так много говорите про OOP, я и сделал вывод, что С++ вы почти не знаете. Так как C++ это далеко не OOP.

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

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

AD>>>Здравствуйте, org_256, Вы писали:
_>>>>А мое сугубо субъективное мнение, многократно подтверждаемое моим субъективным опытом,
_>>>>вряд ли вам будет интересно...

AD>>>Нет, нет. Мне очень интересно.

_>>Тогда объясните, чего конкретно вы от меня желаете услышать???

AD>Примеры из вашего субъективного опыта, подтверждающие ваше высказывание. Достаточно одного примера.

Какое именно высказывание? Хотелось бы побольше конкретики... ( Выделенное жирным вырвано из контекста )

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

_>Вы ожидаете от меня услышать что то что можно оспорить. Я повторяю, ничего объективного, т.е. фактического, обусловленного объяснением за пределами конкретной личности ( индивида ), вы от меня не услышите, потому-что просто не захотите слушать. А мое субъективное мнение( т.е. мнение, сформировавшееся за счёт личного, субъективного опыта, характерного только для меня) вас вряд ли порадует. За сим не вижу смысла в вашем вопросе.

Ну вам же написали, что субъективное мнение тоже интересно:

"
_>>А мое сугубо субъективное мнение, многократно подтверждаемое моим субъективным опытом,
_>>вряд ли вам будет интересно...
AD>Нет, нет. Мне очень интересно.
"

Вы можете просто привести своё субъективное мнение, если вам не хочется — спорить вас никто не заставляет.

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

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

_>>Если вы действительно просто желаете спорить, или убедить меня в чем-то ( подозреваю собака тут покопалась ), то боюсь к сожалению вам придется указать мне успешные конкурентноспособные ОС преимущественно ядро которых написано на С++... если таких нет, какой смысл дальше препираться?

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

1. Большую часть времени я пишу для платформы с большим ограничением по пространству-времени. ( робототехника )
2. При написании игр долгое время приходилось поддерживать огромное число "слабых" машин. ( и да! можете убить меня, я пишу на голом WinAPI )
3. C++ сам по себе ни плох ни хорош. Просто лично для себя я не нашел хороших аргументов, чтобы постоянно писать всё что ни попадя только на нём.
4. Я использую и С++ как вариант подмножества Си в нём, почти не загружая код архитектурными излишествами, но часто сталкивался с кривой реализацией, и не возможностью поддерживать "чистый" Си ( без серьёзного допила )...
5. В большинстве моих проектов и задач использование С++ равносильно "стрельбе из пушки по воробьям".
6. Если я сталкиваюсь с непреодолимой необходимостью использовать С++ для нового пректа, я пониманию, что проект формализован криво и пробую перестроить его. Потому-что твёрдо уверен, что нет такой задачи, которую можно реализовать только на С++ ( я в адеквате, аргументы типа на С++ писать быстрей и проще тут не вариант )...
7. Если бы все мои задачи требовали быстрого решения и реализации и не были бы требовательны к скорости выполнения и размерам кода, то да, я бы стал использовать С++ постоянно, даже не смотря на то, что этот язык просто чисто физически не возможно выучить на все 100%.
8. Аргументы вроде: на современных машинах вызов через один указатель или через указатель на на таблицу указателей не имеет значения, потому что скорость на современных машинах ничтожна мала и не ощутима даже в супер-пупер-тестах... — для меня не аргумент...
9. Аргументы вроде: На Си глобалы, код-лапша, легко насрать куда не нужно, что провоцирует трудновылавливаемые баги — тоже не аргументы. Баги есть даже в релизном коде многих успешных продуктов.
10. Аргументны типа: можно писать Cи-like коде в самом C++ — тоже не аргумент, довелось работать в таких проектах. Половина кода на кривом С++, половина на Си, большая часть кода — вообще сторонние библиотеки на С++ со своей, невообразимой семантикой. В результате куча костылей, граблей и прочей фигни.
11. Я пишу свой код один, все мои "заказчики" — конечные потребители, поддержка моего кода ведётся только мной. Код небольшой, сложность в пределах постигаемости в одно лицо.
12. Вся RMOS ( моя система для экспериментальных роботов-манипуляторов ) написана на С99. Далее LCC->AT89C51. ( лицензия есть ).

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

_>1. Большую часть времени я пишу для платформы с большим ограничением по пространству-времени. ( робототехника )
_>...

Вообще я ожидал услышать что-то типа "В случае <бла-бла-бла> был применён С++, но от него пришлось отказаться по причине <бла-бла-бла>. Код бы переписан на си, что привело к повышению <бла-бла-бла>", а получил кучу демагогии, из которой ничего не следует. Пичалька

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

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

_>>1. Большую часть времени я пишу для платформы с большим ограничением по пространству-времени. ( робототехника )
_>>...

AD>Вообще я ожидал услышать что-то типа "В случае <бла-бла-бла> был применён С++, но от него пришлось отказаться по причине <бла-бла-бла>. Код бы переписан на си, что привело к повышению <бла-бла-бла>", а получил кучу демагогии, из которой ничего не следует. Пичалька

И вообще, каким нужно быть идиотом, чтобы создав проект, и на опираясь С++, вдруг, резко ни с того ни с сего решить даунсемплиться в Си?
Когда я создаю проект я НЕ сразу принимаю решение, а решительно обдумываю всё.
И только после тщательного анализа ситуации выбираю то или иное средство.
Просто чаще всего С99 хватает за глаза. В "стопиццотый" раз повторяю:

у меня крохотнюсенькие проекты. использование С++ в них неоправданная роскошь.

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

_>1. Большую часть времени я пишу для платформы с большим ограничением по пространству-времени. ( робототехника )

Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.

_>2. При написании игр долгое время приходилось поддерживать огромное число "слабых" машин. ( и да! можете убить меня, я пишу на голом WinAPI )

см. ответ на пункт 1.

_>3. C++ сам по себе ни плох ни хорош. Просто лично для себя я не нашел хороших аргументов, чтобы постоянно писать всё что ни попадя только на нём.

попробуйте изучить C++

_>4. Я использую и С++ как вариант подмножества Си в нём, почти не загружая код архитектурными излишествами, но часто сталкивался с кривой реализацией, и не возможностью поддерживать "чистый" Си ( без серьёзного допила )...

Очень интересно услышать примеры. И особенно дату(приблизительный год) этих примеров.

_>5. В большинстве моих проектов и задач использование С++ равносильно "стрельбе из пушки по воробьям".

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

_>6. Если я сталкиваюсь с непреодолимой необходимостью использовать С++ для нового пректа, я пониманию, что проект формализован криво и пробую перестроить его. Потому-что твёрдо уверен, что нет такой задачи, которую можно реализовать только на С++ ( я в адеквате, аргументы типа на С++ писать быстрей и проще тут не вариант )...

Выделенное — типичный аргумент (точнее не аргумент, а высказывание) blub-программиста.
Можно тоже самое сказать и про ассемблер, и даже про машину Тьюринга — на них можно реализовать любые задачи.

_>7. Если бы все мои задачи требовали быстрого решения и реализации и не были бы требовательны к скорости выполнения и размерам кода, то да, я бы стал использовать С++ постоянно, даже не смотря на то, что этот язык просто чисто физически не возможно выучить на все 100%.

даже выучив 50% C++, вы сможете делать более быстрые программы чем на C, либо более компактные чем на C (вообще одновременно максимальная компактность и максимальная скорость почти никогда не достигаются одновременно, в том числе и на C)

_>8. Аргументы вроде: на современных машинах вызов через один указатель или через указатель на на таблицу указателей не имеет значения, потому что скорость на современных машинах ничтожна мала и не ощутима даже в супер-пупер-тестах... — для меня не аргумент...

При чём тут вызов через указатель?
Там где необходимо сделать runtime decision в C++, его также необходимо сделать и в C.
Compile-time decision конечно быстрее чем runtime decision, но никто вас не заставляет делать runtime decision, где возможно compile-time. И кстати, C++ предоставляет намного более богатые возможности для реализации compile-time decision.
Ярким примером является сравнение std::sort (C++ style) vs qsort (C-style) — как вы думаете, что быстрее?
В std::sort как раз compile-time decision, а в qsort — runtime decision.
http://www2.research.att.com/~bs/new_learning.pdf
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Keynote-Bjarne-Stroustrup-Cpp11-Style

_>9. Аргументы вроде: На Си глобалы, код-лапша, легко насрать куда не нужно, что провоцирует трудновылавливаемые баги — тоже не аргументы. Баги есть даже в релизном коде многих успешных продуктов.

какие-то детские рассуждения.
То что баги есть во многих успешных проектах, ни капли не аргумент против того, что C++ позволяет писать программы с меньшим количеством багов (а значит быстрее).
При грамотном использовании C++ позволяет находить многие баги при компиляции, либо не делать их вовсе (по сравнению с C). Да, все делают ошибки, но при грамотном использовании C++ позволяет делать меньше багов чем C.

_>10. Аргументны типа: можно писать Cи-like коде в самом C++ — тоже не аргумент, довелось работать в таких проектах. Половина кода на кривом С++, половина на Си, большая часть кода — вообще сторонние библиотеки на С++ со своей, невообразимой семантикой. В результате куча костылей, граблей и прочей фигни.

Говнокод существует и в C проектах, и в C++ проектах.

_>11. Я пишу свой код один, все мои "заказчики" — конечные потребители, поддержка моего кода ведётся только мной. Код небольшой, сложность в пределах постигаемости в одно лицо.

C++ позволило бы уменьшить сложность ваших проектов и делать их быстрее.

_>12. Вся RMOS ( моя система для экспериментальных роботов-манипуляторов ) написана на С99. Далее LCC->AT89C51. ( лицензия есть ).

Как я писал ранее — отсутствие компилятора действительно может затруднять использование С++, но как я уже писал есть компиляторы транслирующие код C++ в код C.

> Ops>http://connect.microsoft.com/VisualStudio/feedback/details/485416/support-c99
>
> угу, так и понял... печалька... тогда попользь опять в DevCpp )))

Да, прикольно. Доктор отказывается пить за здоровье...

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

_>И вообще, каким нужно быть идиотом, чтобы создав проект, и на опираясь С++, вдруг, резко ни с того ни с сего решить даунсемплиться в Си?

Есть очень много причин, которые могут заставить сменить язык разработки. Для RT это можеть быть, например, несоответствие времени оклика необходимым значениям. И только идиот будет упорствовать и писать на заранее проигрышном для данной ситуации языке, зная, что это приведёт к краху проекта. Не?

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

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

_>>И вообще, каким нужно быть идиотом, чтобы создав проект, и на опираясь С++, вдруг, резко ни с того ни с сего решить даунсемплиться в Си?

AD>Есть очень много причин, которые могут заставить сменить язык разработки. Для RT это можеть быть, например, несоответствие времени оклика необходимым значениям. И только идиот будет упорствовать и писать на заранее проигрышном для данной ситуации языке, зная, что это приведёт к краху проекта. Не?

Вы говорите то же что и я только другими словами... Где смысл?

Вы читаете мои ответы другим переписчичкам? подозреваю что нет....

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

_>Если вы действительно просто желаете спорить, или убедить меня в чем-то ( подозреваю собака тут покопалась ), то боюсь к сожалению вам придется указать мне успешные конкурентноспособные ОС преимущественно ядро которых написано на С++... если таких нет, какой смысл дальше препираться?

scmrtos — собственно не ОС, а только шедулер. Можно рассматривать как ядро ОС.

Вполне себе конкурентносособная на 8-битниках и младших 32-битниках

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

P>>А зачем вообще может понадобится использовать C, когда есть C++ ?
V>В С99 есть киллер фича — динамические массивы. Сразу, пока меня не ткнули в вектор — их можно создавать на стеке, и тогда они
V>а. быстрее
V>б. не приводят к фрагментации памяти.

в. выедают stack

V>Кроме того, С компилятор не делает манглинга — что очень важно, если пишешь бинарную библиотеку.

extern "C"

V>И наконец, сообщения об ошибках от С компилятора, как правило, в разы более вменяемые.

не сравнивал. недавно открыл для себя clang — улётная штука

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

+1

V>>В С99 есть киллер фича — динамические массивы.
V>>а. быстрее
V>>б. не приводят к фрагментации памяти.
P>в. выедают stack
Это не обязательно проблема — например, если такой массив используется в многократно вызываемой фунцкции. Стек все равно освобождается в ее конце.
Кстати, есть еще один пункт, про который я забыл — их можно использовать в обработчиках сигналов.


V>>Кроме того, С компилятор не делает манглинга — что очень важно, если пишешь бинарную библиотеку.
P>extern "C"
Не помогает . Полностью манглинг это не убирает. Не пробовал что ли, никогда? Чтобы не было манглинга, надо колдовать с опциями компилятора (gcc) или сочинять .def файл (виндоус).


V>>И наконец, сообщения об ошибках от С компилятора, как правило, в разы более вменяемые.
P>не сравнивал. недавно открыл для себя clang — улётная штука
Clang, говорят, крутой. Но в продакшн я не слышал, чтобы кто-то его использовал. А разница в диагностике выглядит примерно так:

int foo(int k) { return k; }

int main() {
    double* p;
    foo(); // missing parameter
    p(); //calling something which is not a function
    foo(p); // improper usage
    char (*f)(int) = foo; // function mismatch

}

С++:

"test_error.cpp", line 5: Error: Too few arguments in call to "foo(int)".
"test_error.cpp", line 6: Error: Only a function may be called.
"test_error.cpp", line 7: Error: Formal argument k of type int in call to foo(int) is being passed double*.
"test_error.cpp", line 8: Error: Cannot use int(*)(int) to initialize char(*)(int).

С:

"test_error.c", line 5: prototype mismatch: 0 args passed, 1 expected
"test_error.c", line 6: function designator is not of function type
"test_error.c", line 7: warning: improper pointer/integer combination: arg #1
"test_error1.c", line 8: warning: assignment type mismatch:
pointer to function(int) returning char "=" pointer to function(int) returning int

Сравниваем:
Строка 5 — сишный компилятор четко говорит, сколько должно быть аргументов, и сколько передано. Плюсовый — просто ругается. Когда аргумент один, это не важно. А вот если их 10...
Строка 6. Плюсовый просто врет — не только функцию можно вызывать! Сишный четко говорит. Но вобщем-то, здесь ничья.
Строка 7. Компилятор подсказывает, какой именно аргумент не такой в твоем вызове, а не заставляет тебя лезть в объявление функции, чтобы смотреть, что там k. Особенно увлекательно при использовании всяких смешных имен с подчеркиваниями.
Строка 8. Ну тут и комментировать нечего.

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


V>>>В С99 есть киллер фича — динамические массивы.
V>>>а. быстрее
V>>>б. не приводят к фрагментации памяти.
P>>в. выедают stack
V>Это не обязательно проблема — например, если такой массив используется в многократно вызываемой фунцкции. Стек все равно освобождается в ее конце.

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

V>>>Кроме того, С компилятор не делает манглинга — что очень важно, если пишешь бинарную библиотеку.
P>>extern "C"
V>Не помогает . Полностью манглинг это не убирает. Не пробовал что ли, никогда? Чтобы не было манглинга, надо колдовать с опциями компилятора (gcc) или сочинять .def файл (виндоус).

естественно, что полностью не уберёт, так как в С++ есть перегрузка функций(для каждой должно быть своё имя) и т.п.
но ничто не мешает для С++ библиотеки, делать полностью clean-C интерфейс.

V>>>И наконец, сообщения об ошибках от С компилятора, как правило, в разы более вменяемые.
P>>не сравнивал. недавно открыл для себя clang — улётная штука
V>Clang, говорят, крутой. Но в продакшн я не слышал, чтобы кто-то его использовал.

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

V>А разница в диагностике выглядит примерно так:

а что за компиляторы?

вот вывод clang (в консоли, он ещё раскрашивает сообщения)

C:

errt.c:5:9: error: too few arguments to function call, expected 1, have 0
foo(); // missing parameter
~~~ ^
errt.c:1:1: note: 'foo' declared here
int foo(int k) { return k; }
^
errt.c:6:6: error: called object type 'double *' is not a function or function pointer
p(); //calling something which is not a function
~^
errt.c:7:9: warning: incompatible pointer to integer conversion passing 'double *' to parameter of type 'int' [-Wint-conversion]
foo(p); // improper usage
^
errt.c:1:13: note: passing argument to parameter 'k' here
int foo(int k) { return k; }
^
errt.c:8:12: warning: incompatible pointer types initializing 'char (*)(int)' with an expression of type 'int (int)' [-Wincompatible-pointer-types]
char (*f)(int) = foo; // function mismatch
^ ~~~
2 warnings and 2 errors generated.

C++

errt.cpp:5:5: error: no matching function for call to 'foo'
foo(); // missing parameter
^~~
errt.cpp:1:5: note: candidate function not viable: requires 1 argument, but 0 were provided
int foo(int k) { return k; }
^
errt.cpp:6:6: error: called object type 'double *' is not a function or function pointer
p(); //calling something which is not a function
~^
errt.cpp:7:5: error: no matching function for call to 'foo'
foo(p); // improper usage
^~~
errt.cpp:1:5: note: candidate function not viable: no known conversion from 'double *' to 'int' for 1st argument; dereference the argument with *
int foo(int k) { return k; }
^
errt.cpp:8:12: error: cannot initialize a variable of type 'char (*)(int)' with an lvalue of type 'int (int)': different return type ('char' vs 'int')
char (*f)(int) = foo; // function mismatch
^ ~~~
4 errors generated.

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

P>Здравствуйте, org_256, Вы писали:
_>>1. Большую часть времени я пишу для платформы с большим ограничением по пространству-времени. ( робототехника )
P>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.
Вы можите аргументировать, почему С++ позволяет писать более оптимальные программы? Равные — безусловно. При равном объеме кода — тоже. Но в общем случае "более", звучит довольно странно.

_>>7. Если бы все мои задачи требовали быстрого решения и реализации и не были бы требовательны к скорости выполнения и размерам кода, то да, я бы стал использовать С++ постоянно, даже не смотря на то, что этот язык просто чисто физически не возможно выучить на все 100%.
P>даже выучив 50% C++, вы сможете делать более быстрые программы чем на C, либо более компактные чем на C (вообще одновременно максимальная компактность и максимальная скорость почти никогда не достигаются одновременно, в том числе и на C)
Вопрос к пункту один.

_>>8. Аргументы вроде: на современных машинах вызов через один указатель или через указатель на на таблицу указателей не имеет значения, потому что скорость на современных машинах ничтожна мала и не ощутима даже в супер-пупер-тестах... — для меня не аргумент...
P>При чём тут вызов через указатель?
P>Там где необходимо сделать runtime decision в C++, его также необходимо сделать и в C.
P>Compile-time decision конечно быстрее чем runtime decision, но никто вас не заставляет делать runtime decision, где возможно compile-time. И кстати, C++ предоставляет намного более богатые возможности для реализации compile-time decision.
P>Ярким примером является сравнение std::sort (C++ style) vs qsort (C-style) — как вы думаете, что быстрее?
P>В std::sort как раз compile-time decision, а в qsort — runtime decision.
P>http://www2.research.att.com/~bs/new_learning.pdf
P>http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Keynote-Bjarne-Stroustrup-Cpp11-Style
Дык кто ж пользуется этой qsort? Я о ней вообще узнал только после двух лет программирования на Си)) А если сравнивать std::sort с сортировкой написанной под конкретную задачу — выигрывает последняя. За счет проигрыша в объеме кода.

_>>9. Аргументы вроде: На Си глобалы, код-лапша, легко насрать куда не нужно, что провоцирует трудновылавливаемые баги — тоже не аргументы. Баги есть даже в релизном коде многих успешных продуктов.
P>какие-то детские рассуждения.
P>То что баги есть во многих успешных проектах, ни капли не аргумент против того, что C++ позволяет писать программы с меньшим количеством багов (а значит быстрее).
P>При грамотном использовании C++ позволяет находить многие баги при компиляции, либо не делать их вовсе (по сравнению с C). Да, все делают ошибки, но при грамотном использовании C++ позволяет делать меньше багов чем C.
В целом согласен, но грамотное использование чистого Си тоже позволяет обходиться без ошибок (но по сравнению С++ будет больше кода).

_>>12. Вся RMOS ( моя система для экспериментальных роботов-манипуляторов ) написана на С99. Далее LCC->AT89C51. ( лицензия есть ).
P>Как я писал ранее — отсутствие компилятора действительно может затруднять использование С++, но как я уже писал есть компиляторы транслирующие код C++ в код C.
Иногда транслируют так, что как раз отсутствие компилятора С++ это аргумент его не использовать)) Ну во всяком случае так раньше было, может сейчас уже проще.

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

_>>>1. Большую часть времени я пишу для платформы с большим ограничением по пространству-времени. ( робототехника )
P>>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.
1>Вы можите аргументировать, почему С++ позволяет писать более оптимальные программы? Равные — безусловно. При равном объеме кода — тоже. Но в общем случае "более", звучит довольно странно.

http://www.rsdn.ru/forum/cpp/4731645.1.aspx

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

пример qsort vs sort.
В qsort — runtime decision, в sort — compile-time, отсюда и скорость. И это не единственный пример.

_>>>7. Если бы все мои задачи требовали быстрого решения и реализации и не были бы требовательны к скорости выполнения и размерам кода, то да, я бы стал использовать С++ постоянно, даже не смотря на то, что этот язык просто чисто физически не возможно выучить на все 100%.
P>>даже выучив 50% C++, вы сможете делать более быстрые программы чем на C, либо более компактные чем на C (вообще одновременно максимальная компактность и максимальная скорость почти никогда не достигаются одновременно, в том числе и на C)
1>Вопрос к пункту один.

ну так я не говорил что всегда одновременно получается достигнуть и скорость и компактность. либо то, либо другое, причём на C++ обе цели (по отдельности) достигаются легче чем на C.

_>>>8. Аргументы вроде: на современных машинах вызов через один указатель или через указатель на на таблицу указателей не имеет значения, потому что скорость на современных машинах ничтожна мала и не ощутима даже в супер-пупер-тестах... — для меня не аргумент...
P>>При чём тут вызов через указатель?
P>>Там где необходимо сделать runtime decision в C++, его также необходимо сделать и в C.
P>>Compile-time decision конечно быстрее чем runtime decision, но никто вас не заставляет делать runtime decision, где возможно compile-time. И кстати, C++ предоставляет намного более богатые возможности для реализации compile-time decision.
P>>Ярким примером является сравнение std::sort (C++ style) vs qsort (C-style) — как вы думаете, что быстрее?
P>>В std::sort как раз compile-time decision, а в qsort — runtime decision.
P>>http://www2.research.att.com/~bs/new_learning.pdf
P>>http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Keynote-Bjarne-Stroustrup-Cpp11-Style
1>Дык кто ж пользуется этой qsort? Я о ней вообще узнал только после двух лет программирования на Си)) А если сравнивать std::sort с сортировкой написанной под конкретную задачу — выигрывает последняя. За счет проигрыша в объеме кода.

Вы понимаете почему std::sort быстрее? Посмотрите на ссылки которые я дал — там sort в несколько раз быстрее.

_>>>9. Аргументы вроде: На Си глобалы, код-лапша, легко насрать куда не нужно, что провоцирует трудновылавливаемые баги — тоже не аргументы. Баги есть даже в релизном коде многих успешных продуктов.
P>>какие-то детские рассуждения.
P>>То что баги есть во многих успешных проектах, ни капли не аргумент против того, что C++ позволяет писать программы с меньшим количеством багов (а значит быстрее).
P>>При грамотном использовании C++ позволяет находить многие баги при компиляции, либо не делать их вовсе (по сравнению с C). Да, все делают ошибки, но при грамотном использовании C++ позволяет делать меньше багов чем C.
1>В целом согласен, но грамотное использование чистого Си тоже позволяет обходиться без ошибок (но по сравнению С++ будет больше кода).

не согласен: во-первых больше кода — больше ошибок, во-вторых такие штуки как RAII исключают возможность целых классов ошибок — то есть если вы знаете и используете RAII, то вы чисто технически не сможете сделать целую кучу ошибок.

_>>>12. Вся RMOS ( моя система для экспериментальных роботов-манипуляторов ) написана на С99. Далее LCC->AT89C51. ( лицензия есть ).
P>>Как я писал ранее — отсутствие компилятора действительно может затруднять использование С++, но как я уже писал есть компиляторы транслирующие код C++ в код C.
1>Иногда транслируют так, что как раз отсутствие компилятора С++ это аргумент его не использовать)) Ну во всяком случае так раньше было, может сейчас уже проще.

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

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

P>Здравствуйте, 11molniev, Вы писали:

_>>>>1. Большую часть времени я пишу для платформы с большим ограничением по пространству-времени. ( робототехника )
P>>>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.
1>>Вы можите аргументировать, почему С++ позволяет писать более оптимальные программы? Равные — безусловно. При равном объеме кода — тоже. Но в общем случае "более", звучит довольно странно.

P>http://www.rsdn.ru/forum/cpp/4731645.1.aspx

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

P>пример qsort vs sort.
P>В qsort — runtime decision, в sort — compile-time, отсюда и скорость. И это не единственный пример.
Я то понимаю разницу между ними, но в том то и дело, что в чистом Си обычно именно compile-time. qsort — одно из немногих исключений. Все равно что виртуальные методы.

_>>>>7. Если бы все мои задачи требовали быстрого решения и реализации и не были бы требовательны к скорости выполнения и размерам кода, то да, я бы стал использовать С++ постоянно, даже не смотря на то, что этот язык просто чисто физически не возможно выучить на все 100%.
P>>>даже выучив 50% C++, вы сможете делать более быстрые программы чем на C, либо более компактные чем на C (вообще одновременно максимальная компактность и максимальная скорость почти никогда не достигаются одновременно, в том числе и на C)
1>>Вопрос к пункту один.

P>ну так я не говорил что всегда одновременно получается достигнуть и скорость и компактность. либо то, либо другое, причём на C++ обе цели (по отдельности) достигаются легче чем на C.
ОК. Компактность — безусловно. Но скорость то на С++ достигается за счет legacy C.

_>>>>8. Аргументы вроде: на современных машинах вызов через один указатель или через указатель на на таблицу указателей не имеет значения, потому что скорость на современных машинах ничтожна мала и не ощутима даже в супер-пупер-тестах... — для меня не аргумент...
P>>>При чём тут вызов через указатель?
P>>>Там где необходимо сделать runtime decision в C++, его также необходимо сделать и в C.
P>>>Compile-time decision конечно быстрее чем runtime decision, но никто вас не заставляет делать runtime decision, где возможно compile-time. И кстати, C++ предоставляет намного более богатые возможности для реализации compile-time decision.
P>>>Ярким примером является сравнение std::sort (C++ style) vs qsort (C-style) — как вы думаете, что быстрее?
P>>>В std::sort как раз compile-time decision, а в qsort — runtime decision.
P>>>http://www2.research.att.com/~bs/new_learning.pdf
P>>>http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Keynote-Bjarne-Stroustrup-Cpp11-Style
1>>Дык кто ж пользуется этой qsort? Я о ней вообще узнал только после двух лет программирования на Си)) А если сравнивать std::sort с сортировкой написанной под конкретную задачу — выигрывает последняя. За счет проигрыша в объеме кода.

P>Вы понимаете почему std::sort быстрее? Посмотрите на ссылки которые я дал — там sort в несколько раз быстрее.
Быстрей, потому что qsort делает вызовы функции сравнения. Лишние call/ret + использование стека по сравнению с С++. Реализация qsort под массив float без callback-a будет быстрей std::sort.
И таки не в несколько раз: 1,7 для 32 и 1,4 для 64 кода.

_>>>>9. Аргументы вроде: На Си глобалы, код-лапша, легко насрать куда не нужно, что провоцирует трудновылавливаемые баги — тоже не аргументы. Баги есть даже в релизном коде многих успешных продуктов.
P>>>какие-то детские рассуждения.
P>>>То что баги есть во многих успешных проектах, ни капли не аргумент против того, что C++ позволяет писать программы с меньшим количеством багов (а значит быстрее).
P>>>При грамотном использовании C++ позволяет находить многие баги при компиляции, либо не делать их вовсе (по сравнению с C). Да, все делают ошибки, но при грамотном использовании C++ позволяет делать меньше багов чем C.
1>>В целом согласен, но грамотное использование чистого Си тоже позволяет обходиться без ошибок (но по сравнению С++ будет больше кода).

P>не согласен: во-первых больше кода — больше ошибок, во-вторых такие штуки как RAII исключают возможность целых классов ошибок — то есть если вы знаете и используете RAII, то вы чисто технически не сможете сделать целую кучу ошибок.
Это (в том числе и RAII) компенсируется в Си стандартом кодирования + выделением отдельного слоя api. Гарантия конечно не такая надежная, люди ошибаются чаще машин — но вполне себе работает. В качестве примера можно привести nginx — чистый Си, ничего не течет.

AD>>Вообще я ожидал услышать что-то типа "В случае <бла-бла-бла> был применён С++, но от него пришлось отказаться по причине <бла-бла-бла>. Код бы переписан на си, что привело к повышению <бла-бла-бла>", а получил кучу демагогии, из которой ничего не следует. Пичалька

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

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

_>И вообще, каким нужно быть идиотом, чтобы создав проект, и на опираясь С++, вдруг, резко ни с того ни с сего решить даунсемплиться в Си?

Таким как я например. Больше года пишу новые проекты только на С, и рад что принял такое решение. И да, на С, но с исключениями, автоматическим управлением ресурсами и объектной моделью. С++ для всего этого не особенно и не нужен.

Как бы для уточнения, я использую С не по тому что не знаю или не умею готовить С++, но именно по тому что неплохо умею готовить и тот и другой. Дык вот, старый добрый С оказался на практике гораздо приятнее.

P.S.

То что С++ как-то сильно влияет на обнаружение ошибок в отличии от С — миф.