Вышел Boost 1.35

>Если бы C++ был дерьмом вы бы этого boost:: даже не увидели бы :-D

да? А пахнет так же

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

по выходу C++0x авторам (или их приемникам) придётся переписать половину boost'а. а вторую половину - выкинуть

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

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

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

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

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

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

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

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

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

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

// wbr

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

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

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

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

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

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

TurboVision рулит

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

system-config-*, gajim

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

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

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

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

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

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

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

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

> GIL (Generic Image Library) - библиотека для работы с изображениями;

Адобовский код, кстати :)

> одна из самых интересных библиотек там - asio

Угу, честных людей вводят в заблуждение :)

http://en.wikipedia.org/wiki/Audio_Stream_Input/Output

> лучший С++ реально нужен и следующий стандарт всех проблем не решает...

Лучший C++ - это CLOS

> Угу, честных людей вводят в заблуждение :)

> http://en.wikipedia.org/wiki/Audio_Stream_Input/Output

Умные люди, услышал про asio в контексте boost'а, пойдут читать про asio на сайт boost. Плане networking'а для C++ asio - вещь очень даже замечательная. А главное, удобная в практическом применении.

>Лучший C++ - это CLOS

это провокация :)

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

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

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

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

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

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

> это провокация :)

Это не провокация, это наблюдение. Причём, не только моё.

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

O_O

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

O_X

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

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

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

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

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

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

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

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

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

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

>Это не провокация, это наблюдение. Причём, не только моё

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

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

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

Не для меня.

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

> и?

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

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

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

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

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

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

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

эти четыре буквы вызывают у плюсокодеров истерику, сопровождающуюся повышенным слюноотделением? =)

> упоминание CLOS в треде про C++ - чистой воды провокация.

Стоны сиплюсплюсников о том, как сильно они хотят иметь CLOS в C++, и, между тем, яростное отрицание ими самого CLOS - это чистой воды фанатизм с примесью идиотизма.

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

>O_O

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

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

>O_X

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

> Стоны сиплюсплюсников о том, как сильно они хотят иметь CLOS в C++

В этом треде о CLOS стонешь только ты.

>Не для меня.

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

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

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

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

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

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

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

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

>>O_O

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

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

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

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

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

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

>эти четыре буквы вызывают у плюсокодеров истерику, сопровождающуюся повышенным слюноотделением? =)

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

> В этом треде о CLOS стонешь только ты.

Никто не стонет. Я просто заметил, что смысла в замене плюсов новым модным языком нет. Замена уже 20 лет назад была. Если в C++ на данный момент смысл всё ещё есть (главным образом, очень большой legacy), то в D нужды точно нет. Инфрастуктуры для промышленной разработки нет, библиотек толком нет, и вообще особо смысла нет в занятии крохотной ниши между C++ и Java.

>Стоны сиплюсплюсников о том, как сильно они хотят иметь CLOS в C++, и, между тем, яростное отрицание ими самого CLOS - это чистой воды фанатизм с примесью идиотизма.

пруфлинк или идиотом отныне зарекомендуешь себя ты

> В этом треде о CLOS стонешь только ты.

Interlib?

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

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

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

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

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

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

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

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

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

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

>> Стоны сиплюсплюсников о том, как сильно они хотят иметь CLOS в C++, и, между тем, яростное отрицание ими самого CLOS - это чистой воды фанатизм с примесью идиотизма.

> пруфлинк или идиотом отныне зарекомендуешь себя ты

www.intelib.org

> Interlib?

www.intelib.org, опечатался.

>Никто не стонет. Я просто заметил, что смысла в замене плюсов новым модным языком нет. Замена уже 20 лет назад была. Если в C++ на данный момент смысл всё ещё есть (главным образом, очень большой legacy), то в D нужды точно нет. Инфрастуктуры для промышленной разработки нет, библиотек толком нет, и вообще особо смысла нет в занятии крохотной ниши между C++ и Java.

аналитик с ЛОРа ? может ещё и факты какие-нибудь приведёшь ?

> пруфлинк или идиотом отныне зарекомендуешь себя ты

Да можешь сразу нажать кнопку "игнорировать", что мне с того? :)

Ну вот вы тут как дети радуетесь новому бусту, ждёте C++0x, в котором появится ещё чуть-чуть того, что давно есть в CLOS, но при упоминании CLOS ты лично обострился первым.

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

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

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

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

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

> аналитик с ЛОРа ?

Да, у меня есть своя точка зрения.

> может ещё и факты какие-нибудь приведёшь ?

Давай пойдём псевдонаучным методом "от противного"?

>www.intelib.org

не то. стонов нету :) за всё время подписки на comp.lang.c++.moderated я про это дело не слышал ни разу. туда же можно было бы и prop (cs.nyu.edu/leunga/www/prop.html) и felix (http://felix.sourceforge.net/) докинуть - и что, о ML-подобном синтаксисе C++-программисты тоже стонут что ли ? не аргумент, нет...

>Давай пойдём псевдонаучным методом "от противного"?

давай, я не против :)

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

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

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

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

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

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

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

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

> www.intelib.org

Прикольная либа. Но причем тут CLOS? Насколько я понял, Intelib реализует Схему, а не CL.

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

главная из которых это то, что реализация ООП в большинстве языков (особенно компилируемых) сильно кастрированная.

>Да можешь сразу нажать кнопку "игнорировать", что мне с того? :)

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

>Ну вот вы тут как дети радуетесь новому бусту, ждёте C++0x, в котором появится ещё чуть-чуть того, что давно есть в CLOS, но при упоминании CLOS ты лично обострился первым.

то же самое можно сказать про Java, C#, Python, Ruby, и ещё десяток ЯП - только вот зачем ? хочешь пообсуждать прелести CLOS - создавай в development тему "CLOS как основа всего сущего" и обсуждай на здоровье. здесь его упоминание служит исключительно разжиганию флейма. особенно с заявами насчёт "идиотизма"

>главная из которых это то, что реализация ООП в большинстве языков (особенно компилируемых) сильно кастрированная

а я разве с этим спорю ? ещё и как кастрированная...

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

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

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

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

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

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

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

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

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

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

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

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

И лицензия у них приятная, без ГНУтых закидонов.

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

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