Здравствуйте, Maxim S. Shatskih, Вы писали:
E>>А здесь http://video.google.com/videoplay?docid=6520647478274589397 Андрей Александреску мягко объяснил, что Линус смотрит на C++ со своей очень своеобразной колокольни.
MSS>Что сделал толкового Александреску и что сделал Линус?
Первый написал много толковых книг по вопросу практики примения одного из самых распространенных языков программирования современности. Что такого "архивеликого" сделал второй? Почему рядом с Линусом не поставить, например, Билла Гейтса? Кто из двух последних "вообще круче"?
Здравствуйте, Cyberax, Вы писали:
MSS>>>>Что сделал толкового Александреску и что сделал Линус? C>>>Александреску написал книгу про С++. А вот президент Путин ничего не говорит про С++, а сколько он всего сделал! А>>Да-да-да! Лучше бы он эту книгу не писал которую куча м...ов "прочитала", нихрена не поняла и давай писать программы в подобном стиле что поубивать хочется. C>Не волнуйся, без этой книги эти нехорошие люди писали бы точно так же плохо — но в обычном old C++-стиле
Есть факты "писания в стиле Александреску" без хотя бы мало-мальского понимания сути того "что зачем и как" пишешь?
Здравствуйте, ArtDenis, Вы писали:
AA>>Нет силы разрушительной страшнее, AA>>Чем кода стиль "Я-Прочитал-Александреску"...
AD>После прочтения александреску у меня не появилось желания писать в таком-же стиле, хотя возможность была
Объективные аргументы в обоснование имеются? Не для спора — интереса ради: конструктивную критику всегда приветствовал лично я.
Здравствуйте, The Lex, Вы писали:
А>>>Да-да-да! Лучше бы он эту книгу не писал которую куча м...ов "прочитала", нихрена не поняла и давай писать программы в подобном стиле что поубивать хочется. C>>Не волнуйся, без этой книги эти нехорошие люди писали бы точно так же плохо — но в обычном old C++-стиле TL>Есть факты "писания в стиле Александреску" без хотя бы мало-мальского понимания сути того "что зачем и как" пишешь?
Есть, к сожалению. Лично на себе наблюдал Правда, так как я себя знаю, то я это делал на игрушечных проектах.
Здравствуйте, Pzz, Вы писали:
C>>Нет. Ссылки, особенно константные ссылки, — это способ самодокументации кода. Если метод принимает константную ссылку — вызывающий может быть уверен, что метод не будет менять объект по этой ссылке (в разумном коде, естественно). Pzz>Константные ссылки в этом плане ничем не лучше константных указателей.
Pzz>При этом если я в Си передаю чего-нибудь по значению, это видно сразу в точке вызова. А в C++ надо посмотреть еще на прототип функции, чтобы узнать, не берет ли она от объекта ссылку вместо значения.
Непонятно в чем разница. Используйте константные ссылки если значение нельзя будет менять — т.е. если ссылка — "оптимизация передачи по значению": при этом точно не ошибетесь — компилятор не даст. В случае передачи по указателю... это указатель на единичный элемент или на массив? Это указатель получил валидный адрес, невалидный адрес (тот самый "указатель на временный объект из какой-то "третьей" функции), или просто null?
Имхо, ссылки в C++ — одна из самых удобных полезностей, к тому же лучше защищенная от "криворукости" программиста, чем указатели.
Pzz>Заметим также, что есть вещи, связанные с сылками, которые вообще остаются невидимыми. Например, функция, получившая адрес объекта, может за какой-нибудь надобностью его засейвить на будущее, что накладывает на меня обязательства не освобождать память, занятую этим объектом. В этом смысле, передача константной ссылки семантически очень отличается от передачи объекта по значению. Столь глубокое семантическое различие на мой взгляд заслуживает различия и в синтаксисе, причем в том месте, где объект передается, а не в том, где его принимают.
Здравствуйте, The Lex, Вы писали:
TL>Объективные аргументы в обоснование имеются? Не для спора — интереса ради: конструктивную критику всегда приветствовал лично я.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Pzz, Вы писали:
Pzz>>>Константные ссылки в этом плане ничем не лучше константных указателей. C>>Лучше. Константные ссылки — это по сути оптимизация передачи по значению.
Pzz>Это плохая оптимизация — у нее слишком много тонких эффектов. Если что-то не может быть сделано прозрачно (а дешевая передача объектов в языке типа Си/C++ не может быть сделана прозрачно, в силу очень открытого интерфейса к реальной памяти машины), то лучше не делать этого вовсе.
Имхо, это не "открытость интерфейса к реальной памяти" — это скорее "наследие адресной арифметики": по неновому уже стандарту первое попавшееся число указателю присвоить простым присваиванием нельзя. Имхо, совместимость в области адресной арифметики с ANSI C, включая некоторые ограничения — тоже одна из полезных фич, позволяющих в одном коде объединять и верхние уровни абстракции, и нижние — реализации.
C>>Язык нам дает гарантию, что если мы не будем делать идиотских поступков — то у нас не будет проблем.
Pzz>При этом грань, отделяющая идиотский поступок от неидиотского столь тонка...
Здравствуйте, The Lex, Вы писали:
TL>Первый написал много толковых книг по вопросу практики примения одного из самых распространенных языков программирования современности. Что такого "архивеликого" сделал второй?
Зато второй -- практик...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, dupamid, Вы писали:
D>Плохой код можно писать на любом языке, так же как и хороший.
Не споря по существу, не могу не заметить, что на BF таки трудно...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Sergey, Вы писали:
>> Насколько я понимаю, использование макросов в ядре обусловлено интрузивностью (ну знаю как это по-русски сказать ) контейнеров. S>И каким образом из отсутствия нужных структур данных в STL следует необходимость использования макросов, а не шаблонов?
Согласен, не следует, но для контейнера/структуры данных которая используеться один раз городить темплейтный класс наверное нет надобности, хотя это, конечно, не аргумент. Тогда конкретный вопрос — а вы можете посоветовать/показать какую-то библиотеку интрузивные темплейтных контейнеров (мой опыт работы с с++ небольшой и для него stl контейнеров вполне хватало)?
S>Который потом линкером выкидывается — если код и вправду получился одинаковый.
При динамической линковке не выкидываеться. Т.е если библиотека ядра содержыт класс template< class T > class IOService который является базовым для драйверов и
есть драйвер class DriverA : IOService< DriverA > и
есть еще один драйвер class DriverB : IOService< DriverB >,
то оба бинарника драйверов будут содержать копии IOService и при загрузке в ядро эти копии не выкинуться, даже если код будет одинаковым.
Теоретически, конечно же, можно писать части ядра на С++[1] (да и не только на нем), но практически — >> ... то только как си-с-классами.
S>Вообще-то он про GIT говорил...
В этой части веточки разговор был о с++ для ядра, а линус говорил о system-level and portable C++ (что в том числе и ядро и гит, по крайней мере, так я понимаю system-level). А даже если посмотреть на открытые системы контроля версий, то преимущества выбора с++(monotone) как языка реализации там совсем неочевидны, уже скорее "чистого си"(сvs,subversion,git) и питона(baazar,mercurial).
Все это конечно же под знаком IMHO .
[1] L4Ka::Pistachio microkernel, Fiasco µ-kernel — микроядра написанные на с++ и даже с темплейтами . Правда темплейты используються только для внутренней реализации — грубо говоря темплейтом задается архитектура под которую компилиться микроядро.
Здравствуйте, Maxim S. Shatskih, Вы писали:
AA>>Нет силы разрушительной страшнее, AA>>Чем кода стиль "Я-Прочитал-Александреску"...
MSS>После всего вот этого я начинаю понимать, что и не хочу читать Александреску
>>> Насколько я понимаю, использование макросов в ядре обусловлено интрузивностью (ну знаю как это по-русски сказать ) контейнеров. > S>И каким образом из отсутствия нужных структур данных в STL следует необходимость использования макросов, а не шаблонов? > > Согласен, не следует, но для контейнера/структуры данных которая используеться один раз городить темплейтный класс наверное нет надобности, хотя это, конечно, не аргумент.
Если сгородили макрос — значит и шаблон городить есть смысл
> Тогда конкретный вопрос — а вы можете посоветовать/показать какую-то библиотеку интрузивные темплейтных контейнеров (мой опыт работы с с++ небольшой и для него stl контейнеров вполне хватало)?
В бусте то ли уже появились, то ли вот-вот будут. А пока широко распространенных нету — и самому недолго написать.
> S>Который потом линкером выкидывается — если код и вправду получился одинаковый. > При динамической линковке не выкидываеться. Т.е если библиотека ядра > > содержыт класс template< class T > class IOService который является базовым для драйверов и > есть драйвер class DriverA : IOService< DriverA > и > есть еще один драйвер class DriverB : IOService< DriverB >, >> то оба бинарника драйверов будут содержать копии IOService и при загрузке в ядро эти копии не выкинуться, даже если код будет одинаковым.
Ситуация тут ровно та же, что и с макросами. И даже если все "руками написать", то — сюрприз — все равно две копии кода будут Так что в качестве аргумента против шаблонов — не катит.
> Теоретически, конечно же, можно писать части ядра на С++[1] (да и не только на нем), но практически - >>> ... то только как си-с-классами.
С классами и шаблонами... И кстати даже си-с-классами — уже совсем не "голый С". Система типов более строгая.
> S>Вообще-то он про GIT говорил... > В этой части веточки разговор был о с++ для ядра, а линус говорил о system-level and portable C++ (что в том числе и ядро и гит, по крайней мере, так я понимаю system-level).
С чего бы это система контроля версий вдруг стала system-level?
> А даже если посмотреть на открытые системы контроля версий, то преимущества выбора с++(monotone) как языка реализации там совсем неочевидны, уже скорее "чистого си"(сvs,subversion,git) и питона(baazar,mercurial).
Лень мне по их исходникам лазить... А без изучения — какое может быть сравнение? Да и квалификацию писателей все равно не учтешь.
> Все это конечно же под знаком IMHO . > > [1] L4Ka::Pistachio microkernel, Fiasco µ-kernel — микроядра написанные на с++ и даже с темплейтами . Правда темплейты используються только для внутренней реализации — грубо говоря темплейтом задается архитектура под которую компилиться микроядро.
А никто и не предлагает интерфейсы плюсовые наружу выставлять...
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
S>"C++ leads to really really bad design choices". — усе так и есть. C не позволяет схалтурить, объем исходников на С получается больше, поэтому горячим парням приходится сначала подумать а уж потом кодить С плюсами же можно по-быстрому налабать прототипчик и потом постепенно его дотачивать.
В реальности все строго наоборот. C++ (вообще, ООП) прощает все, кроме неудачного разбиения программы на классы. К сожалению, разбивать ее на классы приходится рано, когда нет достаточной ясности, как программа будет устроена. Поэтому вероятность разбить ее на классы неудачно очень велика.
Кроме того, кода на C++ тоже обычно получается больше, чем на Си, из-за более детального описания "правил игры" с объектами.
S>"You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap" — тут логика отсутствует. Не хочешь — не используй.
Если ты — руководитель проекта, то очень трудно объяснять каждому следующему программисту, почему это мы используем, а это — нет. Проще иметь некоторые универсальные правила, которым все должны следовать. Причем сами по себе правила должны быть простыми, иначе их никто не удосужится дочитать до конца. И следовать, соответственно, не будет.
Правило неиспользования 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." Ну собственно это надо быть очень меедленным программистом (проще говоря, тупым тормозом), чтобы пару лет не замечать, что чего-то там круто тормозит.
Речь, по-моему, идет не о "тормозении" кода, а о неадекватности выбранной абстракции. С чем может быть трудно что-то сделать, если большой объем кода от этой абстракции сильно зависит.
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.
Для того множества типов, которые доступны в обоих языках, строгость проверки их почти одинаковая.
S>"So I'm sorry, but for something like git, where efficiency was a primary objective, the "advantages" of C++ is just a huge mistake." — ну собственно вольному воля. Аргументация, правда, по-прежнему отсутствует.
Это да. Mercurial написан вообще на Питоне, и при этом не сказать, что тормозит. И в отличии от Git'а, неплохо работает на Венде.
S>Ну а дальше он собственно Monotone ругает — не знаю, может она и правда "horrible and unmaintainable mess", но чето в этом сомневаюсь. Она, по крайней мере, почему-то Cygwin для запуска под виндой не требует — в отличие от "portable" GIT. Т.е., "horrible and unmaintainable mess" на винду портировали, а portable и mantainable — нифига.
Ну то, что Git не работает на Венде — вполне сознательная позиция Линуса. C++ тут не при чем. Портировать-то его, конечно, как-то портировали, но для полноценной поддержки Венды надо бы, как минимум, разобраться с \r\n, с тем, что Виндовая файловая система не чувствительна к регистру и с тем, что надо что-то делать с юниксными правами доступа (очень раздражает, когда скрипты теряют битик, разрешающий их to execute, или наоборот, все файлы этот битик приобретают) и с юниксными симлинками.
Здравствуйте, Константин Л., Вы писали:
Pzz>>И как из того, что там написано следует, что я сказал ересь?
КЛ>Ок, сорри, ты меня не понял. Линус сказал ересь, а не ты.
Здравствуйте, The Lex, Вы писали:
MSS>>Что сделал толкового Александреску и что сделал Линус?
TL>Первый написал много толковых книг по вопросу практики примения одного из самых распространенных языков программирования современности. Что такого "архивеликого" сделал второй? Почему рядом с Линусом не поставить, например, Билла Гейтса? Кто из двух последних "вообще круче"?
Александреску не просто еретик, а еретик, активно несущий свою ересь в массы, путем писания книг. Ясно, что писатели попадают в какой-то более крутой круг ада, чем простые содомиты и прелюбодеи
Ставить Торвальдса рядом с Гейтсом бессмыссленно. Первый — менеджер софтверного проекта, архитектор и кодировщик. Второй — успешный бизнесмен. Гейтс вполне мог бы заниматься и не софтварием, Линус — вряд ли.
Здравствуйте, The Lex, Вы писали:
Pzz>>При этом если я в Си передаю чего-нибудь по значению, это видно сразу в точке вызова. А в C++ надо посмотреть еще на прототип функции, чтобы узнать, не берет ли она от объекта ссылку вместо значения.
TL>Непонятно в чем разница.
Разница в том, что вызываемая процедура получает не значение объекта, а его адрес. Это как платить не деньгами, а пластиковой картой — вы не просто отдаете продавцу 10 баксов, Вы авторизуете его покопаться в Вашем банковском счете. Как только Вам попадется нечестный (или просто неаккуратный) продавец, Вы сразу поймете, что это не одно и то же.
Здравствуйте, The Lex, Вы писали:
Pzz>>Это плохая оптимизация — у нее слишком много тонких эффектов. Если что-то не может быть сделано прозрачно (а дешевая передача объектов в языке типа Си/C++ не может быть сделана прозрачно, в силу очень открытого интерфейса к реальной памяти машины), то лучше не делать этого вовсе.
TL>Имхо, это не "открытость интерфейса к реальной памяти" — это скорее "наследие адресной арифметики": по неновому уже стандарту первое попавшееся число указателю присвоить простым присваиванием нельзя. Имхо, совместимость в области адресной арифметики с ANSI C, включая некоторые ограничения — тоже одна из полезных фич, позволяющих в одном коде объединять и верхние уровни абстракции, и нижние — реализации.
Это наследие совместимости с Си. В Си такая открытость к аппаратуре была сделана вполне сознательно. В C++'е она мешает созданию нормальных высокоуровневых абстракций. В первую очередь потому, что трудно полностью скрыть тот факт, что управление памятью осталось ручным. И что любые объекты — всего лишь байты в памяти.
Если бы язык проектировался начисто, а не рос из Си, как само растется, вполне можно было бы от source level совместимости с Си отказаться, но предусмотреть способ взаимного procedure calls между языками. Тем более, что там от этой совместимости уже сейчас мало чего осталось.
Pzz>>При этом грань, отделяющая идиотский поступок от неидиотского столь тонка...
TL>В ANSI C она еще тоньше. имхо.
Си значительно проще и прозрачнее. Это большое достоинство.
Здравствуйте, Alxndr, Вы писали:
A>Здравствуйте, AndrewJD, Вы писали:
AJD>>Здравствуйте, ArtDenis, Вы писали:
AA>>>>Нет силы разрушительной страшнее, AA>>>>Чем кода стиль "Я-Прочитал-Александреску"...
AD>>>После прочтения александреску у меня не появилось желания писать в таком-же стиле, хотя возможность была AJD>>Значит ты уже зрелый профессионал. А вот на не окрепшие умы эта книга действует разрушительно
A>А что в ней такого разрушительного?
Слишком обобщенные решения для обычного прикладного программирования.
