Вышел Boost 1.35

> В питоне? Не понятно. >Хмм... Апстену?

> учиться, учиться и ещё раз учиться.

Именно. Вам. Начать можно с MVC. И finally. __del__ и деструуторы питоне не нужны. И __init__ в каждом классе - тоже не нужен, если подумать.

> __init__ в каждом классе - тоже не нужен, если подумать.

Это смотря о чем думать - так можно сказать, что конструкторы вообще не нужны, нигде и никогда.

Нет, я за описание мета-полей как членов класса, вместе с дефолтными значениями и маппингом из/в xml/json/etc. Мы не стобой разве флеймили на эту тему?

> я за описание мета-полей как членов класса, вместе с дефолтными значениями

Конструктор может делать как раз это.

> и маппингом из/в xml/json/etc

Маппинг не всегда есть.

> Мы не стобой разве флеймили на эту тему?

Да разве это был флейм? 8)

> Конструктор может делать как раз это.

Да, он их генерирует по полям класса. Кстати при желании можно сделать без геммороя и строгую проверку в __setattr__, сравнивая со списком полей класса, для тхе классво где оно полезно.

>> и маппингом из/в xml/json/etc

> Маппинг не всегда есть.

Опционно, конечно.

>> Конструктор может делать как раз это.

> Да, он их генерирует по полям класса

А может и не по полям класса :) Зачем лишать людей гибкости? По-любому, генерация значений - это код, поэтому конструктор неизбежен.

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

Это типа своя реализация __slots__? ;)

> А может и не по полям класса :) Зачем лишать людей гибкости?

Я себя лишаю, там где мне это удобно.

> По-любому, генерация значений - это код, поэтому конструктор неизбежен.

Да, но одын на всю программу ;)

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

> Это типа своя реализация __slots__? ;)

Сравнил! я могу на время тестов сравнивать и *типы* значения, переданного __setattr__, с известным мне типом значения по умолчанию!

>> А может и не по полям класса :) Зачем лишать людей гибкости?

> Я себя лишаю, там где мне это удобно.

Ну если фраза звучит как "мне конструкторы не нужны", тогда конечно :)

>> По-любому, генерация значений - это код, поэтому конструктор неизбежен.

>Да, но одын на всю программу ;)

И объект - тоже один. Назовем его класс TApplication :D

> я могу на время тестов сравнивать и *типы* значения, переданного __setattr__, с известным мне типом значения по умолчанию!

А почему только на время тестов? ;)

> И объект - тоже один. Назовем его класс TApplication :D

вот не надо его так называть! однажды неплохие в принципе ребята назвали его так и.. лучше не надо.

// wbr

>А почему только на время тестов? ;)

твоё пристрастие к статической типизации поражает. Ну очень редко без неё не обойтись. Крайне. А у тебя прямо фетиш =)

>> И объект - тоже один. Назовем его класс TApplication :D

> вот не надо его так называть!

Да ты кого угодно уговоришь O_o Ладно, не будем называть его так.

>однажды неплохие в принципе ребята назвали его так и.. лучше не надо

TurboVision рулит

>> А почему только на время тестов? ;)

> твоё пристрастие к статической типизации поражает.

Учили меня так.

> Ну очень редко без неё не обойтись. Крайне.

Строго говоря, без нее можно обойтись всегда. Но зачем?

> А у тебя прямо фетиш =)

Я видел слишком много last-minute правок в Питон-прогах, которые бросали {Attribute,Name}Error. И уже типа отлаженных прог, которые бросали их же.

Кстати, не я один хочу статическую типизацию в Питоне :)

>> Я себя лишаю, там где мне это удобно.

>Ну если фраза звучит как "мне конструкторы не нужны", тогда конечно :)

В конструкторе недоступен this, поэтому в конструкторе невозможно зарегить где-то свой инстанс. Например зарегистрироваться в обсервере или создать в конструкторе инстанс Command который вызывает метод твоего класса. В практичных нелямбдаозабоченных С++ библиотеках которые вызывают рвоту у С++-филов (типа MFC) вся инициализация производится в методах типа Create.

>>Да, но одын на всю программу ;)

>И объект - тоже один. Назовем его класс TApplication :D

И все сорцы будут зависить от хедера TApplication. Втопку.

> В конструкторе недоступен this, поэтому в конструкторе невозможно зарегить где-то свой инстанс.

O_O

> И все сорцы будут зависить от хедера TApplication.

O_X

P.S. вообще-то речь шла о Питоне, но и для Си++ аргументы, хм, странные.

>Учили меня так.

это весьма печально

>Строго говоря, без нее можно обойтись всегда. Но зачем?

потому что проще? =)

>Я видел слишком много last-minute правок в Питон-прогах, которые бросали {Attribute,Name}Error.

и? это не самый популярный способ отстрелить себе ногу в питоне, кстати. Если ты разработчик - знай и люби свой инструмент (как минимум - помнить про pylint), а если ты пользователь - выбирай тот софт, который нормально работает.

Я вот наблюдаю постоянные падения в корку плюсовых программ. Значит ли это, что статическая типизация не панацея? =)

>Кстати, не я один хочу статическую типизацию в Питоне :)

собсно, разве кто-то мешает сделать свой питон - с блекджеком и так далее?

>>Учили меня так.

>это весьма печально

Не для меня.

>> Я видел слишком много last-minute правок в Питон-прогах, которые бросали {Attribute,Name}Error.

> и?

Компилятор со статической проверкой типов это не пропустил бы.

> Я вот наблюдаю постоянные падения в корку плюсовых программ. Значит ли это, что статическая типизация не панацея? =)

Панацеи вообще нет.

>>Кстати, не я один хочу статическую типизацию в Питоне :)

>собсно, разве кто-то мешает сделать свой питон - с блекджеком и так далее?

Не кто, а что - отсуствие нужной квалификации и времени.

>> В конструкторе недоступен this, поэтому в конструкторе невозможно зарегить где-то свой инстанс.

>O_O

Это типичная хренотень кода пишешь Си++ код. В конструкторах делать нечего обычно, все вылезает во всякие postInit().

>> И все сорцы будут зависить от хедера TApplication.

>O_X

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

>Не для меня.

"если ты чего-то никогда не знал - ты не станешь об этом жалеть"

>Компилятор со статической проверкой типов это не пропустил бы.

я тебе скажу два ( вернее три ) волшебных слова - REPL (кстати, ipython - неплохая штука) и "скорость разработки". Вопросы будут? =)

>Панацеи вообще нет.

твои сокрушения по поводу типизации в питоне выглядят именно так, как будто это единственная проблема питона, мешающая ему порвать все остальные ЯП =)

>Не кто, а что - отсуствие нужной квалификации и времени.

Ну время вообще дефицит, а вот отсутствие квалификации для прочтения документации настораживает =)

>>> В конструкторе недоступен this, поэтому в конструкторе невозможно зарегить где-то свой инстанс.

>>O_O

>Это типичная хренотень кода пишешь Си++ код. В конструкторах делать нечего обычно, все вылезает во всякие postInit().

То есть this в конструкторе таки доступен, но до завершения работы всех конструкторов ты его не хочешь/неможешь использовать? Так и скажи.

> Да, нужно минимизировать зависимости внутри проекта

Блин. У нас в гостях Капитан Очевидность? Ничего, что большая часть кода зависит от какого-нибудь stdexcept, но вот зависеть от TApplication - низзя, пусть он даже и сторонняя библиотека, которую никто никогда не меняет.

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

