> а со ссылкой что делать?
а ничего - ее просто не надо хранить

> и как же?
с помощью нормальных IDE

> впрочем судя по приверженности к копрофекальным темам мсье всё равно не знает
no comments

> в glib как-то сделано
и эти люди про костыли что-то пишут...

> ещё бы, потому что аргументов нет
очки протри

> ахаха, и что по-твоему возвращает оператор & от ссылки?
от ссылки на ссылку, ты ж не думаешь, что передав указатель - ты сможешь его в исходном месте изменить, хотя от лисперов можно всего ожидать

> а в стройной системе костылей и подпорок, которыми они в с++ и являются.
угу - средств С не хватает, но новые - это костыли, угу

> в сях почему-то добавление функции в модуль и даже изменение существующей не вынуждает перекомпилировать все остальные модули
в С++ тоже - прекращай чушь писать

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

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

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

>>> [8.2] What happens if you assign to a reference?
>>> Which means that you can't understand the effect of a statement as simple as a=b; without knowing whether a is a reference or not.
>> даже школьник тут "understand"
>и как же?
Это главный и единственный негативный момент в ссылках, это цена за удобство написания кода в ущерб его читабельности посторонними.

>>> [8.3] Some might say that references serve a more generic purpose - they make pointers to objects feel like objects, but for most purposes that can be achieved with typedef TStruct* T;
>>> C++ introduces duplicate facilities in order to introduce other duplicate facilities.
>>как бы он даже примитивный std::vector на указателях сделал? вобщем этот маразм даже комментировать не надо
>в glib как-то сделано
Сделать то можно, не проблема. Но тут в самой постановке автор, похоже, не понимает всей сути ссылок. В частности указатель можно переприсвоить и при использовании его в стиле ссылок это чревато ещё большими проблемами. Т.е. тут никак не дублирование.

>>> [8.5] You can't do it in portable C++. While the reference is probably implemented as a pointer by your compiler, there's no C++ operator to get the address where that pointer is stored
>>внезапно - оператор & нам вернет этот указатель, но аффтар видимо решил даже не думать
>внезапно - оператор & нам вернет этот указатель, но аффтар видимо решил даже не думать
Это опять непонимание природы ссылок. По той же ссылке выше: "There shall be no references to references, no arrays of references, and no pointers to references.". И в крайнем случае, если так захотелось, то можно написать свою реализацию ссылок и выцеплять адрес объекта, но это и будет черезжопием.

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

> итого высер мимо кассы
впрочем судя по приверженности к копрофекальным темам мсье всё равно не знает

> даже школьник тут "understand"
и как же?

> как бы он даже примитивный std::vector на указателях сделал?
в glib как-то сделано

> вобщем этот маразм даже комментировать не надо
ещё бы, потому что аргументов нет

> внезапно - оператор & нам вернет этот указатель, но аффтар видимо решил даже не думать
ахаха, и что по-твоему возвращает оператор & от ссылки? Ещё один нелюбитель читать спецификации?

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

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

Тезисы:

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

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

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

> [8.1] For example, a wide class of bugs comes from accessing dangling references - references to objects which were already destroyed
тут ровно та же проблема, что и с указателями - итого высер мимо кассы

> [8.2] What happens if you assign to a reference?
> Which means that you can't understand the effect of a statement as simple as a=b; without knowing whether a is a reference or not.
даже школьник тут "understand"

> [8.3] Some might say that references serve a more generic purpose - they make pointers to objects feel like objects, but for most purposes that can be achieved with typedef TStruct* T;
> C++ introduces duplicate facilities in order to introduce other duplicate facilities.
как бы он даже примитивный std::vector на указателях сделал? вобщем этот маразм даже комментировать не надо

> [8.4]
тут он вяло ругает iostream - не буду спорить, эта библиотека мне тоже не нравится

> [8.5] You can't do it in portable C++. While the reference is probably implemented as a pointer by your compiler, there's no C++ operator to get the address where that pointer is stored
внезапно - оператор & нам вернет этот указатель, но аффтар видимо решил даже не думать

> [8.6] Pointers to objects of classes with overloaded operators lead to code like (*parr)[i], which gets annoying.
и какого х%я было распинаться про ненужность ссылок, если потом с умным видом показывать их необходимость

> [8.7] with C++ classes, changing a private member triggers recompilation of user code
изменение кода ведет к необходимости перекомпиляции - это несомненно большой недостаток языка

// что-то это мне напомнило тред на лоре, где делали яичнищу)))

This is what gives us horrors like GNU emacs and Mach: they don't try to do one thing well, they try to do _everything_ based on some loose principle ("LISP is good" or "microkernels make sense" or "GGI should do graphics")

 http://lkml.org/lkml/1998/3/26/8

Лично я с ним не согласен.

>So if a language change were to make people much more
>productive, that would be a good thing regardless of how
>much people end up getting paid.
Так то оно так, но вот что у него даже при желании получилось перевести ядро на C++ я сомневаюсь. Во-первых, кодовая база огромная, и её так просто не перепишешь, во-вторых, многие ведущие разработчики так же как он С-повёрнуты.

>For example, I personally don't even write much code any
>more, and haven't for years. I mainly merge
Это и далее про общение. Всё так, Линуса устраивает картина, т.к. ему и 50и другим лидам удобнее читать патчи вне контекста. Но вот каково остальным 950и разработчикам - ему по барабану.

>And there is a very strong "culture" of C
Эта культура - скорее пример тяжёлого наследственного бремени с его creat и прочим, а вот собственно мой недавнешний пост про UNIX-API

 http://www.linux.org.ru/forum/development/4427471#comment-4429422

>It's true in general in any sw project, but it's true in real
>life too: speaking or writing ambiguously is not good in
>normal human communication either.
Это неправда. Люди как раз живут, общаются и вообще думают в терминах объектов. Лично мне так гораздо проще проектировать что-то, и я думаю так будет с каждым, у кого ещё мозг не травмирован C. И про общение - люди как раз общаются в контексте и разговаривают. Возьмите книгу и прочтите какой-ть диалог из середины. Ничего не будет понятно. Но Линуса это не устраивает, н хочет убрать из обихода все местоимения, заменив их полным определениями. Ему так проще.

 http://lex-kravetski.livejournal.com/301063.html

В ту же тему.

Для Ъ: Линус какбы негодуе по поводу C++.