LINUX.ORG.RU

Qt доступна теперь и под LGPL

 , ,


0

0

Компания Nokia объявила о том, что, начиная с версии 4.5, кросс-платформенная библиотека Qt будет доступна также под лицензией LGPL.

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

Кроме того, станут общедоступными репозитории исходных кодов Qt, сделав процесс разработки библиотеки открытым для сообщества.

Коммерческая лицензия и лицензия GPL также останутся доступными.

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

>>> Подробности

★★★★★

Проверено: Dimez ()
Ответ на: комментарий от mint

> Ты не поверишь, ООП с его краеугольными принципами легко реализуем на ANSI C

Я быдлокодер!

Arceny ★★
()
Ответ на: комментарий от mint

> Ты не поверишь, ООП с его краеугольными принципами легко реализуем на ANSI C

да он при желании и на ассемблере реализуется. видели. ну и что с того?

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от mint

> Ты не поверишь, ООП с его краеугольными принципами легко реализуем на ANSI C

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

x86_64 ★★★
()
Ответ на: комментарий от x86_64

> Только при этом в отличии от С++ часть работы переносится с компилятора на рантайм

Ну-ка поподробнее, что там у тебя в рантайм переводится? Вместо неявной передачи this ты явно пишешь +1 аргумент при передаче параметров. Какие еще отличия будут? Сдается ты говоришь Objective C/реализации ООП в GTK, а не об общем случае. Ну или просто не знаешь C, ООП и как соединить эти две вещи вместе.

anonymous
()
Ответ на: комментарий от anonymous

>> Только при этом в отличии от С++ часть работы переносится с компилятора на рантайм

>Ну-ка поподробнее, что там у тебя в рантайм переводится? Вместо неявной передачи this ты явно пишешь +1 аргумент при передаче параметров. Какие еще отличия будут? Сдается ты говоришь Objective C/реализации ООП в GTK, а не об общем случае. Ну или просто не знаешь C, ООП и как соединить эти две вещи вместе.

Как минимум проверка типуов указателей и их преобразование. Если необходима полная ООП то прицепляется еще туева хуча лишней работы.

x86_64 ★★★
()
Ответ на: комментарий от x86_64

> Как минимум проверка типуов указателей и их преобразование.

Ты вот прямо везде пишешь dynamic_cast чтоли, или все-таки по старике (Derived*)base_ptr? Если первое, то да -- надо проверять в рантайме и то, что плюсовый компилятор генерирует этот код прозрачно для тебя, еще не означает, что этот код в рантайме выполняется за нулевое время. Если же второе -- то это обычный сишный каст, который работает в плюсах точно так же, как и в C: безо всяких проверок (ну за исключением множественного наследования - там значения базового поинтера вычисляется чуть сложнее).

anonymous
()
Ответ на: комментарий от klalafuda

>> Ты не поверишь, ООП с его краеугольными принципами легко реализуем на ANSI C

>да он при желании и на ассемблере реализуется. видели. ну и что с того?

А как в рантайме у С++ - объекта тип можно сменить? Если на Си, можно указатель на vtbl поменять: был например квадрат, одна из размерностей поменялась - стал прямоугольник. У как на т.н "С++ ООП" организовать диспатчинг GUI-сообщений в окна без препроцессора? А как можно генератор парсеров наподобие ANTLR шаблонами забабахать?

Absurd ★★★
()
Ответ на: комментарий от Absurd

> А как в рантайме у С++ - объекта тип можно сменить? Если на Си, можно указатель на vtbl поменять: был например квадрат, одна из размерностей поменялась - стал прямоугольник. У как на т.н "С++ ООП" организовать диспатчинг GUI-сообщений в окна без препроцессора? А как можно генератор парсеров наподобие ANTLR шаблонами забабахать?

вы точно GoF внимательно читали? там есть ответы на большую часть вопросов с примерами :)

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от anonymous

>> Как минимум проверка типуов указателей и их преобразование.