в принципе верно, наличие у базового класса методов типа startTimer() или insertChild является хорошим сигналом "внимание! индусокод!"

>>Не для меня.

>"если ты чего-то никогда не знал - ты не станешь об этом жалеть"

Ну так "Незнание - сила", йоптыть.

>>Компилятор со статической проверкой типов это не пропустил бы.

>я тебе скажу два ( вернее три ) волшебных слова - REPL (кстати, ipython - неплохая штука) и "скорость разработки". Вопросы будут? =)

Да. Причем здесь это? Оно как-то противоречит статической типизации?

> твои сокрушения по поводу типизации в питоне выглядят именно так, как будто это единственная проблема питона, мешающая ему порвать все остальные ЯП =)

Это всего лишь главная проблема Питона для меня лично.

> отсутствие квалификации для прочтения документации настораживает =)

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

> Да, но одын на всю программу ;)

> И объект - тоже один. Назовем его класс TApplication :D

Да, есть косяк с наследованием. Но мега-класс будет в общем пустой. Желающие могут дергать аналог с своем конструкторе без наслдедования

> А почему только на время тестов? ;)

Зависит от требуемой скорости, для того что я лениво пишу - можно навсегда.

>Ну так "Незнание - сила", йоптыть.

я бы даже добавил "неодолимая"

>Да. Причем здесь это? Оно как-то противоречит статической типизации?

причем здесь "противоречит"? Минимизирует необходимость =)

>Это всего лишь главная проблема Питона для меня лично.

это "проблема" того же уровня что и приснопамятные "табы". Т.е. вопрос привычки

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

что значит "приемлемой для питона"? В любом случае это будет _другой_ язык уже. Просто добавляешь в транслятор ругань на необъявленные мемберы и всё.

> что значит "приемлемой для питона"?

То, что выигрыш от нее должен окупать затраты на ее использование.

> В любом случае это будет _другой_ язык уже.

Вопрос в том, какая степень схожести является приемлемой (== не создающей лишних проблем).

> Просто добавляешь в транслятор ругань на необъявленные мемберы и всё.

Бугага. Подумай еще хоть 5 минут, или больше не пиши на эту тему.

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

Я бы сказал что конструкторы в С++ по факту ненужны. Там нечего делать кроме как заполнить поля дефолтовыми значениями. Программисты-бобры которым надо не реализовывать гениальный концепт, а писать много кода пользуются методами типа postInit() и Create(...) в которых и делается вся работа по инициализации.

>Ничего, что большая часть кода зависит от какого-нибудь stdexcept

Путать зависимость от стандартной библиотеки и зависимость от third-party компоненты не стоит. От third-party должен зависть бэкэнд чтобы при миграции на следующий релиз сломался бэкэнд а не весь проект.

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

Да, кстати, о минимизации необходимости путем REPL... в насквозь статически типизированных Ocaml и Haskell есть REPL. Его наличие не зависит от модели типизации.

>Да, кстати, о минимизации необходимости путем REPL... в насквозь статически типизированных Ocaml и Haskell есть REPL. Его наличие не зависит от модели типизации.

а я говорил, что зависит? Ты это - прекращай додумывать за меня =)

> Я бы сказал что конструкторы в С++ по факту ненужны.

Тебе не нужны - не используй.

> Программисты-бобры которым надо не реализовывать гениальный концепт, а писать много кода пользуются методами типа postInit() и Create(...)

И как наличие этих методов противоречит конструкторам?

> Путать зависимость от стандартной библиотеки и зависимость от third-party компоненты не стоит. От third-party должен зависть бэкэнд

Вот только не надо умных терминов из SE - ты собираешься менять хэдер TApplication.h, или нет?

>То, что выигрыш от нее должен окупать затраты на ее использование.

а ты попробуй. И убедишься, что в случае питона выигрыша не будет.

>Вопрос в том, какая степень схожести является приемлемой (== не создающей лишних проблем).

что такое "лишние проблемы" ?

>Бугага. Подумай еще хоть 5 минут, или больше не пиши на эту тему.

лень, чесслово. Подскажешь?

>> Да, кстати, о минимизации необходимости путем REPL... в насквозь статически типизированных Ocaml и Haskell есть REPL. Его наличие не зависит от модели типизации.

> а я говорил, что зависит?

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

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

да потому что ты ошипкой в лоб получишь сразу =) Или не получишь, но результат можешь посмотреть сразу.

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

Честно говоря, если бы MOP был не только в CLOS, но и в остальной (не-ОО) части Лиспа, то с его top-level формами можно было сделать и полноценную статическую типизацию. С выводом типов, как в хаскелле.

>>То, что выигрыш от нее должен окупать затраты на ее использование.

>а ты попробуй.

Использование pylint (некое подобие статической типизации) дает выигрыш. У меня нет оснований думать, что усиление статической типизации не даст еще больший выигрыш.

>>Бугага. Подумай еще хоть 5 минут, или больше не пиши на эту тему.

>лень, чесслово. Подскажешь?

Для начала подумай, как определить наличие полей на объектах, отличных от self (аргументах методов и функций); что делать с полиморфными коллекциями; что делать с декораторами.

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

> да потому что ты ошипкой в лоб получишь сразу =)

Еще раз бугага. Ошибка может сильно зависить от потока исполнения, который зависит от данных. Здесь помогу скорее unit-тесты, но 100%-покрытия тестами не бывает, а 100%-проверка компилятором - обычное дело.

> Здесь помогу скорее unit-тесты, но 100%-покрытия тестами не бывает, а 100%-проверка компилятором - обычное дело.

А убережёт ли компилятор от всех ошибок, связанных с неправильной работой с типами?

>Если ты разработчик - знай и люби свой инструмент (как минимум - помнить про pylint)

попробуй, натрави его на Pylons, узнаешь много интересного :)

> А убережёт ли компилятор от всех ошибок, связанных с неправильной работой с типами?

Зависит от языка. В Си/Си++ - нет, ты и сам это знаешь. В Algol68, ошибок, связанных с типами, быть вообще не могло, IIRC.

"There is no silver bullet" (c)

>Использование pylint (некое подобие статической типизации) дает выигрыш. У меня нет оснований думать, что усиление статической типизации не даст еще больший выигрыш.

отрицание не может быть достаточно информационно насыщенным. Или ты думаешь, что выигрыш будет, при этом не забывая огласить - какой именно и в каких местах, или молчишь =)

>Для начала подумай, как определить наличие полей на объектах, отличных от self (аргументах методов и функций); что делать с полиморфными коллекциями; что делать с декораторами.

а как это делают языки со статической типизацией? =) Вот ровно так же. Только я тебя ещё раз предупреждаю - это будет уже не питон =)

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

Зачем? Мне достаточно того, что у меня есть основания так думать, а делать здесь сырой braindump у меня нет желания.

"Giving people dynamic languages doesn't mean they write dynamic programs" (c)

>> Для начала подумай, как определить наличие полей на объектах, отличных от self (аргументах методов и функций); что делать с полиморфными коллекциями; что делать с декораторами.

> а как это делают языки со статической типизацией?

Интересные мне языки изучаю потихоньку.

> Вот ровно так же

Ровно так же не получится.

> Только я тебя ещё раз предупреждаю - это будет уже не питон =)

