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

Pzz>>Это плохая оптимизация — у нее слишком много тонких эффектов. Если что-то не может быть сделано прозрачно (а дешевая передача объектов в языке типа Си/C++ не может быть сделана прозрачно, в силу очень открытого интерфейса к реальной памяти машины), то лучше не делать этого вовсе.
C>Можешь явно написать чем она плохая?

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

Потом, constantness в C++ — понятие вообще довольно "плюшевое". В силу того, что C++ унаследовал от Си понятие о значении объекта, как о содержимом тех байтов памяти, из который состоит объект.

К примеру, взять такой объект:

struct str
{
    char *s;
};

В буквальном C++'ном понимании его константность заключается в том, что я не смогу поменать указатель s. Но мне ничего не помешает пописать в память, на которую ссылается этот указатель. Изменится при этом значение объекта или нет? Формально — нет, ведь объект лишь содержит указатель, а он не поменялся. Однако если я в силу своего высокоуровнего абстрактного понимания считаю значением объекта именно содержание строки, на которую он ссылается, значение очевидно поменялось. При этом у меня нет синтаксического способа объяснить компилятору эту тонкую семантическую грань — разве что в комментарии написать, и надеяться, что кто-то (не компилятор!) его прочтет.

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

Pzz>В буквальном C++'ном понимании его константность заключается в том, что я не смогу поменать указатель s. Но мне ничего не помешает пописать в память, на которую ссылается этот указатель. Изменится при этом значение объекта или нет? Формально — нет, ведь объект лишь содержит указатель, а он не поменялся. Однако если я в силу своего высокоуровнего абстрактного понимания считаю значением объекта именно содержание строки, на которую он ссылается, значение очевидно поменялось. При этом у меня нет синтаксического способа объяснить компилятору эту тонкую семантическую грань — разве что в комментарии написать, и надеяться, что кто-то (не компилятор!) его прочтет.

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

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

Pzz>Правило неиспользования STL, очевидно, не сработает вообще — если STL нельзя использовать, найдется умник, который напишет библиотеку с эквиавалентной функциональностью (только сильно недоделанную, поскольку писаться будет под конкретные нужды). А если начать запрещать использование отдельных фич C++, то в конечном итого от C++ ничего не останется. И проконтроллировать такой запрет, кстати, будет нелегко.

Тут я не понял "за" или "против" этот аргумент и "за или против" чего. Тут вот совсем недавно и совсем рядом девушка хотела аналог std::string, но чтобы работал на ANSI C. В результате имеет "те же яйца, только сбоку" (к)

S>>"infinite amounts of pain when they don't work" — ну это при использовании чужих библиотек завсегда бывает. Что характерно, если что-то don't work в своей библиотеке — amounts of pain из-за этого гораздо меньше (правда, работы больше). Но это, на мой взгляд, language-neutral feature. Лично меня приколы OpenSSL достали видимо ничуть не меньше, чем Линуса STL. Вот уж где

Pzz>C++ гораздо менее прозрачен, чем Си. Даже в C++ без темплейтов столько всего происходит неявно и автоматически, что глазками уже не проследишь. C++ с темплейтами делает вещи еще "интереснее".

Это да. На ANSI C такие вещи обычно упрятаны в старинную самописную библиотеку и "вытягиваются на свет божий" только в случае чего-то "крайне ахового". Только не надо говорить, якобы кто-нибудь пишет что-нибудь серьезное сегодня без использования какой-либо заранее созданной инфраструктуры — читай, framework-а. Просто на C++ он стандартный и реализован компилятором и рантаймом, а на Си — своими же или чужими ручками. Кстати, потому Си получается переносимее: "самописный рантайм" можно всегда либо пересобрать на практически любой платформе, либо еще и "доточить" по мере необходимости. Ну и, опять-таки, "сишный" "рантайм" может быть любого "веса" и "аппетита к ресурсам" по мере необходимости.

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

Pzz>Просто, слишком много фич. Чрезмерная сложность не является хорошим качеством инструмента. Hint: любители работают пассатижами и разводными ключами (т.е., универсальным инструментом). Профессионал пользуется большой коллекцией дорогущих специализированных ключей, каждый для своей гайки.

Тогда вам прямая дорога в .NET C# etc.: вот где настоящее раздолье для "большой коллекцией дорогущих специализированных ключей, каждый для своей гайки"! (к)

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

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

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

Pzz>>В буквальном C++'ном понимании его константность заключается в том, что я не смогу поменать указатель s. Но мне ничего не помешает пописать в память, на которую ссылается этот указатель. Изменится при этом значение объекта или нет? Формально — нет, ведь объект лишь содержит указатель, а он не поменялся. Однако если я в силу своего высокоуровнего абстрактного понимания считаю значением объекта именно содержание строки, на которую он ссылается, значение очевидно поменялось. При этом у меня нет синтаксического способа объяснить компилятору эту тонкую семантическую грань — разве что в комментарии написать, и надеяться, что кто-то (не компилятор!) его прочтет.

E>Могли бы вы назвать такой язык (из широкораспространненных, с достаточным количеством инструментария, библиотек и документации) в котором вы могли бы сделать компилятору такие указания?

А Ява и C#, они не?

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

Pzz>>>При этом если я в Си передаю чего-нибудь по значению, это видно сразу в точке вызова. А в C++ надо посмотреть еще на прототип функции, чтобы узнать, не берет ли она от объекта ссылку вместо значения.

TL>>Непонятно в чем разница.