> Ты вот прямо везде пишешь dynamic_cast чтоли, или все-таки по старике (Derived*)base_ptr? Если первое, то да -- надо проверять в рантайме и то, что плюсовый компилятор генерирует этот код прозрачно для тебя, еще не означает, что этот код в рантайме выполняется за нулевое время. Если же второе -- то это обычный сишный каст, который работает в плюсах точно так же, как и в C: безо всяких проверок (ну за исключением множественного наследования - там значения базового поинтера вычисляется чуть сложнее).

Я, вообще то, говорил про реализацию основных принципов ООП который в С без проверки типов не реализовать.

x86_64 ★★★
()
Ответ на: комментарий от klalafuda

>> А как в рантайме у С++ - объекта тип можно сменить? Если на Си, можно указатель на vtbl поменять: был например квадрат, одна из размерностей поменялась - стал прямоугольник. У как на т.н "С++ ООП" организовать диспатчинг GUI-сообщений в окна без препроцессора? А как можно генератор парсеров наподобие ANTLR шаблонами забабахать?

>вы точно GoF внимательно читали? там есть ответы на большую часть вопросов с примерами :)

По поводу превращения квадрата в прямоугольник там ничего внятного напмсано не было - было сказано только что квадрат нельзя наследовать от прямоугольника, так как это делает часть унаследованных функций бессмысленными. То есть правило "is-a" в данном случае не работает: квадрат это не прямоугольник хотя с точки зрения геометрии вроде бы должен им быть. Диспатчинг GUI сообщений на шаблонах тоже будет сложной, хрупкой и медленно компилирующийся хренью. По сравнению с тупым, надежным, сердитым и компилирующимся за один хлоп flex/bison boost::spirit тоже очень конкретно посасывает.

Absurd ★★★
()
Ответ на: комментарий от x86_64

> Я, вообще то, говорил про реализацию основных принципов ООП который в С без проверки типов не реализовать.

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

anonymous
()
Ответ на: комментарий от anonymous

>> Я, вообще то, говорил про реализацию основных принципов ООП который в С без проверки типов не реализовать.

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

Покажите мне хотя бы одну реализацию на С основных принципов ООП без приведения типов рантайм.

x86_64 ★★★
()
Ответ на: комментарий от x86_64

Хм... реквестирую версию Qt 5.0 на D :)
А вообще Нокия правильно сделала, она же железками торгует, поэтому ей выгодно, чтобы под её железки было как можно больше софта. Да и с более открытой моделью разработки получается с одной стороны дешевле, а с другой стороны получается лучшая обратная связь с сообществом (в идеале по крайней мере)

Gorthauer ★★★★★
()
Ответ на: комментарий от x86_64

> Покажите мне хотя бы одну реализацию на С основных принципов ООП без приведения типов рантайм.

извиняюсь - без проверки

x86_64 ★★★
()
Ответ на: комментарий от x86_64

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

>Покажите мне хотя бы одну реализацию на С основных принципов ООП без приведения типов рантайм.

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

Absurd ★★★
()
Ответ на: комментарий от Absurd

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

>> Покажите мне хотя бы одну реализацию на С основных принципов ООП без приведения типов рантайм.

> Есть одно хорошее высказывание: "Если вас не устраивает динамический полиморфизм, то статический вам тоже не поможет".

Это всего лишь высказывание, не являющееся истиной.

x86_64 ★★★
()
Ответ на: комментарий от x86_64

>> Есть одно хорошее высказывание: "Если вас не устраивает динамический полиморфизм, то статический вам тоже не поможет".

>Это всего лишь высказывание, не являющееся истиной.

А код сгенеренный moc стало быть не делает проверок в рантайме?

Absurd ★★★
()
Ответ на: комментарий от x86_64

> Покажите мне хотя бы одну реализацию на С основных принципов ООП без приведения типов рантайм.

Наследование.

struct Base {
  int data;
};

struct Derived {
  struct Base parent;
  int extra_data;
  // инкапсуляция:
  int private_field; // с*ка, не смей изменять это поле на прямое: убью!
};