Блин, еще и ты решил побыть Капитаном Очевидность?

>Еще раз бугага. Ошибка может сильно зависить от потока исполнения, который зависит от данных. Здесь помогу скорее unit-тесты, но 100%-покрытия тестами не бывает, а 100%-проверка компилятором - обычное дело.

можно подумать, ты сегфолтов никогда не видел. И то что сегфолты - это в том числе и обращение по неправильному указателю, возникающее из-за того, что в функцию передали не то - никогда не слышал, да? Причем не "не то значение" а именно "не тот тип структуры/объекта". Или в твоем уютном мирке все параметры передаются по значению? =) Ну тогда да, заявление насчет 100% проверки компилятором имеет шанс быть правдой =)

>> Я бы сказал что конструкторы в С++ по факту ненужны.

>Тебе не нужны - не используй.

Давай без словоблудия. Слоган "выделение ресурсов есть инициализация" не имеет смысла для более-менее сложных случаев когда ресурс должен оповещать обладателя о изменении его внутреннего состояния. Чтобы ресурс мог это сделать, он должен получить this который из конструктора не доступен, т.к объект еще не создан.

>> Программисты-бобры которым надо не реализовывать гениальный концепт, а писать много кода пользуются методами типа postInit() и Create(...)

>И как наличие этих методов противоречит конструкторам?

Очень много в C++ завязано на то что объект создается конструктором, например const-поля.

>Вот только не надо умных терминов из SE - ты собираешься менять хэдер TApplication.h, или нет?

Я бы вообще TApplication не делал. Структура нормального приложения должна быть децентрализована.

>Зачем? Мне достаточно того, что у меня есть основания так думать

в том-то и дело, что нет, а тебе только так кажется =)

а вот возможность обрабатывать в одной функции разные типы параметров ты потеряешь безвозвратно. Напомнить тебе про костыль с названием Variant? =)

>Интересные мне языки изучаю потихоньку.

т.е. как они это делают - ты не знаешь, но тем не менее считаешь статическую типизацию серебряной пулей? =)

>Блин, еще и ты решил побыть Капитаном Очевидность?

вот ещё. Просто я на минтуку представил что произойдет с питоновскими __getattr__ и __setattr__ в случае статической типизации =)

>> Еще раз бугага. Ошибка может сильно зависить от потока исполнения, который зависит от данных. Здесь помогу скорее unit-тесты, но 100%-покрытия тестами не бывает, а 100%-проверка компилятором - обычное дело.

> можно подумать, ты сегфолтов никогда не видел. И то что сегфолты - это в том числе и обращение по неправильному указателю, возникающее из-за того, что в функцию передали не то - никогда не слышал, да? Причем не "не то значение" а именно "не тот тип структуры/объекта".

Блин. Сегфолтов я видел меньше, чем {Name,Attribute}Error. По приведенным тобой причинам обычно возникает не сегфолт, а молчаливое искажение памяти/неверная работа (что еще хуже). Сама передача в указателе адреса объекта не того типа в Си возможна только при насильном приведении типов, это решается runtime-поддержкой, которая есть в Питоне.

> Или в твоем уютном мирке все параметры передаются по значению? =)

Не удержался от наезда, ага? :D

> я на минтуку представил что произойдет с питоновскими __getattr__ и __setattr__ в случае статической типизации =)

Это один из вопросов - что должен позволять статический компилятор.

>Блин. Сегфолтов я видел меньше, чем {Name,Attribute}Error

я думал что ты девелопер =) Я как пользователь - ошибок в скомпиленых прогах вижу на порядки больше, чем в питоне как разработчик.

>По приведенным тобой причинам обычно возникает не сегфолт, а молчаливое искажение памяти/неверная работа

в 90% это все равно приводит к сегфолту. Эффект домино никто не отменял =)

>Сама передача в указателе адреса объекта не того типа в Си возможна только при насильном приведении типов

насильственное приведение типов - обычная практика. Более того - без этого _никуда_ в программах сложнее чем printf("йакреветко\n"); =) так что твои 100% эффективности статической типизации - это, увы, всего лишь фантазии =)

>Не удержался от наезда, ага? :D

окстись, ты прекрасно знаешь, что такое _наезд_ с моей стороны =)

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

что значит "что должен позволять" ? типа "вот это у нас статически типизируется, а вот это - динамически" ? С таким подходом я гарантирую тебе непрекращающуюся головную боль =)

> Просто я на минтуку представил что произойдет с питоновскими __getattr__ и __setattr__ в случае статической типизации =)

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

>>Блин. Сегфолтов я видел меньше, чем {Name,Attribute}Error

>я думал что ты девелопер =)

Я аккуратный девелопер.

>>Сама передача в указателе адреса объекта не того типа в Си возможна только при насильном приведении типов

>насильственное приведение типов - обычная практика.

Даже в Си - нет (исключаем специальный случай void * как generic pointer). Тем более, что речь о Питоне, с RTTI и reflection.

> без этого _никуда_ в программах сложнее чем printf("йакреветко\n")

Я начинаю понимать, где ты видел эти тонны сегфолтов.

> твои 100% эффективности статической типизации - это, увы, всего лишь фантазии =)

Еще раз повторю - это так _в Си_.

> типа "вот это у нас статически типизируется, а вот это - динамически" ?

Возможно. У меня нет дизайна языка.

> С таким подходом я гарантирую тебе непрекращающуюся головную боль =)

Меньше, чем сейчас.

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

ключевой момент ... пользователям свою программу покажит... они иногда умудряются так использовать программу, что диву даешься ... и будет тонна Name,Attribute}Error-ов, стопудова ...

>Я аккуратный девелопер.

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

>Даже в Си - нет (исключаем специальный случай void * как generic pointer). Тем более, что речь о Питоне, с RTTI и reflection.

в си - да. Всё-таки =) Видимо, аккуратные девелоперы программируют только в тех областях, где можно программировать аккуратно без приведения типов =))))))

в питоне - пожалста пример: список разнотипных объектов. И foreach + print :) . И что делать? :)

>Еще раз повторю - это так _в Си_.

видимо, плюсовые программы, которые, к слову падают чаще просто потому что работа с памятью там сложнее - на самом деле не падают, а просто присаживаются отдохнуть =)

>Возможно.

по рукам. Линейкой. Чугуниевой :)

>Меньше, чем сейчас.

больше =)

>>Еще раз повторю - это так _в Си_.

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

У Си++ есть все проблемы Си и еще свои специфические. Так что практически всё, что я сказал о Си (кроме void *), относится и к Си++. Но вот работа с памятью в Си++ не сложнее.

> У Си++ есть все проблемы Си и еще свои специфические. Так что практически всё, что я сказал о Си (кроме void *), относится и к Си++. Но вот работа с памятью в Си++ не сложнее.

Даже проще за счет шаблонов и деструкторов (что позволяет получать вещи типа auto_ptr/shared_ptr).

>__del__ и деструуторы питоне не нужны. И __init__ в каждом классе - тоже не нужен, если подумать.

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

>Но вот работа с памятью в Си++ не сложнее.

в итоге - сложнее. Если угодно - компилятору _труднее_ проверить выверты программерского разума, потому что всякие втбл, конструкторы, перегрузки, виртуальные функции ВНЕЗАПНО превращающиеся в инлайны и прочие прелести языка =)

