Планы по выпуску GTK+ версии 3

Никто не мешат к жабке написать нативный метод на асме;)

>Приходится городить static if (is(T : struct)) { ...

Это я так думаю не хуже частичных специализаций template member function шаблонным параметром Loki::Int2Type<isPolymorfic>.

> Никто не мешат к жабке написать нативный метод на асме;)

А у жабопрограммиста на него профессионализма хватит? Там ведь злые Указатели :)

Указатели - это Ъ!

> Указатели - это Ъ!

Указатели -- это !

> Может быть, Страуструпу следовало оставить value-семантику для struct, и сделать классы reference. Интересно, он как-то обосновал свои решения?

Уж не знаю как бы это обовновал Страуструп, но многих бы это лишило возможности использовать один и тот же алгоритм для работы с double и классом MyCoolDoubleWithInacuracyCouting.

>> Никто не мешат к жабке написать нативный метод на асме;)

>А у жабопрограммиста на него профессионализма хватит? Там ведь злые Указатели :)

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

>Уж не знаю как бы это обовновал Страуструп, но многих бы это лишило возможности использовать один и тот же алгоритм для работы с double и классом MyCoolDoubleWithInacuracyCouting.

Я как-то сталкивался с необходимостью отказаться от double в пользу custom типа и идея сделать это классическим С++ способом провалилась из-за перформанса. Пришлось на массивах делать.

> Аккуратно работать с указателями это как "не курить в постели", "прятать от детей спички" или "выключать бытовые приборы". Однако в 10-милионном городе среднее количество пожаров это почти константа. Тебе как математику это должно быть ясно.

Я не понял, что мне должно быть ясно :)

> Я как-то сталкивался с необходимостью отказаться от double в пользу custom типа и идея сделать это классическим С++ способом провалилась из-за перформанса. Пришлось на массивах делать.

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

>> Аккуратно работать с указателями это как "не курить в постели", "прятать от детей спички" или "выключать бытовые приборы". Однако в 10-милионном городе среднее количество пожаров это почти константа. Тебе как математику это должно быть ясно.

>Я не понял, что мне должно быть ясно :)

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

>> Я как-то сталкивался с необходимостью отказаться от double в пользу custom типа и идея сделать это классическим С++ способом провалилась из-за перформанса. Пришлось на массивах делать.

>Мне, как математику, переход от частного к общему совершенно противен.

Если перформанс важен, то "общих" решений нет. А если перформанс не важен то можно воспользоваться числами с бесконечной точностью из Common Lisp.

> Абсолютно без издёвок предложил. Потому что сам с долей скепсиса читал читать ("ну и что там такого грандиозного придумать могли?"), и постепенно офигевал.

Почитайте CLIM и совсем поплохеет :-)

А какие есть свободные реализации CLIM, которые более-менее полностью его реализуют и не глючат направо и налево?

> Тогда я скажу по плохому - никакой элитарности в прямой работе с памятью нет. Любой человек с средним техническим может это делать.

Сможет-то любой. Вопрос только в том, с какой попытки это станет работать так как надо :)

> Если перформанс важен, то "общих" решений нет. А если перформанс не важен то можно воспользоваться числами с бесконечной точностью из Common Lisp.

А там уже sin() с бесконечной точностью появился?

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

>> Если перформанс важен, то "общих" решений нет. А если перформанс не важен то можно воспользоваться числами с бесконечной точностью из Common Lisp.

>А там уже sin() с бесконечной точностью появился?

Как в лиспе не вычислять сразу выражение, а сохранить его в аналитическом виде чтобы потом повторять вычисления неограниченное количество раз с разной точностью я себе представляю. Возможно даже упростить выражение, но это конечно сложнее. В С++ это - убийственная затея. По любому для этого нужны будут виртуальные функции. Делать ли при этом перегруженные операторы виртуальными? И какой будет при этом синтаксис?

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

Делаешь шаблонную функцию, а потом вызываешь её с float, double, CoolDouble... Или я не понял задачи?

> Делать ли при этом перегруженные операторы виртуальными? И какой будет при этом синтаксис?

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

> Вопрос только в том, с какой попытки это станет работать так как надо :)