Pzz>Разница в том, что вызываемая процедура получает не значение объекта, а его адрес. Это как платить не деньгами, а пластиковой картой — вы не просто отдаете продавцу 10 баксов, Вы авторизуете его покопаться в Вашем банковском счете. Как только Вам попадется нечестный (или просто неаккуратный) продавец, Вы сразу поймете, что это не одно и то же.

Угу. У вас прямая аналогия и прямое заблуждение, выведенное из этой аналогии.
Получается что когда вы передаете объект по значению — вы передаете продавцу весь свой счет — точнее, конечно, если прямо без оптимизации — его копию. хех! или же копию 10 баксов.

Вообще-то при расчете банковской картой максимум, к чему получает доступ продавец — это к "транзакции на 10 баксов" — которую, к тому же, вы до определенного момента можете еще и опротестовать...

Давайте без аналогий. Чем мешает передача по ссылке, а не по значению. При условии, что Си++ позволяет явно указать что ссылка — константная. Можно без него — тоже интересно. И насколько распространена практика передачи по значению более или менее сложных объектов (структур?) в Си.

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

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

Pzz>>Правило неиспользования STL, очевидно, не сработает вообще — если STL нельзя использовать, найдется умник, который напишет библиотеку с эквиавалентной функциональностью (только сильно недоделанную, поскольку писаться будет под конкретные нужды). А если начать запрещать использование отдельных фич C++, то в конечном итого от C++ ничего не останется. И проконтроллировать такой запрет, кстати, будет нелегко.

TL>Тут я не понял "за" или "против" этот аргумент и "за или против" чего. Тут вот совсем недавно и совсем рядом девушка хотела аналог std::string, но чтобы работал на ANSI C. В результате имеет "те же яйца, только сбоку" (к)

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

Проблема с STL заключается не в том, что в нем реализуются автоматические растущие строки (они и до STL были, кстати) а в том, что в STL непонятно, что происходит — весь содержательный код выводится большим количеством весьма нетривиальных темплейтов.

Pzz>>C++ гораздо менее прозрачен, чем Си. Даже в C++ без темплейтов столько всего происходит неявно и автоматически, что глазками уже не проследишь. C++ с темплейтами делает вещи еще "интереснее".

TL>Это да. На ANSI C такие вещи обычно упрятаны в старинную самописную библиотеку и "вытягиваются на свет божий" только в случае чего-то "крайне ахового".

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

Pzz>>Просто, слишком много фич. Чрезмерная сложность не является хорошим качеством инструмента. Hint: любители работают пассатижами и разводными ключами (т.е., универсальным инструментом). Профессионал пользуется большой коллекцией дорогущих специализированных ключей, каждый для своей гайки.

TL>Тогда вам прямая дорога в .NET C# etc.: вот где настоящее раздолье для "большой коллекцией дорогущих специализированных ключей, каждый для своей гайки"! (к)

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

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

TL>Лично я, например, долго "палился" на собеседованиях на привычке возможности присваивания целого указателю...

Без явного каста такое присваивание выдает предупреждение. С явным кастом можно и в C++ присвоить.

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

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

TL>Можно без него — тоже интересно. И насколько распространена практика передачи по значению более или менее сложных объектов (структур?) в Си.

Не насколько не распостранена. Но факт передачи указателя явно виден в точке вызова. Т.е., когда Вы читаете вызов функции, Вам не надо заглядывать в другой файл, чтобы понять, что на самом деле получит эта функция — значение или ссылку.

> S>"C++ leads to really really bad design choices". — усе так и есть. C не позволяет схалтурить, объем исходников на С получается больше, поэтому горячим парням приходится сначала подумать а уж потом кодить С плюсами же можно по-быстрому налабать прототипчик и потом постепенно его дотачивать.
>
> В реальности все строго наоборот. C++ (вообще, ООП) прощает все, кроме неудачного разбиения программы на классы. К сожалению, разбивать ее на классы приходится рано, когда нет достаточной ясности, как программа будет устроена. Поэтому вероятность разбить ее на классы неудачно очень велика.

Фигня. Сущности, с которыми работает программа (класса — в случае С++), в любом случае приходится выделять, хоть на бейсике пиши, хоть на жабе. Разумеется, выделять их приходится на одной и той же стадии проектирования, независимо от языка. Причем, по моему опыту, кошмар от их неудачного выбора при написании программы на С бывает гораздо жОстче — во многом благодаря более слабой типизации.

> Кроме того, кода на C++ тоже обычно получается больше, чем на Си, из-за более детального описания "правил игры" с объектами.

Это кто как пишет. Лично у меня исходного кода на C++ обычно получается меньше — благодаря RAII и шаблонам. А вот объем бинарника больше — за счет более полной обработки ошибок.

> S>"You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap" — тут логика отсутствует. Не хочешь — не используй.
>
> Если ты — руководитель проекта, то очень трудно объяснять каждому следующему программисту, почему это мы используем, а это — нет.

Ну у Линуса я гляжу вообще такой проблемы нет — piss of и усе Так чта мимо кассы.

> Проще иметь некоторые универсальные правила, которым все должны следовать. Причем сами по себе правила должны быть простыми, иначе их никто не удосужится дочитать до конца. И следовать, соответственно, не будет.

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

> Правило неиспользования STL, очевидно, не сработает вообще — если STL нельзя использовать, найдется умник, который напишет библиотеку с эквиавалентной функциональностью (только сильно недоделанную, поскольку писаться будет под конкретные нужды).

Что характерно, при использовании С такую библиотеку по любому придется писать

