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

TL>

TL>В настоящее время лишь около двух процентов системного ядра «Linux» написано самим Торвальдсом, но за ним остаётся решение о внесении изменений в официальную ветку ядра.

TL>Это и есть "очень большой и серьезный проект"?

Ну там написано, что он этим проектом руководит...

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

TL>Лично я пока что не вижу чем Сам Линус может мне помочь в моей лично скромной жизни. Копаться в ядре линукса я не буду — что лично мне Линус еще может предложить? А полезного лично для меня?

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

Вот поэтому к его рассуждениям и имеет смысл прислушиваться. Ну чисто чтобы на чужом опыте учиться...

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

MSS>>>Почему не cout.output(i).output(j)?
E>>Потому, что output -- это метод какого-то класса. И в C++ у меня нет возможности расширять чужой класс перегруженными методами для своих типов.

R>Хороший аргумент. Правда он не отменяет возможности писать:
R>

R>output(cout, i);
R>output(cout, j);
R>

R>Это впрочем уже не так красиво...

Это недоработка. Такая же, как и public virtual. Должно было быть 2 функции, интерфейс и реализация. Т. е., юзеры перегружали бы одну функцию, а вызывали бы другую. Например:

x.h

class X
{
    . . .
};

void output(std::ostream& os, X const& x) // тема basic_ostream сознательно оставлена за кадром
{
    os << x.toString(); // например
}

ostream

template <class T>
std::ostream& operator <<(std::ostream& os, T const& value)
{
    output(os, value); // unqualified call
    return os;
}

main.cpp

std::cout << X() << std::endl;

Тогда было бы можно использовать и operator <<, и std::cout.out(x).out(y), и т. п.

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

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

Ну почему же нет? Именно описывая методы объекта ты очень точно задаёшь семантику константности...

Pzz>Заметим в скобках, что в языках, в которых нет переменных (т.е., чистая функциональщина), и понятие константы не имеет смысла. В такого рода языках выражение let x = 5 не создает переменной x, а создает человеческое имя для значения 5.
Ну это к обсуждению C vs C++ IMHO мало отношения имеет

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

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

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

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

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

H>Я думаю, что в целом Линус прав, но кое в чем он ошибается. Просто у
H>этих языков — принципиально разные цели. Настолько разные, что их, по
H>большому счету, не имеет особого смысла сравнивать. C++ (как и все ОО
H>языки), в первую очередь, ориентирован на эффективность разработки и
H>сопровождения программы, а C — на эффективность исполнения (память,
H>скорость, объем кода).
Не согласен абсолютно. Одним из главных принципов при разработке С++ было: "you don't pay for what you don't use". Этот принцип вполне нормально соблюдается почти всеми реализациями С++. В результате, на С++ можно писать так же быстро (и даже быстрее — благодаря исключениями, например) как и на С. Более того, можно вообще писать точно так же как и на С (за исключением мелких различий в синтаксисе).

Проблема в том, что многие "C++-программисты" не знают нормально язык — в случае с чистым С они просто были бы недостаточно квалифицированы для разработки. Ну и получаются в итоге жуткие монстрики.

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

C>>Нет. Ссылки, особенно константные ссылки, — это способ самодокументации кода. Если метод принимает константную ссылку — вызывающий может быть уверен, что метод не будет менять объект по этой ссылке (в разумном коде, естественно).
MSS>Не согласен. Чем плохо const T* ?
А оно может быть NULL'ом? А можно ли его сохранить в поле класса? А какое у него время жизни?

Ты не можешь ответить на все эти вопросы просто из описания функции — нужно делать дополнительные комментарии. А это уже само по себе плохо.

C>>Многие ядерные разработчики вообще не понимают смысла константности — типа "и без const'а же работает". Вот сравнительно свежий пример: http://thread.gmane.org/gmane.linux.kernel/595956/focus=596197
MSS>Понимаете, ядерные разработчики не только ядро знают зачастую я знаю, что const — это хорошо.
MSS>Но я не виноват, что Катлер с Луковским его невзлюбили и сделали все ядерные (и половину Win32шных) АПИ без него (кажется, Линус его тоже не любит).
Линус к const равнодушен, в основном из-за того, что во время изначального создания ядра семантика const еще не была нормально определена в С.

MSS>В итоге, чтобы не морочиться с кастами, приходится это "отсутствие const" волочь за собой везде и всюду.
Это, действительно, одна из причин не использовать const. Но ни в коем случае не критика в его адрес.

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

