C != C++

> Для стандартного C++ -- да, именно руководствуясь им я неправильно понял документацию по shared_ptr. Однако, насколько я знаю, в 0x включат shared_ptr'ы. Внимание, вопрос: останутся ли shared_ptr по прежнему потокобезопасны, а auto_ptr по прежнему потоконебезопасны?

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

IMHO поздно вносить что-то новое или менять существующее в стандарте C++. разве что явные багфиксы. скажем то, что туда идет из того-же boost уже давно есть в самом boost и все, кому это нужно, им пользуются.

> К слову, такого мелкого барахла с совместимостью в C++ накопилось уже порядком. Например, пресловутые "for( int i=0; ...". Помнится, в середине 90-х i принадлежала внешнему контексту, теперь -- внутреннему. Плохо то, что нельзя изменить поведение локально для, скажем, legacy-кода. Это означает, что при написании программы на C++ никогда не знаешь, что отвалится лет через 10, когда выйдет очередной стандарт.

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

// wbr

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

Си :-D

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

> Си :-D

я видел и участвовал в коммерчески успешных проектах, выполненных в большей своей части на C. причем объем кода существенно превышает текущий объем, скажем, ядра Linux. и ни разу не видел разработчиков, которые бы сегодня с уверенностью могли сказать "да, в свое время мы поступили правильно выбрав C". ни-ра-зу. period.

// wbr

> ни-ра-зу. period.

Вы видели unix? Коммерчески успешный проект, сформировавший современную вычислительную реальность :) Написан на Си большей своей частью

>Покажи мне хоть одну конструкцию Си, не работающую в Ди, кроме препроцессора

// 1 x * y; // Объявление или умножение?

// 2 (x)-y; // Приведение или вычитание?

Обеих конструкций нет в D.

> Вы видели unix? Коммерчески успешный проект, сформировавший современную вычислительную реальность :) Написан на Си большей своей частью

чтобы ответить на этот вопрос, я бы хотел уточнить: что именно вы понимаете под UNIX?

// wbr

>(x)-y; // Приведение или вычитание?

Ага, т.е. по твоему в случае (double)-y компилятор задумается, вычесть из double переменную, или нет?? А (var1)-y наверное приведет переменную y к типу переменной var1? Че за бред?

>x * y; // Объявление или умножение?

Аналогичное мнение.

Если не секрет, то что в Ди вместо этого?

> чтобы ответить на этот вопрос, я бы хотел уточнить: что именно вы понимаете под UNIX?

Непосредственно ОС: её ядро и минимальный набор юзерспейс утилит.

А var1 в D разве не может быть typedef'ом?

>> чтобы ответить на этот вопрос, я бы хотел уточнить: что именно вы понимаете под UNIX?

> Непосредственно ОС: её ядро и минимальный набор юзерспейс утилит.

какую именно OS? кто вендор? текущая версия? ссылка? etc.

// wbr

Всё понятно. Принесите песочку.

> Всё понятно. Принесите песочку.

конкретики я так понял не будет? np, я это ожидал.

// wbr

> Ну сравните с тем же питоном, в котором в каждой версии что-то ломают :)

?

> Поэтому туча костылей и тянется за ним ))

За питоном тоже, в 3.0 решили полмать и от них избавиться.

Чего ожидали? Что я буду уверять вас в том, что начиная с первого творения в недрах bell labs, давшее это слово (unix), и заканчивая тем же линуксом (вроде бы и не совсем unix) ядро и binutils пишется на Си? Представьте, не буду, не вижу смысла. Вы сейчас до столба докапываетесь.

> Вы видели unix? ... Написан на Си большей своей частью

Master Foo and the Ten Thousand Lines ?

> Чего ожидали?

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

> Что я буду уверять вас в том, что начиная с первого творения в недрах bell labs, давшее это слово (unix), и заканчивая тем же линуксом (вроде бы и не совсем unix) ядро и binutils пишется на Си? Представьте, не буду, не вижу смысла. Вы сейчас до столба докапываетесь.

в пояснении что "ядро Linux написано на C" действительно смысла не так много.

// wbr

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

Вы вообще адекватны? Какие финансы, какое текущее состояние?

>Че за бред?

Это не бред. Пардон, zabivator с моей подачи это запостил, так что беру ответственность за эти слова на себя, так что предъявы ко мне а не к нему :) Подробно ответить смогу после работы (ох и напостили вы тут, за вечер не разберусь). Так что кратко.

