Вышел Boost 1.35

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

>Это потому, что ты мутно формулируешь задачу - то дать доступ к члену класса, то к его копии.

Задача дать доступ к *значению* члена. Это может быть ссылка на значение, а может быть копия значения. Какая разница собственно?

> Задача дать доступ к *значению* члена. Это может быть ссылка на значение, а может быть копия значения. Какая разница собственно?

Пока не захочешь изменить это значение - никакой. Но про то. что изменения не планируются, ты не сказал.

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

Попячься, безудержный огнемёдчег. По существу опять сказать нечего?

> совершенно очевидно что Bar это
> полиморфный объект, так как он лежит в куче и доступен через указатель
Совершенно очевидно ололо.
Ты жжёшь всё сильнее.
Значит, по-твоему, если объект лежит в куче и доступен через указатель, то это полиморфный объект и никак иначе?
Пешы есчо, %username%.

> Задача дать доступ к *значению* члена. Это может быть ссылка на значение, а может быть копия значения. Какая разница собственно?
Создать ненужную копию объекта или не создавать?
Конечно же никакой разницы нет. А лучше создать сразу две ненужные копии - одну отдать сразу, вторую оставить прозапас.

аватаре место на помойке.

Жепь ебрило, %username%

>> совершенно очевидно что Bar это полиморфный объект, так как он лежит в куче и доступен через указатель

>начит, по-твоему, если объект лежит в куче и доступен через указатель, то это полиморфный объект и никак иначе?

А нахрена объект-значение класть в кучу?

>> Задача дать доступ к *значению* члена. Это может быть ссылка на значение, а может быть копия значения. Какая разница собственно?

>Конечно же никакой разницы нет. А лучше создать сразу две ненужные копии - одну отдать сразу, вторую оставить прозапас.

Ты вообще делаешь срезку объекта Bar при каждой операции getBar().

>По существу опять сказать нечего?

Приведи цитату из своих предыдыщих высеров по существу.

PS: Теперь я начинаю понимать почему поддержка стандарта С++ в msvc появилась только тогда когда с выходом платформы .NET VisualC++ перестал быть флагманским продуктом в линейке. MS просто не хотели на стратегическом направлении из MFC и ATL армию олегофренов типа gpg держать.

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

>Сильно пришлось бы постараться, чтобы повыше получилось, однако

интересно, зачем постоянно тыкают бенчмарками? вы действительно верите, что на свете ровно один компилятор Оберона и ровно одна архитектура? O_o

>Ой, шаблоны, оказывается ведут к расходу памяти? Просветите, плз.

ведут, ведут. не сами шаблоны, конечно, — они просто компилятор тормозят, не более. зато неуёмное желание сделать шаблон и наплодить ним кучу одинакового кода — вполне реальная ситуация, и экономии памяти никак не способствует. кстати, авторов OO2C за «генерики» тоже надо больно бить. %-)

>Ага, конечно. То, что в C++ пишется простым арифметическим выражением в Oberon-е нужно разложить вручную на элементарные составляющие. Т.е. написать раза в 3–4 больше кода, а потом надеятся, что оптимизатор все это заинлайнит.

я как-то пропустил: что, задача была чисто математическая? тогда пардон, скорее всего я бы не Оберон выбирал. что именно — с ходу не скажу, сильно зависит именно от задачи. видите ли, я знаю не только С, C++, Oberon, а несколько побольше языков. и не боюсь писать части проектов на разных. работать тоже предпочитал в командах, где на C++ не зациклены.

>Если с Oberon-ом все так прекрасно, не объясните, почему встроенное ПО на C++ пишут все, кому не лень, а на Oberon-е нужно днем с огнем искать? Если уж Oberon такой серьезный конкурент в этой области…

если линукс так удобен на десктопе, не объясните, почему большинство ПО пишут для винды и все, кому не лень, а для линукса совсем не многие чешутся? если уж линукс такой серьёзный конкурент в этой области…

> интересно, зачем постоянно тыкают бенчмарками?

Потому что не всем нравится слова вроде "полагаю" вот в таком обмене репликами:

>>И получили бы такую же производительность, как в C++?

>полагаю, повыше.