>Даже проще за счет шаблонов и деструкторов (что позволяет получать вещи типа auto_ptr/shared_ptr).

Вот что действительно раздражает это когда вылезает какой-то "Асиливший Сиплюсплюс" и начинает втирать про auto_ptr/shared_ptr. И эти асилившие не удосуживаются вникнуть в детали. Например, про аллокацию дополнительного объекта со счетчиком ссылок размером в четыре байта, что фрагментирует память так как malloc() расчитан на аллокацию блоков по несколько KB. Или про работу с тредами - ведь инкрементировать/декрементировать счетчик ссылок надо с помощью interlocked increment/interlocked decrement. И при этом как-то обмениваться этими shared_ptr с однотредовым бэкэндом где interlocked функции - это лишний оверхед.

>> __del__ и деструуторы питоне не нужны. И __init__ в каждом классе - тоже не нужен, если подумать.

> да и питон не нужен. если подумать, конечно.

Это у нас так преподаватель по С++ говорит, а он конечно же заблуждается %)

> начинает втирать про auto_ptr/shared_ptr. И эти асилившие не удосуживаются вникнуть в детали.

То, что ты в разговоре о "auto_ptr/shared_ptr" жалуешься исключительно на счетчик ссылок и фрагментацю, показательно.

>>Даже проще за счет шаблонов и деструкторов (что позволяет получать вещи типа auto_ptr/shared_ptr).

>Вот что действительно раздражает это когда вылезает какой-то "Асиливший Сиплюсплюс" и начинает втирать про auto_ptr/shared_ptr. И эти асилившие не удосуживаются вникнуть в детали.

Да, я такой! :)

> Например, про аллокацию дополнительного объекта со счетчиком ссылок размером в четыре байта, что фрагментирует память так как malloc() расчитан на аллокацию блоков по несколько KB.

Использование собственных аллокаторов в приложении не спасает отца русской демократии?

Если мне не изменяет память, в Linux-ах уже давно в качестве штатного используется dlmalloc, который имеет отдельный алгоритм распределения объектов меньше 64 байт размером.

А если вам так жалко лишних 4-х байт, то ведь шаблоны в C++ позволяют реализовывать вещи типа intrusive_ptr из того же Boost-а.

> Или про работу с тредами - ведь инкрементировать/декрементировать счетчик ссылок надо с помощью interlocked increment/interlocked decrement. И при этом как-то обмениваться этими shared_ptr с однотредовым бэкэндом где interlocked функции - это лишний оверхед.

А вы посмотрите на ACE_Refcounted_Auto_Ptr и макрос ACE_SYNCH_MUTEX для случая, когда приложение компилируется под однопоточный режим. Опять же ACE_Refcounter_Auto_Ptr построен на C++ных шаблонах.

>Я бы сказал что конструкторы в С++ по факту ненужны.

Оп-ля. Ты опять? Ты много напрограммил на С++, чтобы такое утверждать?

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

и сегфолтов, происходящих раз в месяц, ты тоже огребёшь, как будто не знаешь :)

> Ты много напрограммил на С++, чтобы такое утверждать?

Если много напрограммить на С++, то может появиться мысль, что C++ - велик и могуч, а остальные языки - не нужны. То есть, думать человек в худщем случае совсем перестает >_<

>> питон не нужен. если подумать, конечно.

> Это у нас так преподаватель по С++ говорит, а он конечно же заблуждается %)

Человек, утверждающий, что пятон не нужен, не может заблуждаться.

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

Кирилл Леонидович, перелогиньтесь пожалуйста!

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

А может и не появиться :)

>То есть, думать человек в худщем случае совсем перестает >_< Взрыв мозга бывает от самых разных симптомов, и язык здесь далеко не на первом месте :)

> Если много напрограммить на С++, то может появиться мысль, что C++ - велик и могуч, а остальные языки - не нужны. > А может и не появиться :)

Однако, корреляция отличается от нуля :(

>Видимо, аккуратные девелоперы программируют только в тех областях, где можно программировать аккуратно без приведения типов =))))))

Либо программируют с использованием средств, позволяющих делать аккуратное приведение типов ;)

> Либо программируют с использованием средств, позволяющих делать аккуратное приведение типов ;)

Например?

QueryInterface, boost::variant, boost::any

>Использование собственных аллокаторов в приложении не спасает отца русской демократии?

Да, садишься за код и начинаешь городить инфраструктуру проекта. Через неделю обнаруживаешь что в плане собственно функционала еще и конь не валялся. Еще через неделю плюешь, сносишь все и пишешь тупо через виртуальные функции и downcasting. Правда с некоторых пор я начал сразу писать на C89 - кариеса меньше.

>Если мне не изменяет память, в Linux-ах уже давно в качестве штатного используется dlmalloc, который имеет отдельный алгоритм распределения объектов меньше 64 байт размером.

Я тупо открыл <memory> в c++ lib и обнаружил что там operator new реализован тупо через malloc().

>А вы посмотрите на ACE_Refcounted_Auto_Ptr и макрос ACE_SYNCH_MUTEX для случая, когда приложение компилируется под однопоточный режим. Опять же ACE_Refcounter_Auto_Ptr построен на C++ных шаблонах.

Проще удалять в том же *.c файле в котором происходит выделение. И не иметь ликов из-за отсутствия исключений. Вообще, неплохо бы SEH из винды перетащить.

>> начинает втирать про auto_ptr/shared_ptr. И эти асилившие не удосуживаются вникнуть в детали.

>То, что ты в разговоре о "auto_ptr/shared_ptr" жалуешься исключительно на счетчик ссылок и фрагментацю, показательно.

Что показательно? Все эти косяки "интеллектуальных указателей" начинают проявляться когда проект уже большой и превратился в помойку. На proof-of-concept'ах килобайт по сорок все работает замечательно.

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

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

О каких косяках ты постоянно говоришь?
Чем не устраивает Loki::SmartPtr?
Или бог запрещает определить BOOST_SP_USE_QUICK_ALLOCATOR?
Если "косяки" представляют из себя прогиб перформанса на "большых проектах" из-за boost::shared_ptr можешь не отвечать, диагноз ясен.

>>То, что ты в разговоре о "auto_ptr/shared_ptr" жалуешься исключительно на счетчик ссылок и фрагментацю, показательно.

>Что показательно?

auto_ptr не использует счетчик ссылок и не ведет к фрагментации - он практически всегда на стеке. Насчет фрагментации от мелких shared_ptr - тоже сомнительно. Всё смешано в одну кучу.

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

Вот именно - когда _уже_ превратился. Не из-за смарпойнтеров же он в нее превратился.

>Чем не устраивает Loki::SmartPtr?

Хорошая кстати вещь. 2 my mind лучшая имплементация. Но тут та же ситуация что и со стрингами - std::string vs std::wstring vs Bicycle1::TMyCoolString Bicycle2::TVasyaPupkinCoolString.

>Если "косяки" представляют из себя прогиб перформанса на "большых проектах" из-за boost::shared_ptr можешь не отвечать, диагноз ясен.

Косяки в том, что как на Си++ не пиши, получается говно. Поэтому лучше не комплексовать и делать говно изначально.

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

Чтобы auto_ptr передать кому-то надо объект клонировать если не хочешь его потерять. То же самое, вид в профиль.