// невиртуальный метод
void Base_do_something(Base *self) {
  printf ("data = %d\n", self->data;
}

int main()
{
  Derived d = {12,15};
  do_something((Base*)&d);
  return 0;
}

anonymous
()
Ответ на: комментарий от anonymous

> int private_field; // с*ка, не смей изменять это поле на прямое: убью!

Конечно же имелось в виду "напрямую".

anonymous
()
Ответ на: комментарий от Gorthauer

> Хм... реквестирую версию Qt 5.0 на D :)

Биндинг к Qt4 в активной разработке: http://code.google.com/p/qtd/

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

naryl ★★★★★
()
Ответ на: комментарий от anonymous

>int private_field; // с*ка, не смей изменять это поле на прямое: убью!

Можно описание структуры поместить в .c файл, а в .h оставить только предварительную декларацию.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> Диспатчинг GUI сообщений на шаблонах тоже будет сложной, хрупкой и медленно компилирующийся хренью. По сравнению с тупым, надежным, сердитым и компилирующимся за один хлоп flex/bison boost::spirit тоже очень конкретно посасывает.

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

Что мешает использовать препроцессоры и IDL-компиляторы, дополняющие С/С++? Так сделан и flex/bison, и СORBA, и QT, и еще много чего. Да и стандартный препроцессор многое может.

С++ и не претендует на звание "единственно верного языка". Это просто набор расширений С. Одно - для написания ООП кода, другое - для generic кода, третье - набор алгоритмов и контейнеров, и т.д.

Чем плох С++ для своих задач? Т.е. написание "реально кроссплатформенного" кода в стиле ООП, максимально приближенного к "железу"? Все остальное может быть прикручено "поверх" с помощью других инструментов.

anonymous
()
Ответ на: комментарий от anonymous

>Что мешает использовать препроцессоры и IDL-компиляторы, дополняющие С/С++?

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

Absurd ★★★
()
Ответ на: комментарий от anonymous

>struct Base { > int data; >}; > >struct Derived { > struct Base parent; > int extra_data; > // инкапсуляция: > int private_field; // с*ка, не смей изменять это поле на прямое: убью! >}; > >// невиртуальный метод >void Base_do_something(Base *self) { > printf ("data = %d\n", self->data; >} > >int main() >{ > Derived d = {12,15}; > do_something((Base*)&d); > return 0; >}

14G$i)

Там скобка пропущена.

anonymous
()
Ответ на: комментарий от anonymous

>struct Base {
> int data;

>};

>

>struct Derived {

> struct Base parent;

> int extra_data;

> // инкапсуляция:

> int private_field; // с*ка, не смей изменять это поле на прямое: убью!

>};

>

>// невиртуальный метод

>void Base_do_something(Base *self) {

> printf ("data = %d\n", self->data;

>}

>

>int main()

>{

> Derived d = {12,15};

> do_something((Base*)&d);

> return 0;

>}


14G$i)

Там скобка пропущена.

anonymous
()
Ответ на: комментарий от Absurd

> Можно описание структуры поместить в .c файл, а в .h оставить только предварительную декларацию.

Ну, можно как в GTK: public поля в *.h файле, private -- в *.c Но зачем? Меня, например, в свое время такое смутило и я всерьез было подумал, что g_array (или как его там) реаллокейтится каждый раз при добавлении нового элемента).

Я считаю, что культурные программисты обязаны соблюдать культуру программирования, и если написано: "не трожь, с*ка", то культурный программист и не тронет, а вот хакИры... Эти да, поломают всю инкапсуляцию.

anonymous
()
Ответ на: комментарий от anonymous

>> Покажите мне хотя бы одну реализацию на С основных принципов ООП без приведения типов рантайм.

> Наследование.

Жду продолжения. Реализованы не все принципы.

x86_64 ★★★
()
Ответ на: комментарий от Absurd

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

Значит он ошибался. QT же не от хорошей жизни пользуется своим собственным препроцессором. И boost активно пользуется стандартным препроцессором, даже библиотека для него есть.

Зачем подражать лиспу в его безуспешных попытках "делать все"? Для специфичной задачи - специфичный язык.

anonymous
()
Ответ на: комментарий от anonymous

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

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