>>Сильно пришлось бы постараться, чтобы повыше получилось, однако

>интересно, зачем постоянно тыкают бенчмарками? вы действительно верите, что на свете ровно один компилятор Оберона и ровно одна архитектура? O_o

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

Тем более, что в отличии от C++, у Оберона есть такой маленький недостаток -- Оберона может не быть под нужную платформу.

>>Ой, шаблоны, оказывается ведут к расходу памяти? Просветите, плз.

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

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

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

>>Ага, конечно. То, что в C++ пишется простым арифметическим выражением в Oberon-е нужно разложить вручную на элементарные составляющие. Т.е. написать раза в 3–4 больше кода, а потом надеятся, что оптимизатор все это заинлайнит.

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

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

>видите ли, я знаю не только С, C++, Oberon, а несколько побольше языков. и не боюсь писать части проектов на разных. работать тоже предпочитал в командах, где на C++ не зациклены.

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

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

>>> совершенно очевидно что Bar это полиморфный объект, так как он лежит в куче и доступен через указатель

>>начит, по-твоему, если объект лежит в куче и доступен через указатель, то это полиморфный объект и никак иначе?

>А нахрена объект-значение класть в кучу?

Есть, по меньшей мере, несколько причин:

1. Значение атрибута _bar неизвестно во время конструирования объекта Foo, а вычисляется, например, в каком-то из модифицирующих объект методов.

2. Для Foo проще реализовать безопасный по исключениям оператор присваивания, владея _bar через указатель. Например, в случае, если Bar является частью идиомы PIMPL для Foo.

3. Объект Bar слишком большой (например, содержит в себе вектора/матрицы больших размерностей) чтобы безболезнено создавать его на стеке.

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

Тем более, что в отличии от C++, у Оберона есть такой маленький недостаток — Оберона может не быть под нужную платформу.

кто мешает использовать C как back-end? портабельный ассемблер — это удобно. %-)

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

а код памяти не занимает, живёт в астрале? O_o

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

и нам снова начинать нарезать круги вокруг утечек памяти и багов мусоросборки? смысл? к тому же я специально явно упомянул UNTAGED POINTERS.

>Тогда бы стало понятно, что имеющаяся там математика только часть проблемы.

вот именно. однако прицепились зачем-то именно к математике.

>Человек проработал десять лет и уже знает столько языков.

«занимаюсь профессионально» — означает «получаю за это деньги, а не just for fun only».

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

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

впрочем, это опять повод для флэйма. сейчас меня снова будут обзывать «гением», тщателльно стараясь, чтобы ненапечатаные кавычки были видны, опять пояснят, что раз «мелкое и наживное» — то я на самом деле не знаю толком ничего… скучно. а начиналось вполне интересно.

можете зашитать мне слив и нарисовать очередную звёздочку на фюзеляже. с моей стороны case closed.

> к сожалению, бенчмарки имеют такое же отношение к реальной жизни, как и рассуждения очкастого интеллигента-девственника о женщинах к реальному сексу.

Тем не менее, это общепринятый способ сравнения и языков, и компиляторов.

> единственно возможное сравнение — сделать большой рабочий проект на C++ и на Обероне, а потом сравнить

Такой вот дорогой бенчмарк, который вдруг выиграет менее качественный компилятор.

>Тем не менее, это общепринятый способ сравнения и языков, и компиляторов.

общепринятое == лучшее? O_o

>Такой вот дорогой бенчмарк, который вдруг выиграет менее качественный компилятор.

не выиграет, от Солнца оторвётся кусок и всех убьёт.

case closed.

>> Тем не менее, это общепринятый способ сравнения и языков, и компиляторов.

> общепринятое == лучшее? O_o

В данном случае - единственное практичное.

> case closed.

Жаль. Было весело.

>Жаль. Было весело.

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

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

>>Тем более, что в отличии от C++, у Оберона есть такой маленький недостаток — Оберона может не быть под нужную платформу.

>кто мешает использовать C как back-end? портабельный ассемблер — это удобно. %-)

А какие еще компиляторы Оберона, кроме OO2C транслируют Оберон в C? И имеют реализацию рантайма Оберона и его стандартных библиотек для различных платформ?

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