Мой опыт показывает, что как надо в 100% никто не умеет этого делать. Только GC умеет.

И то не всегда. Баги в GenGC SBCL'ном до сих пор находят.

>> Мой опыт показывает, что как надо в 100% никто не умеет этого делать. Только GC умеет.

> И то не всегда. Баги в GenGC SBCL'ном до сих пор находят.

Вывод: мы все умрёоооооооом! :)

>>> Мой опыт показывает, что как надо в 100% никто не умеет этого делать. Только GC умеет.

>> И то не всегда. Баги в GenGC SBCL'ном до сих пор находят.

>Вывод: мы все умрёоооооооом! :)

Аминь, брат. Мы занимаемся ремеслом, которое в приницпе не по силам человеку %)

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

>Делаешь шаблонную функцию, а потом вызываешь её с float, double, CoolDouble... Или я не понял задачи?

Не, я про то что в лиспе sin(x) можно не вычислять, а сохранить в аналитическом виде. Что-то типа '(sin x)

> Аминь, брат. Мы занимаемся ремеслом, которое в приницпе не по силам человеку %)

Интеллектуальный оккультизм? :)

>> Делаешь шаблонную функцию, а потом вызываешь её с float, double, CoolDouble... Или я не понял задачи?

> Не, я про то что в лиспе sin(x) можно не вычислять, а сохранить в аналитическом виде. Что-то типа '(sin x)

Лисп -- это лисп, у него возможности пошире. Ноя всё равно так и не понял, в каком контексте это должно быть применено, чтобы там же нельзя было использовать (м.б. шаблонную) функцию.

>> Аминь, брат. Мы занимаемся ремеслом, которое в приницпе не по силам человеку %)

> Интеллектуальный оккультизм? :)

Ну так вас почитаешь - во всякое поверишь :D

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

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

Хотя после того как я сегодня увидел рейстрейсер на шаблонах языка D который вместо результирующей бинари дает отрендеренную сцену, я не настолько скептичен. Возможно, компиляторам скоро понадобится собственный уборщик мусора и коннекшен к БД.

> Возможно, компиляторам скоро понадобится собственный уборщик мусора и коннекшен к БД.

Дык уже: http://en.wikipedia.org/wiki/Nemerle, см. ExecuteReaderLoop

>> Возможно, компиляторам скоро понадобится собственный уборщик мусора и коннекшен к БД.

>Дык уже: http://en.wikipedia.org/wiki/Nemerle, см. ExecuteReaderLoop

Я имею в виду что понадобится коннекшен к базе данных, поскольку не будет хватать ОЗУ для компилирования.

PS: Это все баловство намного более чем наполовину, т.к если для задачи не подходит динамический полиморфизм, то не подходит никакой. Будут в D менее дубовые виртуальные функции типа как Objective C, будет какой-то толк. Иначе это бесполезный derived work от бесполезного былдлоязычка C++.

> Будут в D менее дубовые виртуальные функции типа как Objective C, будет какой-то толк.

Не будет. т.к. на первом месте стоит производительность готовых программ. Где там Obj-C по производительности? 1.7.

> Иначе это бесполезный derived work от бесполезного былдлоязычка C++.

Это derived work, но не от C++.

>Не будет. т.к. на первом месте стоит производительность готовых программ. Где там Obj-C по производительности? 1.7.

Ну и будет тогда куча базовых классов с единственном методом virtual void* sendMessage(Message* msg) = 0. Всяко лучше чем потом думать как же нам добавить метод в корень огромной иерархии.

>> Иначе это бесполезный derived work от бесполезного былдлоязычка C++.

>Это derived work, но не от C++.

А от чего?

Я неправильно выразился. Это derived work, но не _только_ от C++.

Из C++ взяты только шаблоны и то, благодаря Александреску, в D их реализовали более-менее правильно, а не так, как в C++. Конкретно из C++ больше ничего заимствовано не было.

Надо же, какая волнующая тема :)
3 дня ушло, чтобы прочитать.
Никто не знает каков абсолютный рекорд длины треда на ЛОРе?

> Никто не знает каков абсолютный рекорд длины треда на ЛОРе?