Мне в последнее время закрадывается подозрение, что для ООП вообще места нет нигде. Данные проще извлекать при помощи SQL, тексты парсить - регэкспами, для rpc - использовать разные midl'ы, итд. Для всего есть более простое и надежное решение чем написание иерархии классов. Единственная проблема - видимость символов, префиксами функций получается слишком топорно.

Absurd ★★★
()
Ответ на: комментарий от alex_custov

>опять в магазин вещества завезли? :)

А что, по твоему С++ хорошо подходит для гуйни чтоли? Что фреймворки С++, что Жава со свингом - страх и ужас.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> А что, по твоему С++ хорошо подходит для гуйни чтоли? Что фреймворки С++, что Жава со свингом - страх и ужас.

Какой у Вас стаж программирования на C++ и в какой области?

GlitchHead
()
Ответ на: комментарий от Absurd

>> опять в магазин вещества завезли? :)

> А что, по твоему С++ хорошо подходит для гуйни чтоли? Что фреймворки С++, что Жава со свингом - страх и ужас.

На страх и ужас нас рать. Главное - что работает. Легко разрабатывается и есть методики рефакторинга.

x86_64 ★★★
()
Ответ на: комментарий от alex_custov

> гуйня в виде Qt - просто сказка. Swing тут и рядом не стоял.

Страшная сказка народов севера? :) Qt красив, не спорю, но писать гуй без замыканий как-то уже неудобно.

gaa ★★
()
Ответ на: комментарий от Absurd

> А что, по твоему С++ хорошо подходит для гуйни чтоли? Что фреймворки С++, что Жава со свингом - страх и ужас.

А по-твоему, ооп --- это только гуйня?

gaa ★★
()
Ответ на: комментарий от x86_64

>> А что, по твоему С++ хорошо подходит для гуйни чтоли? Что фреймворки С++, что Жава со свингом - страх и ужас.
> На страх и ужас нас рать. Главное - что работает. Легко разрабатывается и есть методики рефакторинга.


Ну и пусть, что говно получается, зато писать легко :)

gaa ★★
()
Ответ на: комментарий от GlitchHead

>> А что, по твоему С++ хорошо подходит для гуйни чтоли? Что фреймворки С++, что Жава со свингом - страх и ужас.

>Какой у Вас стаж программирования на C++ и в какой области?

Ну начинал с Watcom 11, обрабатывал слайды с барабанного сканера. Потом - все по мелочи.

Absurd ★★★
()
Ответ на: комментарий от gaa

>>> А что, по твоему С++ хорошо подходит для гуйни чтоли? Что фреймворки С++, что Жава со свингом - страх и ужас.

>> На страх и ужас нас рать. Главное - что работает. Легко разрабатывается и есть методики рефакторинга.

> Ну и пусть, что говно получается, зато писать легко :)

Как ты отличишь одно окошко от другого? Для пользователя по барабану насколько кривой тулкит использован. А результат получается нормальный.

x86_64 ★★★
()
Ответ на: комментарий от x86_64

>> А что, по твоему С++ хорошо подходит для гуйни чтоли? Что фреймворки С++, что Жава со свингом - страх и ужас.

>На страх и ужас нас рать. Главное - что работает. Легко разрабатывается и есть методики рефакторинга.

Ну гуевое окошко это походу машина состояний которая реагирует на события. Чето средств для хорошего, добротного описания машин состояний в С++&Co я не нашел. Лесенки switch-ей и if-ов это несерьезно. State Design Pattern - это еще более сомнительно: мне что, по классу на кждое возможное состояние окна писать?

Absurd ★★★
()
Ответ на: комментарий от x86_64

> Как ты отличишь одно окошко от другого? Для пользователя по барабану насколько кривой тулкит использован. А результат получается нормальный.

Аргумент корректный. Но не применим к куте из-за тормознутости и ресурсоёмкости последней.

anonymous
()
Ответ на: комментарий от anonymous

>> Как ты отличишь одно окошко от другого? Для пользователя по барабану насколько кривой тулкит использован. А результат получается нормальный.

> Аргумент корректный. Но не применим к куте из-за тормознутости и ресурсоёмкости последней.

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