Свой аллокатор пишется во-первых тогда, когда это даст выгоду (а это в 90% проектов не надо, т.к. botteneck-и не там), во-вторых аллокатор, абсолютно не фрагментируемый на фиксированные размеры (а особенно sizeof(void*)) пишется за считанные часы. Проблемы не там ищете.

>>Чем не устраивает Loki::SmartPtr?
> тут та же ситуация что и со стрингами - std::string vs std::wstring
и какая же тут ситуация???

> Косяки в том, что как на Си++ не пиши, получается говно.
Это не проблема смартпойнтеров. Решается заменой говнодела на девелопера.
> Поэтому лучше не комплексовать и делать говно изначально.
Это сразу всё проясняет. Психология непрофессионала.

> Чтобы auto_ptr передать кому-то надо объект клонировать если не хочешь его потерять.
О чём ещё можно говорить после такого высказывания?

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

Естесно, там, где он применим.

> Чтобы auto_ptr передать кому-то надо объект клонировать

ыы

Британские учёные впервые передали auto_ptr овечке Долли.

>> Чтобы auto_ptr передать кому-то надо объект клонировать если не хочешь его потерять.

>О чём ещё можно говорить после такого высказывания?

Кончаем трепологию

class Foo {
std::auto_ptr<Bar> _bar;
public:
...
std::auto_ptr<Bar> getBar() {
return std::auto_ptr<Bar>(_bar->clone());
}
...
};

>> Косяки в том, что как на Си++ не пиши, получается говно.

>Это не проблема смартпойнтеров. Решается заменой говнодела на девелопера.

Под С++ девелоперов не существует. Только говноделы.

>> Поэтому лучше не комплексовать и делать говно изначально.

>Это сразу всё проясняет. Психология непрофессионала.

О блин. Психолахи на ЛОР.

> Чтобы auto_ptr передать кому-то надо объект клонировать если не хочешь его потерять.

std::auto_ptr<Foo> MakeFoo()
{
return std::auto_ptr<Foo>(new Foo());
}

...
std::auto_ptr<Foo> p = MakeFoo();
p->Bar();
...
Вот тебе передача объекта _без_ клонирования и _без_ потери объекта.

> Кончаем трепологию
Кончай смешить людей.

> Под С++ девелоперов не существует. Только говноделы.

Так и напрашивается подпись "Миша, 16 лет".

s/говноделы/мазохисты/

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

>std::auto_ptr<Foo> MakeFoo()
>{
>return std::auto_ptr<Foo>(new Foo());
>}

>Вот тебе передача объекта _без_ клонирования и _без_ потери объекта.

Это неэквивалентный пример. Да и нахрен тут auto_ptr?

Почему не

Foo* foo;
try {
foo = makeFoo();
foo->bar();
...
} finally {
pFoo = null;
}

А наверно потому что Страус такой же даун.

>> Под С++ девелоперов не существует. Только говноделы.

>Так и напрашивается подпись "Миша, 16 лет".

Иди KDE4 разглючивай. Миши 16 лет наваяли, теперь надо доводить.

>Foo* foo;
>try {
>foo = makeFoo();
>foo->bar();
>...
>} finally {
>pFoo = null;
>}

Это на каком языке? O_o

>>Foo* foo; >>try { >>foo = makeFoo(); >>foo->bar(); >>... >>} finally { >>pFoo = null; >>}

>Это на каком языке? O_o

На C++ если бы Страус был вменяем.

UPD: в finally блоке переменная конечно называется не pFoo а foo.

>> Это на каком языке? O_o

> На C++ если бы Страус был вменяем.

Ну-ну. Это был бы такой Си++ со сборкой мусора, finally и null вместо NULL? Ты мог бы просто сказать, что написал на смеси Си++ и Явы, но надо же обязательно пнуть Страуструпа, иначе никрута.

Малыш, у меня нет цели унизить тебя.
Своими постами ты обдристал себя сам по самые помидоры и без моего участия.
Если тебя интересует мера твоего незнания c++, я могу помочь тебе её раскрыть. Если же в тебе просто клокочет подростковая моча, прости, мне это неинтересно. Играй в эту игру со своими сверстниками.

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

> Да и нахрен тут auto_ptr?
А воображение включить?

Bar::Bar()
: m_foo(makeFoo())
{
...
}

>class Foo {
>std::auto_ptr<Bar> _bar;
>public:
>...
>std::auto_ptr<Bar> getBar() {

Зачем здесь getBar возвращает auto_ptr<Bar>? Почему не Bar *?

>Зачем здесь getBar возвращает auto_ptr<Bar>? Почему не Bar *?

Имеет место передача владения. Если возвращаешь auto_ptr<Bar> то одназначно даешь клиенту кода понять что он - владелец того инстанса который возвращает метод getBar(). Он может его отсоединить от auto_ptr и присоединить к shared_ptr. Или вручную с ним работать. Если возвращаешь Bar* то клиенту кода не понатно, что дальше с этим указателем делать - удалять его или нет.

>Это пример, доказывающий ложность твоего высказывания. Чему он должен быть эквивалентен?

Бл*дь, 1) У меня есть memeber field "_bar" охраняемый auto_ptr. 2) Мне надо клиенту кода дать к нему доступ. Ссылки auto_ptr не считает, значит чтобы передать _bar наружу надо сделать clone().

>>Зачем здесь getBar возвращает auto_ptr<Bar>? Почему не Bar *?

>Имеет место передача владения.

Ага, то есть о модели владения вы знаете. Тогда скажите, как вы будете реализовывать эту модель владения в C?

>Малыш, у меня нет цели унизить тебя. Своими постами ты обдристал себя сам по самые помидоры и без моего участия.

PS: Оставь телефончик, ты из Питера как я погляжу. Надо поговорить.

>> Зачем здесь getBar возвращает auto_ptr<Bar>? Почему не Bar *?

> Имеет место передача владения.

Передача _клиенту_ владения указателем на закрытый член класса? o_O Чего-то я в жизни не понимаю.

> o_O Чего-то я в жизни не понимаю.

Ну раз мы продолжаем программировать на C++, значит так и есть. А то ведь по настоящему умные люди уже давно рвут всех на Lisp-е в распределенных вычислительных задачах.

>>> Зачем здесь getBar возвращает auto_ptr<Bar>? Почему не Bar *?

>> Имеет место передача владения.

>Передача _клиенту_ владения указателем на закрытый член класса? o_O Чего-то я в жизни не понимаю.

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

>> o_O Чего-то я в жизни не понимаю.

>Ну раз мы продолжаем программировать на C++, значит так и есть. А то ведь по настоящему умные люди уже давно рвут всех на Lisp-е в распределенных вычислительных задачах.

А я... а я... а я на Питоне умею, вот!

>>Передача _клиенту_ владения указателем на закрытый член класса? o_O Чего-то я в жизни не понимаю.

>Владения копией.

Если и надо передавать клиенту именно _копию_ - то какие претензии к auto_ptr? Не говоря о том, что копию клиенту можно передать как голый указатель - если ему надо, пусть обернет ее в auto_ptr или что-нибудь другое.

>>> o_O Чего-то я в жизни не понимаю.

>>Ну раз мы продолжаем программировать на C++, значит так и есть. А то ведь по настоящему умные люди уже давно рвут всех на Lisp-е в распределенных вычислительных задачах.

>А я... а я... а я на Питоне умею, вот!

Поздно каешься, грешник! :)

>>>Передача _клиенту_ владения указателем на закрытый член класса? o_O Чего-то я в жизни не понимаю.