>а код памяти не занимает, живёт в астрале? O_o

Вы не внимательно читаете: я же специально сказал, что размер кода здесь не показатель -- он известен заранее. И если код с шаблонами не помещается в RAM/ROM целевой платформы, то можно обойтись и без шаблонов.

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

>и нам снова начинать нарезать круги вокруг утечек памяти и багов мусоросборки? смысл? к тому же я специально явно упомянул UNTAGED POINTERS.

Я ничего не говорил ни про утечки памяти, ни про баги GC. Просто существуют исследования, которые показывают, что языки с GC показывают сравнимую производительность с языками с явным управлением памятью только если свободной памяти доступно в несколько раз больше, чем используется приложением. И если уж вы озабочены лишним размером, который дают шаблоны в коде, то следовало бы обратить внимание и на такой аспект так же.

>>Тогда бы стало понятно, что имеющаяся там математика только часть проблемы.

>вот именно. однако прицепились зачем-то именно к математике.

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

А вы говорите, что не видите для C++ актуальных ниш.

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

Когда вы начинаете употреблять подобные выражения, то это выглядит как попытка доказать, что именно вы-то и можете выбрать подходящий инструмент. В отличие от ваших собеседников. Которые не только этого не могут сделать, но и языков никаких не знают, кроме C++, да и программируют "just for fun only". Почему-то вы отказываете нам в праве иметь и опыт и знания.

> А нахрена объект-значение класть в кучу?
И этого ты тоже не знаешь. Профессионал.

> Ты вообще делаешь срезку объекта Bar при каждой операции getBar().
Расскажи мне, как при передаче по ссылке происходит срезка, о, создатель альтернативных стандартов.

PS: Я вижу ты уже начал выходить из себя, обожаю раздражать тупаков, они забавные. Только, не останавливайся.

>Почему-то вы отказываете нам в праве иметь и опыт и знания.

каждый видит то, что хочет видеть. кто-то — хинт от оппонента, что простые вещи разжёвывать не надо, кто-то — «я один умею и знаю, а вы — куриный помёт».

у меня есть право сомневаться во вменяемости выбравшего C++ (и не доказывать своё право на это право %-), у вас — видеть в моих словах свой смысл.

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

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

Скучно? Месье гурман.
Жаль, конечно, но у нас ещё есть в запасе непревзойдённый человек-стандарт.

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

> у меня сегодня нет настроения троллить.
Кстати да. Интереснейший феномен. Со мной такое бывало.
В самый разгар битвы, когда кровь закипает на раскалённых мечах, противник по пояс в липких какашках и труба играет в атаку, вдруг пропадает всякий интерес.
Мне кажется надо различать благородную усталость адепта светлых сил c++ и презренную унылость приверженца тьмы <подставь язык сам>.

так и запишем: чужой иронии в упор не видит, только свою.

//mirage

ну да. тяжело человеку, умученому плюсами.

//mirage

> Потому что C++ в таких задачах позволяет все делать в рамках одного языка.

1) С каких это пор?

2) На кой это надо?

> При этом язык имеет и статическую типизацию

Ржунимагу с такой типизации. Язык, в котором есть (void *) - это не типпизация, это кошмар.

> и высокоуровневые абстракции

На уровне древних макроассемблеров, не выше.

> и большое количество владеющих им разработчиков

От которых надо держаться подальше, в силу их непрофессионализма и неадекватности.

> так и запишем: чужой иронии в упор не видит, только свою.
Поgъе6нyл прохожего на себя похожего.

> ну да. тяжело человеку, умученому плюсами.
Мои соболезнования. Хочешь поговорить об этом? Вдруг смогу чем-нибудь помочь?


PS: Почему из-под анонимуса? За этим кроется какая-то неприглядная тайна?

>Поgъе6нyл прохожего на себя похожего.

угу. и день прошёл не зря.

>Хочешь поговорить об этом? Вдруг смогу чем-нибудь помочь?

да тут уже сколько страниц наговорили…

>Почему из-под анонимуса? За этим кроется какая-то неприглядная тайна?

угу. тестирование userJS'а и общая ленивость логиниться (все равно у меня статус «аноним»). но фигачить капчу ещё ленивей, там многабукав.