x86_64 ★★★
()
Ответ на: комментарий от anonymous

> Аргумент корректный. Но не применим к куте из-за тормознутости и ресурсоёмкости последней.

Qt в разы быстрее Gtk. См. тесты.

GlitchHead
()
Ответ на: комментарий от GlitchHead

>Жава со свингом - страх и ужас. Зато хоть в одной технологической цепочке во всей java со всеми остальными java-технологиями в одной куче, а не раздроблено по сотне другой производителей и соответственно документации. А у java мощная поддержка документация, хорошие книги и прочее. Работать реально проще и удобнее разработчику. Мне лично проще работать, когда все в "одном флаконе".

Ну допустим напишу я ГУЙ на gtk и что дальше делать прикажете? Как будто программа это только один ГУЙ. А за Qt слава богу только рад, что она идет по примеру java и уже кроме средств для GUI включает в себя очень много другово очень полезного "в одном флаконе". Но с поддержкой такой как у SUN еще пока беда у Qt.

anonymous
()
Ответ на: комментарий от Absurd

> Есть одно хорошее высказывание: "Если вас не устраивает динамический полиморфизм, то статический вам тоже не поможет"

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>На практике как раз требуется в основном статический полиморфизм + шаблонный полиморфизм

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

wfrr ★★☆
()
Ответ на: комментарий от mint

> Ты не поверишь, ООП с его краеугольными принципами легко реализуем на ANSI C

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

Допустим, у нас есть struct Point { int x; int y;}

Сделай от нее производный класс Circle, да так, чтобы

Point *p=new_circle( bla-bla ); Circle *c=new_circle( bla-bla );

оба работали.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Absurd

> А как в рантайме у С++ - объекта тип можно сменить? Если на Си, можно указатель на vtbl поменять: был например квадрат, одна из размерностей поменялась - стал прямоугольник.

(прикрываясь от града камней) Если мне это понадобится, то я не постесняюсь полезть в vtbl в C++.

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

Например мы парсим что-то, получили объект Expr, потом в результате парсинга ОН ЖЕ должен превратиться в Term (который есть потомок Expr) -- и при этом изменить РАЗМЕР. Это полиморфные конструкторы, мне их в плюсах очень не хватает.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>Сделай от нее...

[special for you] Кидаю повторно ссылку на веселую книжку: http://www.planetpdf.com/codecuts/pdfs/ooc.pdf

для Ъ - там все объекты будут делаться универсальным new, а удаляться универсальным delete. Блекджек и тётеньки в комплекте

mint
()
Ответ на: комментарий от wfrr

>> На практике как раз требуется в основном статический полиморфизм + шаблонный полиморфизм

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

Если бы *не это* требовалось в основном на практике, то санки

1. не ввели бы в яву шаблоны

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от mint

> [special for you] Кидаю повторно ссылку на веселую книжку: http://www.planetpdf.com/codecuts/pdfs/ooc.pdf для Ъ - там все объекты будут делаться универсальным new, а удаляться универсальным delete. Блекджек и тётеньки в комплекте

Книжку будет интересно посмотреть, но даже не читая, можно с 99% вероятностью предположить, что там проверки типизации плюсового компилятора переносятся в рантайм.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

В целом да =)

mint
()
Ответ на: комментарий от mint

> В целом да =)

Значит, это не путь воина :-)

Заодно: мне ближе ООП в виде не методов, а функций f( Obj1* o1, Obj2* o2) -- хотя бы потому, что их можно сделать виртуальными по обоим аргументам, а не по одному первому, как в плюсах.

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

wfrr ★★☆
()
Ответ на: комментарий от www_linux_org_ru

>мне ближе ООП в виде не методов, а функций f( Obj1* o1, Obj2* o2)

В сабжевой книге так и сделано, там для всех объектов есть универсальные new, delete, differ (аналог operator==) и clone, именуемые в книге селекторами

Да, хоть я и работаю с плюсами, я в них всё больше разочаровываюсь. Единственное, что меня "удерживает" - книга Александреску и большие возможности разврата с шаблонами ;D