C>>Лучше. Константные ссылки — это по сути оптимизация передачи по значению. В частности, очень частно это делается при передаче временных объектов. Если же брать на них указатель — то мы не можем знать сохранит ли вызываемый код где-то у себя. В случае со ссылками мы знаем, что вызываемый код не будет сохранять переданое ему значение (ну если его не идиоты пишут, конечно).
MSS>Вот про идиотов хорошая оговорка. Идиоты могут передать ссылку в конструктор какого-то класса и позвать его через new.
Так обычно это нормально — я в своих проектах пишу, что передача const-ссылки в конструктор всегда безопасна, так как конструктор обязан будет сохранять копию объекта в поле своего класса. Введут еще rvalue reference и move semantics — вообще круто тогда будет.

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

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

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

Не вижу недостатка.

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

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

TL>Это и есть "очень большой и серьезный проект"?

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

Так и Линус, сколько лет своей жизни он отдал заботам над своим детищем?!

P.S.
Я тоже, когда я оцениваю конкретного человека, я пытаюсь представить что было бы,
если бы не было его самого и его дел.

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

C>Линус к const равнодушен, в основном из-за того, что во время изначального создания ядра семантика const еще не была нормально определена в С.

Семантика const в C не менялась, сколько я себя помню. Т.е., более 20-и лет. Ядро линуха появилось заметно позже. gcc поддерживал ANSI C, включая const, с очень давних времен.

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

C>>Линус к const равнодушен, в основном из-за того, что во время изначального создания ядра семантика const еще не была нормально определена в С.
Pzz>Семантика const в C не менялась, сколько я себя помню. Т.е., более 20-и лет. Ядро линуха появилось заметно позже. gcc поддерживал ANSI C, включая const, с очень давних времен.

char * str="Hello, world!";

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

Pzz>>Семантика const в C не менялась, сколько я себя помню. Т.е., более 20-и лет. Ядро линуха появилось заметно позже. gcc поддерживал ANSI C, включая const, с очень давних времен.

C>char * str="Hello, world!";

И чо?

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

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

Временный объект при передаче по значению — это локальная переменная вызываемой процедуры.

C>Тут Егор уже объяснил. Могу объяснить и я, если интересно.

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

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

Pzz>>В Си нет такой вещи, как иерархия классов. А именно ее очень болезненно переделывать.
C>Как нет?!?! Очень даже есть! Посмотри на GObject'ы в GTK, например.

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

GTK писали студенты, это надо понимать. Им было прикольно.

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

Эээ. А я лично (командой из 3-х человек) выразил в 60К строк на Си примерно то, что команда из 6-и человек до меня выразила в 300К строк кода на C++. Поэтому у меня другой опыт.

P.S. Их C++'ный код был очень хорош, как и мой Сишный.

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

AF>Слишком обобщенные решения для обычного прикладного программирования.

Это где же Александреску говорил, что его решения — для прикладного программирования???

А если какие-то идиоты принимаются писать прикладной код в стиле библиотечного кода, а гуй — на асме, а драйвер — на вижуал-бейсике — так это их персональные половые проблемы.

You will always get what you always got
  If you always do  what you always did

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

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

TL>>

TL>>В настоящее время лишь около двух процентов системного ядра «Linux» написано самим Торвальдсом, но за ним остаётся решение о внесении изменений в официальную ветку ядра.

TL>>Это и есть "очень большой и серьезный проект"?

E>Ну там написано, что он этим проектом руководит...

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

You will always get what you always got
  If you always do  what you always did

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

J>Ну т.е. Торвальдс — это менеджер. Чего он полез с менеджерской колокольни судить о языке, которого он не знает — не очень понятно.
Нет, Торвальдс — очень хороший программист. Но! Он системный программист, часто работающий на уровне ассемблера (он писал, что GDB в качестве дизассемблера чаще всего использует).

В результате — у него стандартная болезнь системщиков. Т.е. неприятие чего-либо кроме С.

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

Pzz>

C>>char * str="Hello, world!";
Pzz>

Pzz>И чо?
Ну как бы все стандартные функции работы со строками до некоторого времени принимали "char*", например.

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

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

C>>Тут Егор уже объяснил. Могу объяснить и я, если интересно.
Pzz>Проще спорить с одним, чем с двумя. Выберете от себя делегата
Мне повторять лениво