> На кой это надо?
Включи голову. Чтобы не нанимать людей на каждый проект

>> При этом язык имеет и статическую типизацию
> Язык, в котором есть (void *) - это не типпизация, это кошмар.
Не надо работать с идиотами. Подобного рода "кошмары" присутствуют в любом языке.

>> и высокоуровневые абстракции
> На уровне древних макроассемблеров, не выше.
Если тебе не подняться выше, при чём здесь язык?

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

> Включи голову. Чтобы не нанимать людей на каждый проект

Кому нужны ущербные людишки, знающие не более одного языка? Дерьмо и работать будет дерьмово.

> Подобного рода "кошмары" присутствуют в любом языке.

Мало ты языков знаешь...

> Если тебе не подняться выше, при чём здесь язык?

Язык мешает оперировать высокоуровневыми абстракциями. Поскольку в языке отсутствуют конструкции для определения этих самых абстракций. Метапрограммирования нет, HOF-ов нет, карринга нет, система типов ущербная и нерасширяемая.

> Наберись опыта и устройся в приличное место, и ты перестанешь разделять людей по языкам, которые они используют.

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

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

> Мало ты языков знаешь...
Как мерил?

> Язык мешает оперировать высокоуровневыми абстракциями.
Ещё один проблемный танцор? Ты пропустил слово "мне".

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

>1. Значение атрибута _bar неизвестно во время конструирования объекта Foo, а вычисляется, например, в каком-то из модифицирующих объект методов.

Это объект - значение, его по любому нет смысла размещать в куче. Иначе - зачем делали объект - значение, почему было не сделать его полиморфным?

>2. Для Foo проще реализовать безопасный по исключениям оператор присваивания, владея _bar через указатель. Например, в случае, если Bar является частью идиомы PIMPL для Foo.

PIMPL ??? Тип pimpl - объекта по любому незавершенный тип, клиент кода просто физически не сможет ничего с ним сделать. Я уже опускаю такой малозначительный аспект, как "А нафига делать pimpl - объект доступным клиенту через get-метод???"

>3. Объект Bar слишком большой (например, содержит в себе вектора/матрицы больших размерностей) чтобы безболезнено создавать его на стеке.

А каким макаром ты создашь такой объект? std::vector<T> занимает на стеке 4-16 байт, массив аллоцирован в куче. Напрашивается только статический массив, но он может быть фиксированного размера. Но зачем хранить в поле класса std::auto_ptr< std::vector<T> > ?.

>> Ты вообще делаешь срезку объекта Bar при каждой операции getBar().

>Расскажи мне, как при передаче по ссылке происходит срезка, о, создатель альтернативных стандартов.

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

>> А нахрена объект-значение класть в кучу? >И этого ты тоже не знаешь. Профессионал.

Да, профессионал. А ты - дегенерат.

> Ты возвращаешь не по ссылке, а по значению.
http://www.linux.org.ru/jump-message.jsp?msgid=2623536&cid=2628815
К окулисту. Как минимум.

> А ты - дегенерат.
Ты, главное, не заплачь, маленький, здесь мамы нет.

Ох, ё! Как все запущено...

>>2. Для Foo проще реализовать безопасный по исключениям оператор присваивания, владея _bar через указатель. Например, в случае, если Bar является частью идиомы PIMPL для Foo.

>PIMPL ??? Тип pimpl - объекта по любому незавершенный тип, клиент кода просто физически не сможет ничего с ним сделать.

PIMPL -- это пример того, как можно обеспечить безопасный по исключениям оператор присваивания. Такую же практику можно использовать и вне pimpl, например, если в объекте есть несколько атрибутов-указателей.

>Я уже опускаю такой малозначительный аспект, как "А нафига делать pimpl - объект доступным клиенту через get-метод???"

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

>>3. Объект Bar слишком большой (например, содержит в себе вектора/матрицы больших размерностей) чтобы безболезнено создавать его на стеке.

>А каким макаром ты создашь такой объект? std::vector<T> занимает на стеке 4-16 байт, массив аллоцирован в куче. Напрашивается только статический массив, но он может быть фиксированного размера. Но зачем хранить в поле класса std::auto_ptr< std::vector<T> > ?.