В одном треде про "svu vs Alksnis" за полторы тысячи перевалило. Так что мы тут рекорда пока что не поставили. Вливайся :)

>Никто не знает каков абсолютный рекорд длины треда на ЛОРе?

В поиск, приводилась топ-10. Правда, сейчас еще слакварь из новых до неприличных размеров растолстела.

> Никто не знает каков абсолютный рекорд длины треда на ЛОРе?

Абсолютный - ХЗ, но во "Фразе о Лиспе" было больше 8)

>Я неправильно выразился. Это derived work, но не _только_ от C++.

Меня больше интересует не генеалогия D, а все-таки расширения динамического полиморфизма. Вон, Мейерса напимер очень волновало как можно обеспечить полиморфное столкновение двух объектов SpaceObject c методом virtual void collide(SpaceObject* anotherSpaceObject), зависящее от обоих рантаймовых типов сталкивающихся объектов. Написал три заготовки, а потом их раскритиковал и дал домашнее задание довести до ума четвертую заготовку. Александреску попроще: (мордастый румынский) пацан сказал - пацан сделал, но КАК он это сделал...

Взял я конечно провокационный тон, чтобы тебя раззадорить, но одних только virtual функций действительно ИМХО недостаточно. Это спровоцирует индокод с обменом текстовыми коммандами между объектами.

> Это спровоцирует индокод с обменом текстовыми коммандами между объектами.

Раздобыл библиотечку для mutiple dispatch. Вот use-case:

import multipledispatch, std.stdio;

class A {}
class B : A {}

class Foo
{
  void bar(A a1, A a2)
  { writefln("AA"); }

  void bar(A a, B b)
  { writefln("AB"); }
  
  void bar(B a, B b)
  { writefln("BB"); }

  // generates void dispatch(Object,Object)
  // that uses RTTI to call one of the overloads
  // defined above
  mixin MultipleDispatch!("bar", _0, _1);
}

void main()
{
  A a = new A;
  A b = new B;

  auto foo = new Foo;

  foo.dispatch(a, a); // writes AA
  foo.dispatch(a, b); // writes AB
  foo.dispatch(b, b); // writes BB
  
  foo.dispatch(b, a); // throws error
}

Вот реализация и тесты: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&artic
le_id=56018

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

>В одном треде про "svu vs Alksnis" за полторы тысячи перевалило. Так что мы тут рекорда пока что не поставили.

До полутора тысяч осталось-то всего ничего, 64 сообщения. А мы ведь только-только затронули такую волнительную тему, как язык D... ;)

>...Так что мы тут рекорда пока что не поставили. Вливайся :)
не.. я больше читать люблю, чем писать мне как эмбеддеру кажется, что
этот флейм носит умозрительный
характер, имхо. я уже давно все, кроме си забыл. тут просто
фраза мелькнула, что в ВУЗах учат строки на си обрабатывать, я аж
вздрогнул :) до сих пор помню этот ужос. а про плюсы я сразу понял,
что они не для средних умов. единственное, что было интересное, из того,
что давали в институте, это написание компиляторов и интерпретаторов
мат. формул. всякие там стеки Дейкстры или там метод нисходящего
разбора.. эххх, молодость :)

> тут просто фраза мелькнула, что в ВУЗах учат строки на си обрабатывать, я аж вздрогнул :) до сих пор помню этот ужос.

Не такой это и ужас. Но вот то, что самой убойной задачей на C в ВУЗе считается что-то, связанное со строками -- вот это ужас. Ибо для обработки строк есть более другие языки, где и код читабельнее и оступиться сложнее.

вот поэтому и надо давать людям с++ :) но при этом обязательно обьяснить почему сишный подход работы с char* строками лучше

> вот поэтому и надо давать людям с++ :) но при этом обязательно обьяснить почему сишный подход работы с char* строками лучше

Моей параллели, кстати, так никто(кроме меня) и не рассказал про std::string. Зато сколько загибов пальцев было на тему "а вот в сишарпе со строками работать просто"...

А вообще, плюсы для строк тоже страшноваты. Лучше tcl :)