> А если начать запрещать использование отдельных фич C++, то в конечном итого от C++ ничего не останется. И проконтроллировать такой запрет, кстати, будет нелегко.

Не сложнее, чем проконтролировать следование стратегиям управления памятью

> S>"infinite amounts of pain when they don't work" — ну это при использовании чужих библиотек завсегда бывает. Что характерно, если что-то don't work в своей библиотеке — amounts of pain из-за этого гораздо меньше (правда, работы больше). Но это, на мой взгляд, language-neutral feature. Лично меня приколы OpenSSL достали видимо ничуть не меньше, чем Линуса STL. Вот уж где
>
> C++ гораздо менее прозрачен, чем Си.

Есть такой момент. Хотя иногда это достоинство, а не недостаток.

> Даже в C++ без темплейтов столько всего происходит неявно и автоматически, что глазками уже не проследишь.

Зато сколько кода надо написать, чтобы покрыть те операции, за которыми глазками уже не проследишь...

> C++ с темплейтами делает вещи еще "интереснее".

А че про исключения забыл?


> S>"inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app." Ну собственно это надо быть очень меедленным программистом (проще говоря, тупым тормозом), чтобы пару лет не замечать, что чего-то там круто тормозит.
>
> Речь, по-моему, идет не о "тормозении" кода, а о неадекватности выбранной абстракции.

Насколько я понял, речь идет о торможении (или перерасходе памяти) из-за неверно выбранной абстракции.

> С чем может быть трудно что-то сделать, если большой объем кода от этой абстракции сильно зависит.

Это — language-independent проблема.

> S>Итого — С++ развращает программиста, поскольку для него есть слишком много библиотек, а в языке слишком много фич.
>
> Просто, слишком много фич.

И все равно не хватает...

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

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

> S>"In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C." Ну это просто брехня. В C++ по крайней мере проверки типов построже и переменные непосредственно перед использованием объявлять можно. Насчет portable — я сильно удивлюсь, если GIT или тем более linux kernel вдруг скомпиляется чем-то отличным от gcc.
>
> Для того множества типов, которые доступны в обоих языках, строгость проверки их почти одинаковая.

void * q;
char *t;
q = 0;
t = q;

В плюсах не скомпиляется. Ну и вообще, на голом C даже типобезопасный аналог printf не сделать. Или вот:

int foo(int a)
{
return a * a;
}
int bar(int b)
{
return foo("s");
}

VC это спокойно компиляет — правда, выдает предупреждение.

> S>Ну а дальше он собственно Monotone ругает — не знаю, может она и правда "horrible and unmaintainable mess", но чето в этом сомневаюсь. Она, по крайней мере, почему-то Cygwin для запуска под виндой не требует — в отличие от "portable" GIT. Т.е., "horrible and unmaintainable mess" на винду портировали, а portable и mantainable — нифига.
>
> Ну то, что Git не работает на Венде — вполне сознательная позиция Линуса.

Ну так и чего тогда трепаться про портабельность? Если вся его портабельность — 1 компилятор (хотя нет, еще интел в режиме совместимости) и 1 операционка.

> C++ тут не при чем. Портировать-то его, конечно, как-то портировали, но для полноценной поддержки Венды надо бы, как минимум, разобраться с \r\n,

Это не отмаз — достаточно файлы в бинарном режиме открывать.

> с тем, что Виндовая файловая система не чувствительна к регистру

Это вообще проблемы пользователя.

> и с тем, что надо что-то делать с юниксными правами доступа (очень раздражает, когда скрипты теряют битик, разрешающий их to execute, или наоборот, все файлы этот битик приобретают)

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

> и с юниксными симлинками.

Опять же, проблема пользователя. Не поддерживает ОС симлинки — не используй их.

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

AJD>>Значит ты уже зрелый профессионал. А вот на не окрепшие умы эта книга действует разрушительно

A>А что в ней такого разрушительного?

Эйфория от ощущения, что всё можно сделать в compile-time constraints плюс неумение чисто писать/читать шаблоны. В результате получается код, который
1) не работает
2) проще переписать, чем исправить

Про расширяемость, масштабируемость и прочие best practices уже и речи не идет.

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

TL>>... Имхо, совместимость в области адресной арифметики с ANSI C, включая некоторые ограничения — тоже одна из полезных фич, позволяющих в одном коде объединять и верхние уровни абстракции, и нижние — реализации.

Pzz>Это наследие совместимости с Си. В Си такая открытость к аппаратуре была сделана вполне сознательно. В C++'е она мешает созданию нормальных высокоуровневых абстракций. В первую очередь потому, что трудно полностью скрыть тот факт, что управление памятью осталось ручным. И что любые объекты — всего лишь байты в памяти.

Pzz>Если бы язык проектировался начисто, а не рос из Си, как само растется, вполне можно было бы от source level совместимости с Си отказаться, но предусмотреть способ взаимного procedure calls между языками. Тем более, что там от этой совместимости уже сейчас мало чего осталось.

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

Pzz>>>При этом грань, отделяющая идиотский поступок от неидиотского столь тонка...
TL>>В ANSI C она еще тоньше. имхо.

Pzz>Си значительно проще и прозрачнее. Это большое достоинство.

А также недостаток: для выражения (написания, высказывания, реализации) простых вещей на "плюсах" на Си приходится "крепко материться".

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

Pzz>Потом, constantness в C++ — понятие вообще довольно "плюшевое". В силу того, что C++ унаследовал от Си понятие о значении объекта, как о содержимом тех байтов памяти, из который состоит объект.

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