>>Владения копией.

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

Не, голый указатель на копию -- не кошерно. Пользователь легко может забыть его вообще сохранить где-нибудь. А auto_ptr в этом случае гарантированно прибъет безхозную копию.

Тем более, что auto_ptr в прототипе функции/метода -- это железобетонно задокументированное требование к пользователю принять ответственность за возвращаемый объект. В случае с голым неконстантным указателем это требование, в лучшем случае, будет отражено в документации к методу. Но документацию программисты читают, как правило, после, а не до.

>>>Передача _клиенту_ владения указателем на закрытый член класса? o_O Чего-то я в жизни не понимаю.

>>Владения копией.

>Если и надо передавать клиенту именно _копию_ - то какие претензии к auto_ptr?

Передача копии - это способ оставаться в рамках std, то есть std::auto_ptr и не цепляться к бусту.

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

Нет, в стандартном C++ попрждающий метод должен возвращать auto_ptr.

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

Ладно, пусть. Но ставить необходимость клонирования в getBar в вину auto_ptr - это просто ни в какие ворота.

> в стандартном C++ попрждающий метод должен возвращать auto_ptr.

Это сильно зависит от того, что именно называть "стандартным Си++"

>>Если и надо передавать клиенту именно _копию_ - то какие претензии к auto_ptr?

>Передача копии - это способ оставаться в рамках std, то есть std::auto_ptr и не цепляться к бусту.

Афигеть!

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

>Нет, в стандартном C++ попрждающий метод должен возвращать auto_ptr.

А в каком месте стандарта C++ это утверждается?

И что, разработчики Boost-а, ACE, Qt, Poco, STLSoft, а так же все их пользователи являются злостными нарушителями стандарта C++, когда они создают и используют вещи типа boost::shared_ptr, ACE_Refcounted_Auto_Ptr, Poco::AutoPtr и т.д.?

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

>Ладно, пусть. Но ставить необходимость клонирования в getBar в вину auto_ptr - это просто ни в какие ворота.

Это точно.

Первоначальный вариант
> Чтобы auto_ptr передать кому-то надо объект клонировать если не хочешь его потерять.

То, что ты говоришь сейчас
> 1) У меня есть memeber field "_bar" охраняемый auto_ptr. 2) Мне надо клиенту кода дать к нему доступ.
Некислая разница, не находишь?

> Если возвращаешь Bar* то клиенту кода не понатно, что дальше с этим указателем делать - удалять его или нет.
Если код на с++ вариантов быть не может. Удалять не надо никогда.
При передаче/разделении владения, возвращаться должен смартпойнтер.

Bar& GetBar()
{
return *m_bar;
}

Bar GetBar() const
{
return *m_bar;
}

На выбор. Какие проблемы?

Говори, раз надо.

+1

>> в стандартном C++ попрждающий метод должен возвращать auto_ptr.

>Это сильно зависит от того, что именно называть "стандартным Си++"

Вот это в Ц++ и раздражает больше всего - куча трактатов как правильно писать. Как правильно реализовать operator=? Через идиому swap + temp object. Какой ньанс есть в перегруженных operator-ах типа operator+() ? Возвращать надо по значению. Какой ньанс есть в перегруженных operator-ах типа operator<() ? Они должны быть const-методами чтобы const-aware алгоритмы из stl не переглючило с четерехкилобайтным отчетом об ошибке компиляции. Какой ньюанс есть в auto_ptr? Он не обладает семантикой значений. Как надо копировать объекты с семантикой значений? Через конструктор копирования. Как надо копировать полиморфные объекты? С помощью клонирования. Как избежать забывания перегрузки виртуального метода clone() в производном классе? С помощью помещения виртуального метода doClone() в protected-секцию класса и вывода в public секцию неперегружаемого метода clone() который вызывает виртуальную функцию doClone() и сравнивает типы через RTTI, вызывая Assertion Error при несовпадении.

Etc весь двухтомник Мейрса, двухтомник Саттера, обоюдный высер Саттер + Александресу. Причем рекоммендации все время меняются с критикой в пух и прах предыдущих рекоммендаций. Похоже на советскую традицию нагружать школьников всякой херней типа "переведи 1 Кг из системы Си в систему СГС" с каким-нибудь подвохом. Олимпиады выигрывали всякие аутические индивиды, которые однако в реальном производстве были беспомощными.

> Передача копии - это способ оставаться в рамках std, то есть std::auto_ptr и не цепляться к бусту.
Очень странная самоцель. Разумное объяснение существует?

> Нет, в стандартном C++ попрждающий метод должен возвращать auto_ptr.
Это ещё что за новости??
Возврат по стеку или любого другого смартпойнтера компилятор не скомпилирует?

> это в Ц++ и раздражает больше всего - куча трактатов как правильно писать. Как [...] Какой [...]

Ну да, всё так. Си++ - сложный (переусложненный) язык, с этим кто-то спорит? Но речь шла об auto_ptr и shared_ptr.

А то, о чем ты говоришь, достаточно логично, если знать о том, как всё реализуется. Пойми это, и не надо будет зубрить частности (если тебе это еще нужно, конечно).

> в реальном производстве

Такое впечатление, что ты выгорел на каком-то запущенном Си++-проекте.

P.S. "нюанс", без "ь".

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

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

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

Вам просто повезло.

PS. C++ далеко не идеальный язык и я бы с удовольствием сменил бы его на что-нибудь более удобное, но временами конкурентов у него действительно нет.

> Как правильно реализовать operator=? Через идиому swap + temp object.
Далеко не всегда, но такой приём есть. Можно посчитать за нюанс.

> Какой ньанс есть в перегруженных operator-ах типа operator+()? Возвращать надо по значению.
Это не нюанс, это основы языка. Если ты про оператор сложения, то непонятно как ещё, кроме как по значению? Если ты про постинкремент, то это снова не нюанс, а сама его суть.

> Какой ньанс есть в перегруженных operator-ах типа operator<() ? Они должны быть const-методами чтобы const-aware алгоритмы из stl не переглючило с четерехкилобайтным отчетом об ошибке компиляции.
Это не нюанс, это основы языка. Методы не меняющие состояния объекта должны быть объявлены как константные.
> Какой ньюанс есть в auto_ptr? Он не обладает семантикой значений.
А должен? _Таких_ нюансов море - навскидку, он ещё парсить регэкспы не умеет.
> Как надо копировать объекты с семантикой значений? Через конструктор копирования. Как надо копировать полиморфные объекты? С помощью клонирования.
Это тоже основы языка. Что тебя тут удивляет? Невозможность создать копию объекта неизвестного класса?
> Как избежать забывания перегрузки виртуального метода clone() в производном классе?
[бред поскипан]
Надеюсь, это завуалированный первоапрельский розыгрыш?
Если нет, то ататат и смотреть в сторону чисто виртуальных функций.

Мда... А ведь это азы. Что уж тогда говорить о нюансах.

> дети часто удивляются, отчего [...]

Да, дети многого не понимают - на то они и дети.

> как-то не заметил ни одной области, в которой C++ был бы адекватным выбором. конечно, если разработчики знают ещё что-то, а не только C++.

А ты знаешь Си++?

> 10 лет занимаясь программированием профессионально (и системным, и прикладным) как-то не заметил ни одной области, в которой C++ был бы адекватным выбором.
"А я голой жопой ежей давил".