mint
()
Ответ на: комментарий от www_linux_org_ru

>виртуальными по обоим аргументам

Вообще они зовутся мультиметодами ;) Кстати, разве они так уж часто нужны?

theos ★★★
()
Ответ на: комментарий от theos

> Вообще они зовутся мультиметодами ;) Кстати, разве они так уж часто нужны?

Настолько часто, что в плюсовых шаблонах матчинг происходит по всем параметрам, коих может быть значительно больше двух. Это не что иное, как compile-time мультиметод.

Простейший пример: boost::lexical_cast

anonymous
()
Ответ на: комментарий от theos

> Так это _статичекский_ матчинг. это то понятно. я про _динамический_.

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

anonymous
()
Ответ на: комментарий от mint

>Да, хоть я и работаю с плюсами, я в них всё больше разочаровываюсь. Единственное, что меня "удерживает" - книга Александреску и большие возможности разврата с шаблонами ;D

Ну как бы Александреску-то плюсы давно забросил сам, а весной у него выходит новая книга по D. Поэтому есть смысл задуматься ;D

anonymous
()
Ответ на: комментарий от wfrr

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

1. да нужны

2. нет, лямбды (хотя и неполноценные) есть и в С -- в т.ч. гнутое расширение "вложенные функции"

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>лямбды (хотя и неполноценные)

Это частично беременные лямбды?

>1. да нужны


Нужны тебе, большая часть индусов живет и без них и будет жить, дальше.

wfrr ★★☆
()
Ответ на: комментарий от anonymous

> do_something((Base*)&d);

Компилятор контроль типов не делает -- в топку.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от wfrr

> Нужны тебе, большая часть индусов живет и без них и будет жить, дальше.

Опять не угадал. Посмотри на досуге доку на libcurl как пример того, как в С передаются замыкания (для Ъ -- в виде указателя на функцию и указателя на void)

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>libcurl

Писано индусами?

>в виде указателя на функцию и указателя на void


Мдя, это не лямбды это гимор на постном масле, с темже успехом ты мог бы утверждать что лямбды есть в асме.

зы. так что там с рапространенностью irl?

wfrr ★★☆
()
Ответ на: комментарий от wfrr

>> лямбды (хотя и неполноценные) > Это частично беременные лямбды?

В отличие от частично беременных женщин неполноценные лямбды можно использовать, более того, они быстрее полноценных.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>> Это частично беременные лямбды?

> В отличие от частично беременных женщин неполноценные лямбды можно использовать

Ты кормишь жирного тролля.

tailgunner ★★★★★
()
Ответ на: комментарий от wfrr

>>libcurl > Писано индусами?

The original author of cURL is Daniel Stenberg, who started the project in 1997

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Таки статический полиморфизм оказался ненужен?

wfrr ★★☆
()
Ответ на: комментарий от theos

> Вообще они зовутся мультиметодами ;) Кстати, разве они так уж часто нужны?

Честно говоря я до сих пор не понял, где нужны именно *методы* (ну или мультиметоды) в противовес функциям. По-моему, нигде.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от theos

>Вообще они зовутся мультиметодами ;) Кстати, разве они так уж часто нужны?

в 95% случаях потребность в мультиметодах означает ошибку проектирования

в оставшихся 5% - да, нужны. и для этого есть CLOS :)

jtootf ★★★★★
()
Ответ на: комментарий от wfrr

>А вставки на асме быстрее кода на сях, так что велкам к истокам?

тем, кто такое пишет, очень хочется оторвать три и более конечностей

jtootf ★★★★★
()
Ответ на: комментарий от wfrr

>Чувствуешь что надо было кодить на жаве?

это тебе libastral такое сказал?

жаба не нужна чуть более чем полностью

jtootf ★★★★★
()
Ответ на: комментарий от wfrr

Отличная новость! Поздравляю всех Qt-шников с этим замечательным событием! =)

mechanicus
()
Ответ на: комментарий от www_linux_org_ru

> как в С передаются замыкания

Замыкание -- это динамическое окружение. Возможность передать указатель на функцию никак не связана с наличием замыкания.