То, что _можно_ посмотреть на все двоичные внутренности объекта "плюсов" вовсе не означает что так _нужно_ делать.

Pzz>К примеру, взять такой объект:
Pzz>

Pzz>struct str
Pzz>{
Pzz>    char *s;
Pzz>};
Pzz>

Pzz>В буквальном C++'ном понимании его константность заключается в том, что я не смогу поменать указатель s. Но мне ничего не помешает пописать в память, на которую ссылается этот указатель. Изменится при этом значение объекта или нет? Формально — нет, ведь объект лишь содержит указатель, а он не поменялся. Однако если я в силу своего высокоуровнего абстрактного понимания считаю значением объекта именно содержание строки, на которую он ссылается, значение очевидно поменялось. При этом у меня нет синтаксического способа объяснить компилятору эту тонкую семантическую грань — разве что в комментарии написать, и надеяться, что кто-то (не компилятор!) его прочтет.


Уел!!!

Ну ладно: как ты то же самое ограничишь в Си? А никак.
В тех же "плюсах" это может ограничить даже школьник, перебросив член в защищенную область и нарисовав публичные аксессоры.
Применить к C++ явно "сишный" подход и поставить факт в укор "плюсам" —

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Ссылки нужны на деле только для того, чтобы поддержать operator++, operator[] и прочее, где операнд или результат есть lvalue. Соответственно, ссылки вне параметров и возвращаемых значений — просто ненужная фича, и причем дурацкая, ибо неполноценно дублирует указатели. Неполноценно потому, что не бывает указателей на ссылки и массивов ссылок.


Может немного не в тему, но тем не менее. Что мне не нравится в указателях и нравится в ссылках.
Указатель может представлять из себя 4 совершенно разные вещи:
1. Указатель на объект
2. Указатель на объект или 0
3. Массив объектов
4. Массив объектов или 0
При этом нет способа различить эти вещи, не вдаваясь в код, ни программисту, ни компилятору (по крайней мере никто это не делает).

Допустим есть некая незнакомая функция f(X* x). Как со стороны вызывающего, так и со стороны разработчика функции совершенно не понятно, что перечисленных 4 пунктов можно передать в эту функцию. Единственный способ — разбираться в коде функции, как она его использует. Допустим мы разобрались. Но компилятор это разбирать не будет — допустим функция ждёт один объект, а мы передаём туда массив или 0.

Далее, т.к. указатели обычно не объявляются как константные, то указатель-параметр в середине функции может вдруг "стать другим объектом". Ясности это тоже не прибавляет.

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


Ссылка всегда представляет одну чётко определённую вещь — это объект, всегда один, и никогда не отсутствие объекта (NULL). Поэтому сразу снимаются все вопросы и для вызывающего функцию, и для разрабатывающего функцию. Плюс к этому ссылка никогда не может "стать другим объектом" посередине функции, она всегда останется "входным" параметром функции.
Лично для меня это существенно повышает понятность кода.


Возможно формально ссылка является излишней вещью в языке... так же как и struct в C

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

S>Фигня. Сущности, с которыми работает программа (класса — в случае С++), в любом случае приходится выделять, хоть на бейсике пиши, хоть на жабе. Разумеется, выделять их приходится на одной и той же стадии проектирования, независимо от языка. Причем, по моему опыту, кошмар от их неудачного выбора при написании программы на С бывает гораздо жОстче — во многом благодаря более слабой типизации.

В Си нет такой вещи, как иерархия классов. А именно ее очень болезненно переделывать.

>> Кроме того, кода на C++ тоже обычно получается больше, чем на Си, из-за более детального описания "правил игры" с объектами.

S>Это кто как пишет. Лично у меня исходного кода на C++ обычно получается меньше — благодаря RAII и шаблонам. А вот объем бинарника больше — за счет более полной обработки ошибок.

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

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

S>Ну у Линуса я гляжу вообще такой проблемы нет — piss of и усе Так чта мимо кассы.

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

S>Возьмем к примеру простое правило — кто должен освобождать память? В плюсах это решается элементарно — разумется, объект, который этой памятью владеет. Вся стратегия выделения-освобождения-смены владельца прячется внутрь объекта. "Голые указатели" просто запрещаем. В С же придется все случаи, отличные от "стратегии по умолчанию" (например — кто выделил — тот и освобождает), отдельно документировать и, что самое поганое, периодически налетать на ситуацию когда кто-то из разработчиков оказался недостаточно внимателен. И, кроме управления памятью, таких примеров можно придумать массу.

Глупость какая-то. В простых случаях ничего не стоит договориться о простых принципах управления памятью, и всем их соблюдать. Их можно даже поенфорсить, как это делает внутри себя Apache — например, аллоцировать память со ссылкой на родительский объект, и обеспечить автоматическое удаление всей памяти, которой владеют дочерние объекты, при удалении родительского. Реализовать такую штуку не сильно сложнее, чем реализовать "вумственный" (smart) указатель.

В сложных случаях (например, если Вы пишете систему управления памятью ядра операционной системы) такой простой подход все равно не сработает — на то они и сложные случаи. К счастию, эту сложность обычно удается локализовать.

Потом, не забывайте, что кроме памяти есть и другие действия, которые надо совершать парно. Например, открывать/закрывать файлы, работать с объектами синхронизации и т.п.

>> Правило неиспользования STL, очевидно, не сработает вообще — если STL нельзя использовать, найдется умник, который напишет библиотеку с эквиавалентной функциональностью (только сильно недоделанную, поскольку писаться будет под конкретные нужды).