>Какой ньанс есть в перегруженных operator-ах типа operator<() ? Они должны быть const-методами чтобы const-aware алгоритмы из stl не переглючило с четерехкилобайтным отчетом об ошибке компиляции.

Какой нахрен "нюанс"?! Такие методы должны быть const просто by design! Только не говори мне, что ты объявляешь методы как const только когда что-то явно требует этого (как в приведённом тобой случае).... =\

бедняга. ничего, заживёт.

нет, мы всё больше на gw-basic…

>Вам просто повезло.

возможно.

>но временами конкурентов у него действительно нет.

честно говоря, вижу только одно условие для этого: передали нечто, уже написаное на C++, которое надо поддерживать и развивать.

о, нет, наврал. ещё есть: идиот-заказчик оговаривает в ТЗ конкретный язык, а не функциональность.

>>но временами конкурентов у него действительно нет.

>честно говоря, вижу только одно условие для этого: передали нечто, уже написаное на C++, которое надо поддерживать и развивать.

>о, нет, наврал. ещё есть: идиот-заказчик оговаривает в ТЗ конкретный язык, а не функциональность.

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

А, например, софт для вот такого дизеля -- http://www.research.att.com/~bs/abstraction-and-machine.pdf -- вы бы на чем делали? На plain C?

Не завидуй, тебя, может, тоже вылечат.

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

тут что-то одно лишнее, имо. впрочем, Oberon прекрасно справится.

>А так же работать в условиях сжатых сроков, небольших команд и не резиновых бюджетов.

вот как раз в таких условиях первым же решением было слить C++ в помойку.

>А, например, софт для вот такого дизеля — http://www.research.att.com/~bs/abstraction-and-machine.pdf — вы бы на чем делали? На plain C?

на Oberon-2. возможно, с допиливаниями в виде UNTAGED POINTERS и C как back-end'ом.

> Oberon прекрасно справится.

O_O ты не Irsi часом?

>>А, например, софт для вот такого дизеля — http://www.research.att.com/~bs/abstraction-and-machine.pdf
>> вы бы на чем делали? На plain C? 

>на Oberon-2. возможно, с допиливаниями в виде UNTAGED POINTERS и C как back-end'ом.

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

А как на счет реализации арифметики, которую в C++ реализации сделали на шаблонах?
В Oberon-е бы все ручками делали? Вроде:

sl := FixPoint16.Mul(UnsigRelSpeed,FuelIndex);
IntLoad := FixPoint16.Mul(sl,
  FixPoint16.Add(PointSevenFive,
    FixPoint16.Mul(sl,
      FixPoint16.Sub(PointFiveFour,
        FixPoint16.Mul(PointTwoSeven,sl)
      )
    )
  )
) ...

>> Как избежать забывания перегрузки виртуального метода clone() в производном классе?

>[бред поскипан] Надеюсь, это завуалированный первоапрельский розыгрыш? Если нет, то ататат и смотреть в сторону чисто виртуальных функций.

Base : public Cloneable<Base> -> Derived1 -> Derived2

Если в Derived2 забыли перегрузить clone(), то при клонировании Derived2 будет вызываться clone() от Derived1, который будет возвращать инстанс Derived1. Читать вообще умеешь?

>> Передача копии - это способ оставаться в рамках std, то есть std::auto_ptr и не цепляться к бусту.

>Очень странная самоцель. Разумное объяснение существует?

Было впадлу собирать буст под MSVC 6. Так все проекты и выросли из MSVC 4-5-6 без супа-пупа-дупа фичей стандартного С++. В мире GNU если было и лучше, то ненамного. Торвальдсу вон g++ нехватило. Может оно и к лучшему.

>> Нет, в стандартном C++ порождающий метод должен возвращать auto_ptr.

>Это ещё что за новости??

Я сказал.

> Base : public Cloneable<Base> -> Derived1 -> Derived2
> Читать вообще умеешь?
Ну провафлил, бывает. Под впечатлением от предыдущих "нюансов", не иначе.
По существу сходу ничего не скажу, никогда не сталкивался с необходимостью в Clone.
Итого: два "нюанса" из пяти - не бред. Всё равно показательно.

> Было впадлу собирать буст под MSVC 6
Что само по себе напрашивается на аплодисменты.
Loki собирать тоже было впадлу?
В конце концов всегда есть возможность завести свой велосипед (любой степени заимствования).
Если, конечно, не впадлу.

>>> Нет, в стандартном C++ порождающий метод должен возвращать auto_ptr.
>> Это ещё что за новости??
> Я сказал.
"Поздравляю вас, гражданин, соврамши"

какая из букв в слове mirage нечитабельна? O_o

> какая из букв в слове mirage нечитабельна? O_o

Это ответ "да" или "нет"?

P.S. "Леди Винтер, графиня де ля Фер, леди Кларик" (с) ;)

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

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

>А как на счет реализации арифметики, которую в C++ реализации сделали на шаблонах?

кто-то выше говорил про экономию памяти? O_o

>В Oberon-е бы все ручками делали?

что, внешние препроцессоры религия запретила — на самый крайний случай? хотя это глупо и ненужно, на самом деле. и вложеность такая не нужна, отлично заводятся временные переменные, которые оптимизатор сам выкидывает. получаются вполне нормально читаемые строки. IMPORT FixPoint16 := FP16; и так далее. и всю эту дребедень компилятор спокойно заинлайнит.

да не стоит так за меня переживать, право же…

нужно, наверное, очень много пить в честь 1-го апреля, чтобы прочитать «mirage» как «irsi».

> нужно, наверное, очень много пить в честь 1-го апреля, чтобы прочитать «mirage» как «irsi».

Не-а, нужно увидеть Irsi в l-t, рекламирующим Оберон.

>> Было впадлу собирать буст под MSVC 6 >Что само по себе напрашивается на аплодисменты.

А ты ее собирал под MSVC 6? В stlport хотя бы потрудились сделать nmake скрипт. Разбираться в связке чей-то непонятный jam + ms cl + ms линкер действительно впадлу, тем более что овчинка выделки не стоит - MSVC 6 плохо поддерживал т.н Стандарт, так что трахаться с бесконечными воркараундами в бусте желания не было.

>Loki собирать тоже было впадлу?

loki? под msvc 6 ? попробуй.

ну так а я тут при чём? я вообще Оберон не упоминал, пока меня не спросили, на чём бы я стал писать. спросили — ответил. точно так же там могло оказаться bit scheme, например, или forth. просто я выбрал нечто более близкое к C/C++, иначе совсем нечестно. %-)

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

а за удаление камента в новостях скор снимают? мне ещё 30 поинтов до нуля скинуть надо. ну, на всякий случай проверим: я охуительно рад, да.

> loki? под msvc 6 ? попробуй.
Я использовал Loki под msvc6 в продакшене ещё 4 года назад.
Перед этим, естесно, попробовал.
А что, есть проблемы?

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

>А что, есть проблемы?

Например, отсутствие partial template specialization и template template classes.

>Я использовал Loki под msvc6 в продакшене ещё 4 года назад.

Это хуже малолетнего фанатства.

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

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

Сильно пришлось бы постараться, чтобы повыше получилось, однако http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=ooc&...

>>А как на счет реализации арифметики, которую в C++ реализации сделали на шаблонах?

>кто-то выше говорил про экономию памяти? O_o

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

>>В Oberon-е бы все ручками делали?