В Си контекстно-зависимая грамматика, в D — контекстно свободная. Могу привести их строгое определение, можете сами почитать в Dragon Book. Расскажу вкратце, как контекстная зависимость на практике влияет на синтаксический и семантический анализ.

А влияет она так: если грамматика к.-свободная, то разбор (парсинг ака синтаксический анализ) можно проводить *без* таблицы символов, она понадобится позже, на этапе семантического анализа. В Си это не так, и таблица символов (точнее, достаточно её самого простого аналога) должна присутствовать на этапе синт. анализа.

Была фраза, что любая конструкция Си является корректной конструкцией D. Это не так для приведения. В Си, чтобы разрулить неоднозначность типа (x)-y; нужна таблица символов (по сути, артефакт *семантического анализа*) для определения того, является ли x типом или переменной. Только так компилятор сможет определить, какой узел дерева разбора (не путать с АСТ) создавать. В D это может быть только вычитанием, таблицы символов не нужно, ибо для приведения там другой синтаксис («cast(x)(-y);»). Это сделано в том числе и для того, чтобы оставить грамматику D к.-свободной.

--Qbit

>D, напоминает кристально чистый, гладкий и понятный Си с его привычными языковыми конструкциями и принципами,

И C99 у вас лучше, чем C++, и D имеет больше общего с Си, а не C++... Это бред, вы не знаете D.

>Покажи мне хоть одну конструкцию Си, не работающую в Ди, кроме препроцессора?

Вы думали, с вас за эту фразу не спросят? Хороший понт дороже знаний? Выше zabivator уже привёл два примера, я добалю ещё один: «int* p, q;» в D объявляет два указателя, а не указатель и целочисленную переменную (как в Си). А если плотно подойти к этому делу, то можно гоораздо больше отличий найти.

>Даже после добавления в язык некоторых высокоуровнивостей, он стал с виду больше похож на Си

Офигеть.

(Себе: всё Qbit, работать, работать...)

--Qbit

>>Даже после добавления в язык некоторых высокоуровнивостей, он стал с виду больше похож на Си

>Офигеть.

Имелось ввиду, что снова появились прозрачность и ненагруженность кода аля Си, вместо спагетти С++.

>>Покажи мне хоть одну конструкцию Си, не работающую в Ди, кроме препроцессора?

>Вы думали, с вас за эту фразу не спросят? Хороший понт дороже знаний?

Я говорил "Покажи мне хоть одну конструкцию Си, не работающую в Ди, кроме препроцессора". Вы мне ее показали, очень рад) Я же не говорил, что таких нет.

>Имелось ввиду, что снова появились прозрачность и ненагруженность кода аля Си, вместо спагетти С++.

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

>Прозрачность и ненагруженность в Си за счет его убогости

вовсе он не убог, а лишь просто

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

главное выбрать относительно чего )

относительно лиспа вообще весь мир убог тогда

>ну [пока?] в стандарте C++ в принципе нет ничего, что как-то могло бы касаться распараллеливания и потоков в том числе. так что это общий подход.

ну вообще есть же уже openmp, чем не стандарт

> относительно лиспа вообще весь мир убог тогда

Мне один хаскеллевод как-то чуть горло не перегрыз за такие слова ;)

>вовсе он не убог, а лишь прост

Окей, правильный термин - "примитивен".

Иногда примитивности достаточно, иногда нет. Зависит от задачи.

>Иногда примитивности достаточно, иногда нет. Зависит от задачи.

конечно

ведь молоток вовсе не уёбищный инструмент, просто он предназначен для забивания гвоздей, но много народу поломали себе пальцы и теперь пишут на Java ... бугага =)))))))

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

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

Такого сорта аналогии эксперсивны, но совершенно не конструктивны, к сожалению. Мне лично, и я подозреваю не только мне, очень сложно проконтролировать, на каком именно шаге при проведении аналогии допущена логическая, семантическая или оценочная ошибка.

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

Спасибо.

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

Особенно такие сравнения замечательны, если вспомнить про декларативную совместимость С++ с кодом С. Если уж и сравнивать, то с языком не из этого подмножества. Например, C++ vs Objective-C (т.к. ООП в нём реализуется другими методами), Object Pascal, тот же упомянутый D, etc.

Это я про Яву писал. Смотри пост, на который я отвечал.