S>Что характерно, при использовании С такую библиотеку по любому придется писать

Мы ведь говорили о ядре линуха, нет? В случае ядра, такую библиотеку придется писать в любом случае — STL, работающей в ядре, в природе не существует.

>> А если начать запрещать использование отдельных фич C++, то в конечном итого от C++ ничего не останется. И проконтроллировать такой запрет, кстати, будет нелегко.

S>Не сложнее, чем проконтролировать следование стратегиям управления памятью

Сложнее, потому что гораздо проще объяснить, что с памятью надо обращаться таким-то образом ("иначе работать не будет"), чем то, почему простые способы использования темплейтов разрешены, а использование темплейтов в стиле пресловутого Александреску — нет.

>> C++ гораздо менее прозрачен, чем Си.

S>Есть такой момент. Хотя иногда это достоинство, а не недостаток.

Это всегда недостаток. Не надо путать непрозрачность с высокоуровневостью. Когда я в каком-нибудь, прости господи, Перле использую строки, мне глубоко наплевать, как они там собраны из отдельных байтов — они все равно ведут себя как строки. В C++ же их, строк, внутренний мир полностью скрыть невозможно — все равно что-нибудь да вылезет.

>> Даже в C++ без темплейтов столько всего происходит неявно и автоматически, что глазками уже не проследишь.

S>Зато сколько кода надо написать, чтобы покрыть те операции, за которыми глазками уже не проследишь...

C++ очень этому помогает

>> C++ с темплейтами делает вещи еще "интереснее".

S>А че про исключения забыл?

Память дырявая

>> Речь, по-моему, идет не о "тормозении" кода, а о неадекватности выбранной абстракции.

S>Насколько я понял, речь идет о торможении (или перерасходе памяти) из-за неверно выбранной абстракции.

Я плохо помню, что писал Линус (и лень перечитывать). Но мое мнение, ментальные проблемы, связанные с неверным выбором абстракции, гораздо разрушительнее, чем любые проблемы с памятью и скоростью исполнения программы.

>> С чем может быть трудно что-то сделать, если большой объем кода от этой абстракции сильно зависит.

S>Это — language-independent проблема.

И да и нет. Эта проблема разрастается как снежный ком, если собирать абстракции в сложные иерархии. C++ очень способствует построению сложных иерархий, часто без нужды. При этом перетрясти уже имеющуюся иерархию очень сложно.

>> Просто, слишком много фич.

S>И все равно не хватает...

Да, примерно как с кокаином

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

S>Плохая аналогия. Если оставаться в рамках одного языка, то в С++ специализированных ключей больше, в то время как С — одни большие плоскогубцы.

Один язык — один инструмент.

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

S>

S>void * q;
S>char *t;
S>q = 0;
S>t = q;
S>

S>В плюсах не скомпиляется. Ну и вообще, на голом C даже типобезопасный аналог printf не сделать. Или вот:

Написав слово void, Вы попросили компилятор не лезть Вам в душу. Что компилятор и сделал. Вполне честные отношения. Случайно слово void не напишешь.

Типобезопасный аналог printf и в C++ не сделаешь. Форматный вывод в поток — не аналог printf.

S>

S>int foo(int a)
S>{
S>return a * a;
S>}
S>int bar(int b)
S>{
S>return foo("s");
S>}
S>

S>VC это спокойно компиляет — правда, выдает предупреждение.

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

S>Ну так и чего тогда трепаться про портабельность? Если вся его портабельность — 1 компилятор (хотя нет, еще интел в режиме совместимости) и 1 операционка.

Скорее, это портабабельность трепаются апологеты C++.

>> C++ тут не при чем. Портировать-то его, конечно, как-то портировали, но для полноценной поддержки Венды надо бы, как минимум, разобраться с \r\n,

S>Это не отмаз — достаточно файлы в бинарном режиме открывать.

Нет. Система управления исходными текстами должна позволать локально держать файлы с теми разделителями строк, которые приняты на данной системе. Если 2 человека редактируют один и тот же текстовый файл, один из под виндов, другой из под униха, то содержимое файлов должно выглядеть для них одинаково, а разделители строк так, как принято на данной системе. Иначе очень неудобно.

>> с тем, что Виндовая файловая система не чувствительна к регистру

S>Это вообще проблемы пользователя.

Если делать продукт, а не поделку, это не проблема пользователя.

>> и с тем, что надо что-то делать с юниксными правами доступа (очень раздражает, когда скрипты теряют битик, разрешающий их to execute, или наоборот, все файлы этот битик приобретают)

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

Его еще как-то хранить надо локально. Например, явно в метаинформации, которая связана с файлом в рабочей копии.

>> и с юниксными симлинками.

S>Опять же, проблема пользователя. Не поддерживает ОС симлинки — не используй их.

Если кто-то положил в репозиторий симлинк, как он должен выглядеть с точки зрения пользователя, который общается с системой контроля версий через виндовс?

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

Pzz>Этот аргумент утверждает следующее: если Вы не хотите, чтобы в Вашем проекте появился STL, не используйте язык, на котором STL можно написать. Ничего другого не сработает.

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

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

TL>>Это да. На ANSI C такие вещи обычно упрятаны в старинную самописную библиотеку и "вытягиваются на свет божий" только в случае чего-то "крайне ахового".

Pzz>Я не про это. Я про то, что в случае Си гораздо проще проследить код до того, что там происходит на самом деле. В C++ сделано очень многое, чтобы усложнить такой анализ.