>что, внешние препроцессоры религия запретила — на самый крайний случай? хотя это глупо и ненужно, на самом деле. и вложеность такая не нужна, отлично заводятся временные переменные, которые оптимизатор сам выкидывает. получаются вполне нормально читаемые строки. IMPORT FixPoint16 := FP16; и так далее. и всю эту дребедень компилятор спокойно заинлайнит.

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

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

> отсутствие partial template specialization и template template classes.
С танцами, я так понимаю, тоже не всё гладко?

> Это хуже малолетнего фанатства.
От тебя это действительно смешно слышать.

>Ну раз мы продолжаем программировать на C++, значит так и есть. А то ведь по настоящему умные люди уже давно рвут всех на Lisp-е в распределенных вычислительных задачах.

браво :)

>почему встроенное ПО на C++ пишут все, кому не лень

мне это, кстати, тоже непонятно

>Если код на с++ вариантов быть не может. Удалять не надо никогда.

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

Bar& GetBar()
{
return *m_bar;
}

Bar GetBar() const
{
return *m_bar;
}

Бугагага. Это твой код? Возвращение по ссылке рассматривать не будем,
т.к ни один Ц++ фэн не знает точно когда использовать ссылку, а когда
указатель. По мне так ссылки нужны только чтобы передать параметр по const-ссылке или чтобы вернуть результат operator[] или что-то еще
для реализации семантики значений.

Ну да ладно. Второй вариант: совершенно очевидно что Bar это
полиморфный объект, так как он лежит в куче и доступен через указатель
Теперь вопрос: как ты полиморфный объект
собираешься вернуть *по значению* ? Произойдет срезка. loki он
использовал в продакшене на msvc6, бугагага.

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

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

> Разберитесь между собой сами.

Уже.

>> 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*

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

Я демократичен, и отвечаю любому идиоту который лезет в дискуссию. Возможно, это глупо.

Вернулся из ПТУ?
Другого ответа я и не ожидал.

Мальчик, ты думаешь у взрослых дядек стрелки такие же смешные, как у твоей гопы?
Ты серьёзно думаешь, что я буду реально заморачиваться с каждым младенцем, обсыпавшим меня песочком из ведёрка?
Впрочем, ты-то как раз так и думаешь. Нет, маленький, я с детьми не воюю. Смело дрищи против ветра и дальше.

Уже подменил в Spirit recursive descent на LALR без изменений в пользовательском коде? Ещё нет? Тогда дуй в песочницу к другим деткам и не понтуйся, сиплюсплюсокодерящее ничтожество.

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

gpg значит гопнег?

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

Ну да, дуэли - это полезный инструмент, зря забытый. Приучало фильтровать базар.

А, клоун номер один вернулся!
> Обломаешься, ламерок. Поскольку там из этого ущербного подобия EBNF строится recursive descent parser, а мне, прикинь вот, непременно GLR нужен.
Ты не поверишь, ничуть не обломался. Я же Предводитель Телепатов Северного Полушария и сразу же понял, что тебе "непременно GLR нужен".

> Уже подменил в Spirit recursive descent на LALR без изменений в пользовательском коде?
А обещал? Это у тебя вещества или задержка в развитии?

Да, понимаешь ли, барашек, EBNF - это абстракция. То есть, пользователю должно быть по хрен, как оно реализуется, и надо иметь возможность реализацию полностью подменить, никак пользователя не задевая. Если это средствами быдлоязыка сделать нельзя, то говно твой быдлоязык, и средств для реализации высокоуровневых абстракций твой дебильный язычишко не предоставляет. Просто по определению того, что такое абстракция.

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

>Мальчик, ты думаешь у взрослых дядек стрелки такие же смешные, как у твоей гопы?
gpg значит гопнег?
Такая специальная дедукция для альтернативно одарённых?


> Ну да, дуэли - это полезный инструмент, зря забытый. Приучало фильтровать базар.
Хвалила собака палку.

Обещал, ничтожество, обещал. Ты же тявкнуло что-то там, что твой убогий быдлоязычок позволяет формулировать абстракции высокого уровня.

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

Твой источник вдохновенного бреда иссякает. Иди ещё раз затянись, ты становишься мне неинтересен.

Ну, всё ясно, ущербному никчёмному быдлокоредишке нечего возразить. Усрался гадёныш на тему абстракций, чего собственно и следовало ожидать. Будет теперь играть в психоаналитика, развивая тему "почему меня, гадёныша, называют гадёнышем? Унизить хотят, самоутвердиться? Ведь не может же быть такого, что я и в самом деле гадёныш!". Извини конечно, гадёнышь, но очень даже может - ты гадёныш объективно, и я вынужден тебе об этом факте сообщить, поскольку дальнейшее твоё неведение по данному вопросу провоцирует тебя на некорректное поведение.

Эк тебя несёт. Ты ведь тот самый анонимус, который говорил про неадекватность? С чего бы это?
Хорошо, что бешенство по проводам не передаётся.
Тебя хоть подотпустило в результате? (Ну, вдруг...)
Насчёт моего некорректного поведения можешь не бояться: выставить тебя дураком так, как выставляешь себя ты сам надо сильно постараться. А мне лень. Так что давай и дальше сам.
Аплодисменты!!!

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

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

Нищий плакал, извинялся
Жопу пальцем затыкал.
Но понос не унимался
и сквозь пальцы протекал.

Как же я буду тебе что-то доказывать, если ты контуженный на всю голову?
Меня ещё посадят за издевательство над душевнобольным.
Ты, кстати, не из дурки пишешь? Попроси, чтоб поменяли успокоительное, старое уже не действует.
Расскажи лучше про свою жизнь, как кормят, чем колют. Какой диагноз? Шансы есть?

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

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

Ключевой момен я выделил. И подчеркивал его неоднократно.

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

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

Нда... Продолжай ругать C++, это гораздо проще, чем научиться его использовать.

>на самом деле «знание языков» подразумевает прежде всего знание парадигм, лежащих в их основе, а не ньюансы синтаксиса, которые дело мелкое и наживное.

Конечно-конечно. А потом плодятся такие "знающие", для которых константный метод --- всего лишь "нюанс синтаксиса".... =\

Зато понтами за версту несёт "я знаю то, я знаю сё, я не зациклен на C++/ООП/Win-only/x86-only...."

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

А где ты тут людей увидел? Я только смешные буковки на экране вижу =)

Чёрт, спалился

молодец, возьми с полки отравленый кренодж.

Может, креподж? Откуда же это? Не там ли приветственная речь вождей начиналась с "Я ненавижу тебя, %username%"? Что-то фантастическое...
Злой ты. "А папа прав".

>Не там ли приветственная речь вождей начиналась с «Я ненавижу тебя, %username%»? Что-то фантастическое…

угу. Dethworld series #2: The Ethical Engineer by Harry Harrison. в моём переводе было «кренодж», оригинал не смотрел. надо будет прояснить, ибо не в первый раз вижу «п».

>Злой ты.

я не злой, я охрененный пророк, в своём посте я именно такую реакцию и предсказал. не посылать же наЎ теперь?

Зачем же сразу посылать?
Разве он не прав?
Описанное явление имеет место быть, достаточно отлистать несколько постов назад.

так потому и не послал, что в принципе прав.

зыж надо доделать к скрипту переключатель flat/threaded. %-)

][ватит пукать в лужу