anonymous
()
Ответ на: комментарий от www_linux_org_ru

>В отличие от частично беременных женщин неполноценные лямбды можно использовать

А частично беременных женщин разве нельзя?

MYMUR ★★★★
()
Ответ на: комментарий от MYMUR

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

wfrr ★★☆
()
Ответ на: комментарий от wfrr

>Обоснуешь

а зачем? у меня есть Tcl, Haskell, C и C++ - и мне их хватает с головой

не вижу ни одной области, где лично мне потребовалась бы Java

jtootf ★★★★★
()
Ответ на: комментарий от wfrr

>Ну и на каком из этих языков ты будешь писать веб-сайт, на tcl?

на HAppS, Haskell. для Tcl есть Rivet, но он мне не по нраву в силу олдовости

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

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

Зачем? Есть же розовощекие маркетоиды сана, которые знают как единственно правильно :)

a3
()
Ответ на: комментарий от wfrr

>Боюсь пристрастится, кактусы они такие затянет и все

к кактусам ты уже пристрастился, так что не бойся :)

jtootf ★★★★★
()
Ответ на: комментарий от a3

Они еще и сиськастые, в отличие от бородатых хацкелистов.

wfrr ★★☆
()
Ответ на: комментарий от wfrr

>Оу, этот человек скомпилили libastral!

каждый вечер компиляю, у меня gentoo

>Однако вам подсунули версию из свн, и вот уже есть баг

свежее - значит лучшее :)

jtootf ★★★★★
()
Ответ на: комментарий от Voker57

Ссылка на пример не работает =(. А вообщене не очень понимаю зачем оно нужно. Писать на с++ то, что можно на нём не писать - это себя не уважать...

theos ★★★
()
Ответ на: комментарий от anonymous

>QT же не от хорошей жизни пользуется своим собственным препроцессором.

а) QuickTime тут мимо кассы. можно же и выучить, что библиотеку, о которой говорим, зовут Qt;

б) от того, в основном, что во времена начала Qt компиляторы C++ очень фигово умели шаблоны; а теперь уже как-то поздняк метаться. алсо, сия причина (про "фиговые компиляторы") до сих пор где-то на сайте Qt болтается. а библиотек для slot/signal (кстати, с проверкой типов на этапе компиляции, чего Qt как не умел в первой версии, так и до сих пор не умеет) есть. хотя бы общеизвестная libsigc++. а в Qt до сих пор хромают на костылях.

anonymous
()
Ответ на: комментарий от Absurd

> Ну гуевое окошко это походу машина состояний которая реагирует на события. Чето средств для хорошего, добротного описания машин состояний в С++&Co я не нашел. Лесенки switch-ей и if-ов это несерьезно. State Design Pattern - это еще более сомнительно: мне что, по классу на кждое возможное состояние окна писать?

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

deis
()
Ответ на: комментарий от deis

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

Датыщито!!? O_O

Вот бп риальни потсанъ!

Обосновать сможешь, или это у тебя случился приступ метеоризма?

anonymous
()
Ответ на: комментарий от www_linux_org_ru

>> А как в рантайме у С++ - объекта тип можно сменить? Если на Си, можно указатель на vtbl поменять: был например квадрат, одна из размерностей поменялась - стал прямоугольник.

> (прикрываясь от града камней) Если мне это понадобится, то я не постесняюсь полезть в vtbl в C++.

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

> Например мы парсим что-то, получили объект Expr, потом в результате парсинга ОН ЖЕ должен превратиться в Term (который есть потомок Expr) -- и при этом изменить РАЗМЕР. Это полиморфные конструкторы, мне их в плюсах очень не хватает.

Курим pimpl, господа хорошие.

anonymous
()
Ответ на: комментарий от jtootf

>>Курим pimpl, господа хорошие

>уж лучше траву; pimpl-то тут тебе как поможет, чучело?

Лишь бы воздух испортить? Impl новый создаешь и все.

anonymous
()
Ответ на: комментарий от anonymous

>Курим pimpl, господа хорошие.

Своим осиливанием Саттера ты на ЛОР-е никого не удивишь.

Absurd ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.