Угу. Вообще-то это не так — это раз. А если это так, то, имхо, вы "копаетесь в песке и рассматриваете цветные камешки", вместо того чтобы "строить шоссе на 8 полос". Может у вас такая специфика, но подавляющему большинству реальных проектов это просто не нужно.

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

TL>>Тогда вам прямая дорога в .NET C# etc.: вот где настоящее раздолье для "большой коллекцией дорогущих специализированных ключей, каждый для своей гайки"! (к)

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

Странные у вас аналогии. Имхо, они неправильные — но я готов согласиться что я их просто не понимаю.

Pzz>>>Для того множества типов, которые доступны в обоих языках, строгость проверки их почти одинаковая.
TL>>Лично я, например, долго "палился" на собеседованиях на привычке возможности присваивания целого указателю...

Pzz>Без явного каста такое присваивание выдает предупреждение. С явным кастом можно и в C++ присвоить.

Только что проверил: например VC++ 7.1 выдает "error C2440: 'initializing' : cannot convert from 'int' to 'int *'" на следующую строку:

int i = 0;
int* pi = 0;
int* pi2 = i; // ошибка в этой строке

Могу проверить на gcc и на hpux cc еще.

Да, с явным кастом работает — я знаю. Но это надо _явно_ сказать "хочу привести к указателю". Тогда reinterpret_cast вообще всю систему типов порушит к ...

Pzz>А на собеседования, на которых задают идиотские вопросы про редко используемые фичи языка ходить не надо — целее будете.

Знать бы заранее куда упадешь...

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

Pzz>>Потом, constantness в C++ — понятие вообще довольно "плюшевое". В силу того, что C++ унаследовал от Си понятие о значении объекта, как о содержимом тех байтов памяти, из который состоит объект.

TL>Прямо скажем, это просто порочная практика "любителей копаться там, где никому больше не нужно": почему-то любимый вопрос на собеседовании "как по-вашему представлен экзепляр класса бинарно?" — на практике полезности не вызывает.

Я пытаюсь сказать несколько более глубокую вещь. Не то, что в C++ можно добраться до бинарной сущности объекта — ну можно и можно, и хрен бы с ним. А то, что в C++ нельзя спрятать эту бинарную сущность так, чтобы она никогда не вылезла при добросовестном использовании.

Проблема в том, что в C++ управление памятью — ручное. Как его не оборачивай в темплейтные обертки, компилятор все равно не в курсе, что происходит с памятью. А без этого, видимо, высокоуровневый язык не построишь.

TL>Ну ладно: как ты то же самое ограничишь в Си? А никак.
TL>В тех же "плюсах" это может ограничить даже школьник, перебросив член в защищенную область и нарисовав публичные аксессоры.
TL>Применить к C++ явно "сишный" подход и поставить факт в укор "плюсам" —

На C++, на самом деле, тоже толком никак. Например потому, что конструктор не знает, конструирует ли он константный или mutable объект. Си хоть не обещает невозможного. Честность — большое достоинство.

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

Pzz>>Этот аргумент утверждает следующее: если Вы не хотите, чтобы в Вашем проекте появился STL, не используйте язык, на котором STL можно написать. Ничего другого не сработает.

TL>Да? Извините, но вы в каком-то странном окружении работает. Если в проекте есть правило "мы не используем stl" — то, конечно, должно быть хоть

Это Вы в каком-то странном окружении работаете

Мне приходится работать с такими людьми, которые есть. Которые, например, способны найти внутри исходника понравившуюся им static функцию, убрать слово static, вынести функцию наружу и начать применять. Забыв спросить меня, согласен ли я впредь поддерживать работоспособность этой функции.

В результате, когда я ее таки ломаю (а я не обещал ее не ломать — на то она и static), в говне оказываюсь я. Как же, у них все работало, пока не пришел злобный я, и все не сломал (т.е., не внес "багу" в "работающий" код).