Представь себе, что ты занимаешься вычислительной задачей и у тебя в программе масса довольно больших векторов фиксированного размера. Например, объекты типа struct V2048 { double vector[2048]; }; Как их хранить? В виде атрибутов? По значению? Или заменять их все std::vector<double>?

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

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

> Как мерил?

Сявка вякнула про то, что конкретно вот такие глюки с типизацией есть во всех языках? Вякнула. Вот по громкости взвяка и измерил.

> Ещё один проблемный танцор? Ты пропустил слово "мне".

Изобрази мне абстракцию EBNF на C++, кретин. Убожество типа Spirit не предлагать.

> Ты уже третий или четвёртый студер, от которого я это слышу.

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

> Понимаешь ли, быдлятко, опыта у меня более 15 лет

Всего-то? :D Но разговаривать с людьми ты мог бы и научиться. Но, видно, не судьба.

С людьми - это одно дело. А с самоуверенными наглецами вроде gpg - совсем другое. Чмо считает, что лучше других всё знает и имеет наглость поучать, при этом знаний у чма - ноль без палочки. Чмо надо запинать!

>Чмо надо запинать!

Вау! Неужели довелось побеседовать с самим Луговским?

> Неужели довелось побеседовать с самим Луговским?

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

не похож.

Вау, вот это истерика.
Судя по радиусу разбрызгивания слюней неприятие окружающими всерьёз твоей крутизны больная тема? Очень надеюсь, что ты не сломал клавиатуру в последнем припадке, ибо предчувствую ту ещё клоунаду.

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

> Изобрази мне абстракцию EBNF на C++, кретин. Убожество типа Spirit не предлагать.
Так и видится император на колеснице, простирающий длань над армией своих соратников и грозно приказывающий громовым голосом "SPIRIT НЕ ПРЕДЛАГАТЬ!!!". Боже моечки, а если предложу? Что ты будешь делать, любезная истеричка?

> Понимаешь ли, быдлятко, опыта у меня более 15 лет.
Когда тебе стукнет 16, ты, может быть, поймёшь, что твои мантры действуют только на тебя одного. Сильный Ксандр.

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

Есть сильное подозрение, что в реале щенку чуть больше двадцати.
А может, действительно, что-нибудь нервное. Проклятая экология...

http://www.linux.org.ru/jump-message.jsp?msgid=2623536&cid=2628815 К окулисту. Как минимум.

По ссылке:

Bar GetBar() const { return *m_bar; }

К эвтаназиологу, быдло

>> А ты - дегенерат.

>Ты, главное, не заплачь, маленький, здесь мамы нет.

Я уже тебе предлагал забить стрелку, ты приссал.

>> Понимаешь ли, быдлятко, опыта у меня более 15 лет

>Но разговаривать с людьми ты мог бы и научиться. Но, видно, не судьба.

Разговаривать с gpg как с человеком?

> Разговаривать с gpg как с человеком?

Да. И с Absurd, и с tailgunner... или не разговаривать вообще - это Сеть, никто не принуждает общаться с неприятными людьми

> Боже моечки, а если предложу?

Обломаешься, ламерок. Поскольку там из этого ущербного подобия EBNF строится recursive descent parser, а мне, прикинь вот, непременно GLR нужен. И вся эта якобы абстракция накрывается медным тазом.

>>PIMPL ??? Тип pimpl - объекта по любому незавершенный тип, клиент кода просто физически не сможет ничего с ним сделать.

>PIMPL -- это пример того, как можно обеспечить безопасный по исключениям оператор присваивания. Такую же практику можно использовать и вне pimpl, например, если в объекте есть несколько атрибутов-указателей.

Pimpl - это способ удаления лишних зависимостей из *.h файлов. Чтобы компилятор не захлебывался при глубоких инклюдах. Других разумных причин его применять нет. В других языках есть нормальная модульность.

>Представь себе, что ты занимаешься вычислительной задачей и у тебя в программе масса довольно больших векторов фиксированного размера. Например, объекты типа struct V2048 { double vector[2048]; }; Как их хранить? В виде атрибутов? По значению? Или заменять их все std::vector<double>?

Надуманный пример. Если важен перформанс, то можно ограничиться double*