> Не такой это и ужас. Но вот то, что самой убойной задачей на C в ВУЗе считается что-то, связанное со строками -- вот это ужас. Ибо для обработки строк есть более другие языки, где и код читабельнее и оступиться сложнее.

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

> Всегда от умиления слёзы текут, когда вижу, что в суровом продакшене текстовые данные парсят с помощью strchr, strstr, etc или их аналогами в VCL. Вместо примитивного регэкспа люди полнедели пишут два экрана кода, баги в котором регулярно вылезают ещё минимум в течении полгода.

Энтерпрайз, что ж с него взять. В регекспах ведь автодополнения нет, с ним эффективной энтерпрайз-работы не получится :)

>Не такой это и ужас. Но вот то, что самой убойной задачей на C в ВУЗе >считается что-то, связанное со строками-- вот это ужас. >Ибо для обработки строк есть более другие языки, >где и код читабельнее и оступиться сложнее. я, наверное, неудачно выразился. в том и дело, что, для работы со строками есть куча классных инструментов, и это не std::string. тот же перл. а получается, что учат не задачи/проблемы решать, а кнопачки в вижуал студии,мля, нажимать. самый цирк был у нас с численными методами, где проги должны были отчеты в текстовом виде формировать о своей работе. одно из требований было- использование _своей_ библиотеки(убогой и корявой) работы со строками. ну не дурость? вместо 3 строчек на перле вагон какашек за собой таскать... на си можно много классных вещей делать, пусть они и называются грязными хаками, за которые гнобят в т.ч. и виновник данного флейма ) но этому в институте не учат, а учат работе со строками...

>Всегда от умиления слёзы текут, когда вижу, что в суровом продакшене >текстовые данные парсят с помощью strchr, strstr,... именно! жаль нет статистики, какой процент багов приходится на эти "парсеры" самописные. подозреваю, что он большоой

>> Никто не знает каков абсолютный рекорд длины треда на ЛОРе?

>В одном треде про "svu vs Alksnis" за полторы тысячи перевалило. Так что мы тут рекорда пока что не поставили. Вливайся :)

В треде про Алксниса и Поносова украинским нацполом добили до отметки в 3000, после чего svu похвалил участников, констатировал рекорд и закрыл тему.

> В треде про Алксниса и Поносова украинским нацполом добили до отметки в 3000, после чего svu похвалил участников, констатировал рекорд и закрыл тему.

Мда... Мы прям дети в сравнении с ними :)

>> вот поэтому и надо давать людям с++ :) но при этом обязательно обьяснить почему сишный подход работы с char* строками лучше

>Моей параллели, кстати, так никто(кроме меня) и не рассказал про std::string.

std::string появился в стандарте после постинга в c++.moderated о том что "если в С++ в конце концов не появится стандартного класса строк, то на улицах прольется кровь". Но было уже поздно, так как в каждой С++-ном фреймворке был свой стринг. Создается впечатление что Строуструп рожал С++ держа в голове стринг в качестве образцово-показательного примера микроядерности языка.

BTW И Саттер и Александреску считают std::string плохо спроектированным классом с раздутым интерфейсом. И это даже если не трогать уникод.

>> тут просто фраза мелькнула, что в ВУЗах учат строки на си обрабатывать, я аж вздрогнул :) до сих пор помню этот ужос.

>Не такой это и ужас. Но вот то, что самой убойной задачей на C в ВУЗе считается что-то, связанное со строками -- вот это ужас. Ибо для обработки строк есть более другие языки, где и код читабельнее и оступиться сложнее.

А йаъ в ВУЗе осилил компрессию текстовых данных в кусаче на Си. Но писал долго, рисуя попутно массивы чаров на бумаге в клеточку.

> std::string появился в стандарте после постинга в c++.moderated о том что "если в С++ в конце концов не появится стандартного класса строк, то на улицах прольется кровь".

Но было поздно. Зоопарк стринговых классов цветёт и пахнет. И именно поэтому на C++ со строками лучше не работать :)

> А йаъ в ВУЗе осилил компрессию текстовых данных в кусаче на Си. Но писал долго, рисуя попутно массивы чаров на бумаге в клеточку.

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