Hint: такие люди называются продвинытые индусы (видимо благодаря им такой стиль разработки называется индустриальным. Их менее продвинутые собратья умудряются добиться подобного же эффекта, используя только public интерфейс — путем возложения неоправданных надежд на особенности поведения реализации интерфейса в данной конкретной версии. Эти, на самом деле, еще хуже — поскольку они не гадят в мой код, заметить их вредоносность можно, только время от времени просматривая их код. Что вредно для кармы.

Pzz>>Я не про это. Я про то, что в случае Си гораздо проще проследить код до того, что там происходит на самом деле. В C++ сделано очень многое, чтобы усложнить такой анализ.

TL>Угу. Вообще-то это не так — это раз. А если это так, то, имхо, вы "копаетесь в песке и рассматриваете цветные камешки", вместо того чтобы "строить шоссе на 8 полос". Может у вас такая специфика, но подавляющему большинству реальных проектов это просто не нужно.

Копаться в песке приходится, когда машинка не едет, по казалось бы, ровному 8-полосному шоссе. При индустриальном подходе к делу, такое случается сплошь и рядом.

TL>Кстати, низкоуровневый код — а точнее, HAL — таки и правда "ближе и проще" на "простом си". Вот только как только начинаются абстракции — как тут же самое время разделить слои и писать ниже нижнего на чем-то более подходящем, вместо того чтобы сперва реализовывать своими руками "что-то более подходящее", а потом уже "строить абстракции" на его базе. имхо.

Это, по-моему, заблуждение, путать код, который близок к железу и код, у которого простые абстракции. Сложность абстракций не зависит от близости к железу.

Собственно, что я хочу сказать, высокоуровневые вещи, конечно, лучше писать на высокоуровневом языке. Только C++ не из их числа (высокоуровневых языков).

Pzz>>Без явного каста такое присваивание выдает предупреждение. С явным кастом можно и в C++ присвоить.

TL>Только что проверил: например VC++ 7.1 выдает "error C2440: 'initializing' : cannot convert from 'int' to 'int *'" на следующую строку:

Какая разница, warning, error?

> S>Фигня. Сущности, с которыми работает программа (класса — в случае С++), в любом случае приходится выделять, хоть на бейсике пиши, хоть на жабе. Разумеется, выделять их приходится на одной и той же стадии проектирования, независимо от языка. Причем, по моему опыту, кошмар от их неудачного выбора при написании программы на С бывает гораздо жОстче — во многом благодаря более слабой типизации.
>
> В Си нет такой вещи, как иерархия классов. А именно ее очень болезненно переделывать.

Т.е., если ровно то же мы реализовали (неправильно реализовали) без классов — то переделывать менее болезненно?

>>> Кроме того, кода на C++ тоже обычно получается больше, чем на Си, из-за более детального описания "правил игры" с объектами.
>
> S>Это кто как пишет. Лично у меня исходного кода на C++ обычно получается меньше — благодаря RAII и шаблонам. А вот объем бинарника больше — за счет более полной обработки ошибок.
>
> Сравнивать стили 2-х любых отдельно взятых человек нет смысла — индивидуальные особенности могут перевесить все особенности языка. В общем и целом, C++'ные программисты гораздо более детально описывают интерфейс (а кто так не делает — тот козел ), что приводит к раздуванию кода. Именно исходного кода, я имею ввиду.

Т.е., сишные программисты — козлы без вариантов? Ибо детально интерфейс не описывают... Ну-ну.

>>> Если ты — руководитель проекта, то очень трудно объяснять каждому следующему программисту, почему это мы используем, а это — нет.
>
> S>Ну у Линуса я гляжу вообще такой проблемы нет — piss of и усе Так чта мимо кассы.
>
> Линус в течении многих лет руководит большим проектом, в который вовлечено множество людей, и делает это вполне успешно. Разумеется, в его стиле руководства есть определенные недостатки, но в общем и целом это работает.

Годится. Никому ничего не объясняем, просто говорим — кто хочет использовать STL и не понимает, почему этого делать нельзя — идет нафиг.

> S>Возьмем к примеру простое правило — кто должен освобождать память? В плюсах это решается элементарно — разумется, объект, который этой памятью владеет. Вся стратегия выделения-освобождения-смены владельца прячется внутрь объекта. "Голые указатели" просто запрещаем. В С же придется все случаи, отличные от "стратегии по умолчанию" (например — кто выделил — тот и освобождает), отдельно документировать и, что самое поганое, периодически налетать на ситуацию когда кто-то из разработчиков оказался недостаточно внимателен. И, кроме управления памятью, таких примеров можно придумать массу.
>
> Глупость какая-то. В простых случаях ничего не стоит договориться о простых принципах управления памятью, и всем их соблюдать.

Речь идет, разумеется, о сложных случаях.

> Их можно даже поенфорсить,

Как конкретно будем энфорсить?

> как это делает внутри себя Apache — например, аллоцировать память со ссылкой на родительский объект, и обеспечить автоматическое удаление всей памяти, которой владеют дочерние объекты, при удалении родительского. Реализовать такую штуку не сильно сложнее, чем реализовать "вумственный" (smart) указатель.

Это называется "закат солнца вручную".

>
> В сложных случаях (например, если Вы пишете систему управления памятью ядра операционной системы) такой простой подход все равно не сработает — на то они и сложные случаи. К счастию, эту сложность обычно удается локализовать.

У меня пока срабатывал. Впрочем, ядра ОС я пока и не писал.

> Потом, не забывайте, что кроме памяти есть и другие действия, которые надо совершать парно. Например, открывать/закрывать файлы, работать с объектами синхронизации и т.п.

Про RAII я кажется упоминал. Еще один камешек в огород С.

>>> Правило неиспользования STL, очевидно, не сработает вообще — если STL нельзя использовать, найдется умник, который напишет библиотеку с эквиавалентной функциональностью (только сильно недоделанную, поскольку писаться будет под конкретные нужды).
>
> S>Что характерно, при использовании С такую библиотеку по любому придется писать
>
> Мы ведь говорили о ядре линуха, нет?

Не только.

> В случае ядра, такую библиотеку придется писать в любом случае — STL, работающей в ядре, в природе не существует.

Это верно ровно до тех пор, пока мы не начали писать ядро на С++ Собственно, не вижу причин, по которым std::sort не будет работать в ядре.

>>> А если начать запрещать использование отдельных фич C++, то в конечном итого от C++ ничего не останется. И проконтроллировать такой запрет, кстати, будет нелегко.
>
> S>Не сложнее, чем проконтролировать следование стратегиям управления памятью
>
> Сложнее, потому что гораздо проще объяснить, что с памятью надо обращаться таким-то образом ("иначе работать не будет"), чем то, почему простые способы использования темплейтов разрешены, а использование темплейтов в стиле пресловутого Александреску — нет.

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


>>> C++ гораздо менее прозрачен, чем Си.
>
> S>Есть такой момент. Хотя иногда это достоинство, а не недостаток.
>
> Это всегда недостаток. Не надо путать непрозрачность с высокоуровневостью.

Вот и не путай. Когда у меня в результате выбрасывания исключения "сами собой", благодаря деструкторам уничтожаются десяток другой временных объектов — это не только непрозрачность, но и высокоуровневость — потому что мне не пришлось ручками прописать тучу проверок возвращаемых значений и гору goto cleanup;

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

В чем конкретно заключаются ваши претензии к строкам? Они не ведут себя как строки? В С они ведут себя лучше?

>>> Речь, по-моему, идет не о "тормозении" кода, а о неадекватности выбранной абстракции.
>
> S>Насколько я понял, речь идет о торможении (или перерасходе памяти) из-за неверно выбранной абстракции.
>
> Я плохо помню, что писал Линус (и лень перечитывать). Но мое мнение, ментальные проблемы, связанные с неверным выбором абстракции, гораздо разрушительнее, чем любые проблемы с памятью и скоростью исполнения программы.

ментальные проблемы, связанные с неверным выбором абстракции, как я уже говорил, language-independent. Иначе это не абстракции.

>>> С чем может быть трудно что-то сделать, если большой объем кода от этой абстракции сильно зависит.
>
> S>Это — language-independent проблема.
>
> И да и нет. Эта проблема разрастается как снежный ком, если собирать абстракции в сложные иерархии. C++ очень способствует построению сложных иерархий, часто без нужды.

А С способствует низкоуровнему лазанью в структуры данных. Что на возможность рефакторинга влияет еще более губительно.

> При этом перетрясти уже имеющуюся иерархию очень сложно.

Поменять что-либо в написанной плохим С-программистом программе еще сложнее

>>> Чрезмерная сложность не является хорошим качеством инструмента. Hint: любители работают пассатижами и разводными ключами (т.е., универсальным инструментом). Профессионал пользуется большой коллекцией дорогущих специализированных ключей, каждый для своей гайки.
>
> S>Плохая аналогия. Если оставаться в рамках одного языка, то в С++ специализированных ключей больше, в то время как С — одни большие плоскогубцы.
>
> Один язык — один инструмент.

Вот-вот, плохая аналогия. Одним инструментом в любом случае много не наработаешь.


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

> S>void * q;
> S>char *t;
> S>q = 0;
> S>t = q;
> S>

>
> S>В плюсах не скомпиляется. Ну и вообще, на голом C даже типобезопасный аналог printf не сделать. Или вот:
>
> Написав слово void, Вы попросили компилятор не лезть Вам в душу. Что компилятор и сделал. Вполне честные отношения. Случайно слово void не напишешь.

Отсюда вывод — С способствует написанию программ, обходящих систему типов.

>
> Типобезопасный аналог printf и в C++ не сделаешь. Форматный вывод в поток — не аналог printf.

boost::format. Не идеал, но для вывода сообщений об ошибках — то, что надо.

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

В реальной жизни зачастую ни то, ни другое невозможно.

> S>Ну так и чего тогда трепаться про портабельность? Если вся его портабельность — 1 компилятор (хотя нет, еще интел в режиме совместимости) и 1 операционка.
>
> Скорее, это портабабельность трепаются апологеты C++.

"and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny"
"In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C."

>>> C++ тут не при чем. Портировать-то его, конечно, как-то портировали, но для полноценной поддержки Венды надо бы, как минимум, разобраться с \r\n,
>
> S>Это не отмаз — достаточно файлы в бинарном режиме открывать.
>
> Нет. Система управления исходными текстами должна позволать локально держать файлы с теми разделителями строк, которые приняты на данной системе.

И при этом не должна самовольно редактировать и форматировать мои исходники. Для этого более другие программы есть.

> Если 2 человека редактируют один и тот же текстовый файл, один из под виндов, другой из под униха,

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

> то содержимое файлов должно выглядеть для них одинаково, а разделители строк так, как принято на данной системе. Иначе очень неудобно.

Ну вот у меня буст локально лежит — там концы строк lf. И наши исходники — там как правило cr lf. Разница невооруженным глазом не видна и мне это нисколько не мешает. Что я делаю не так?

>>> с тем, что Виндовая файловая система не чувствительна к регистру
>
> S>Это вообще проблемы пользователя.
>
> Если делать продукт, а не поделку, это не проблема пользователя.

rar у нас значит поделка, не продукт... SVN тоже...

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

Ну и в чем проблема? Все равно кучу всякого трэша, связанного с файлом хранить надо — почему бы еще пару байт туда не добавить

>>> и с юниксными симлинками.
>
> S>Опять же, проблема пользователя. Не поддерживает ОС симлинки — не используй их.
>
> Если кто-то положил в репозиторий симлинк, как он должен выглядеть с точки зрения пользователя, который общается с системой контроля версий через виндовс?

Под вистой — как симлинк. Под более ранними — как ошибка.

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

TL>Ключевой момент был неоднократно упомянут и указан явно тоже: практик в _чем_ именно?
В программировании довольно сложных систем. А Александреску практик в написании книжек...

AJD>А зачем его туда тянуть если ядру уже 100 лет в обед и оно и так работает. Когда ядро начали разрабатывать разве были нормальные компиляторы с++?

Ходят сплетни, что 2мерную графику в НТ строили cfrontом ftdisk и portcls — это намного позже уже, второй особенно.

TL>Тут я не понял "за" или "против" этот аргумент и "за или против" чего. Тут вот совсем недавно и совсем рядом девушка хотела аналог std::string, но чтобы работал на ANSI C. В результате имеет "те же яйца, только сбоку" (к)

igna не девушка, а Игорь Игнатюк