Vala 0.1.7

> ну что им мешало генерить нативный код через C?

ЧСВ

> ЧСВ

Наверное. Французы, <censored>...

> ЧСВ

А зачем, по-твоему, в GHC сделали то же самое? У Си есть определённые узкие места, генерация ассемблера позволяет от них избавиться. Или производительность сегодня никого не интересует, процы нынче дешёвые?

> А зачем, по-твоему, в GHC сделали то же самое? У Си есть определённые узкие места, генерация ассемблера позволяет от них избавиться. Или производительность сегодня никого не интересует, процы нынче дешёвые?

Цитирую документацию:

"We use -O to get respectable speed; e.g., when we want to measure something. When we want to go for broke, we tend to use -O2 -fvia-C (and we go for lots of coffee breaks)."

Это по поводу GHC и узких мест C.

<flame>Давайте по примеру Vala напишем свой язык для libvasyapupkin !!! </flame>

А если серьезно, то С++ не катит для современных либ. Вон, в QT понапихано сколько макросов (без них свой класс НЕ определить!) и думаю гномовские классы тоже не шибко удобно юзать.

Даже полноценный фронтенд на С++ к libcurl пока никто не осилил. Имеющиеся неполноценны.

Посмотрим, сделают ли валовцы полноценные шаблоны...

Но ИМХО чересчур жестко для каждой либы писать свой язык где рукам проврять наличие return и недосягаемого кода...

> А если серьезно, то С++ не катит для современных либ. Вон, в QT понапихано сколько макросов

Под современными либами понимаются гуелибы? Ну Вы неправы.

Хотя мне хотелось бы видеть в C++ нечто вроде template <typename T, int N, int M> klass<T,N+M> oper(klass <T,N> a, klass<T,M> b);

> Под современными либами понимаются гуелибы? Ну Вы неправы.

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

> Хотя мне хотелось бы видеть в C++ нечто вроде template <typename T, int N, int M> klass<T,N+M> oper(klass <T,N> a, klass<T,M> b);

Пожалуста напиши понятно... что такое klass ? oper ? И почему в С++ не проходит? Что компайлер говорит?

>Если так, то Валу правда закапывать надо...

зачем? Астральное Агенство ОБС сообщает, что Vala - исключительно для гуя? =)

> зачем? Астральное Агенство ОБС сообщает, что Vala - исключительно для гуя? =)

The syntax of Vala is similar to C#, modified to better fit the GObject type system. ( http://live.gnome.org/Vala/Syntax?highlight=%28generics%29 )

Кому еще сдался GObject кроме как для гуя? Может там хорошие классы коллекций, параметризованные типом элемента?

Впрочем, я все-таки остаюсь при мнении, что чего-то в С++ для гуя все же не хватает. Тех же properties например. И еще чего-то.

>> Хотя мне хотелось бы видеть в C++ нечто вроде template <typename T, int N, int M> klass<T,N+M> oper(klass <T,N> a, klass<T,M> b);

> Пожалуста напиши понятно... что такое klass ? oper ? И почему в С++ не проходит? Что компайлер говорит?

Да это так, схематически. Компилятор ругается на N+M, ибо нет этого в стандарте. А хотелось бы. Например, при этом очень красиво можно на темплейтах расписать все операции с тензорами произвольного типа со статической проверкой типа.

>Кому еще сдался GObject кроме как для гуя?

навскидку dbus-сервисы, avahi, libxml, trackerd, приснопамятный libxklavier =)

> Впрочем, я все-таки остаюсь при мнении, что чего-то в С++ для гуя все же не хватает. Тех же properties например. И еще чего-то.

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

И ещё строки каждый пишет так как ему взбредёт в голову(std::(w)string, QString, Glib::ustring и т.д.), но это хотя бы можно пытаться лечить.

Ты бы хоть провели сначала...


#include <stdio.h>

template<typename T, int N>  struct Tenzor {
    T value;
    static const int n=N;
};

template<typename T, int N, int M> Tenzor<T,N+M> operator * (Tenzor<T,N> a, Tenzor<T,M> b) {
    return Tenzor<T,N+M>();
}

template<typename T, int N> void print_n(Tenzor<T,N> arg) {
    printf("%d\n",arg.n);
}

int main(int argc, char** argv) {
    Tenzor<double,1> t1;
    Tenzor<double,2> t2;
    print_n(t1*t2);
    return 0;
}

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

Reflection есть и не одна. Лямбда есть в boost, правда кривоватая, попробуй угадать почему. Замыкания? Это тех которые с yield? Таких нет, правда. А обычные, которые с лямбдой -- те есть даже в яве, не говоря уже и про С++.

> Ты бы хоть провели сначала...

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

Прогу запускать так: g++ TenzorTest1.cxx && ./a.out

Результат: 3

Компилятор: g++ (GCC) 3.3.5 (Debian 1:3.3.5-13)

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

> Reflection есть и не одна. Лямбда есть в boost, правда кривоватая, попробуй угадать почему.

Угадывать не буду. Я не спорю, что приделать их можно, но "искаропки" их нет.

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

Ява шире плюсов. Вот в яве даже рефлексия "искаропки".

> Прогу запускать так: g++ TenzorTest1.cxx && ./a.out
> Компилятор: g++ (GCC) 3.3.5 (Debian 1:3.3.5-13)

Я уж на mingw проверил, работает.

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

я _НЕ_ЗРЯ_ просил кусок кода процитировать, вполне возможно грабля осталась

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

> я _НЕ_ЗРЯ_ просил кусок кода процитировать, вполне возможно грабля осталась

Код пропал летом вместе с /home :) (теперь я делаю бэкапы :) )

> Угадывать не буду. Я не спорю, что приделать их можно, но "искаропки" их нет.

1. Явовская лямбда намного хуже С++.

2. Тебе видимо сложно сказать apt-get install boost ?

> Ява шире плюсов. Вот в яве даже рефлексия "искаропки".

Ява намного уже плюсов. С++-ная лямбда в яве не идет из-за type erasure.

P.S. Еще одна жертва пиара Sun Microsystems...

> 2. Тебе видимо сложно сказать apt-get install boost ?

Мне сложно писать дополнительный код там, где это за меня может сделать компилятор/интерпретатор.

> P.S. Еще одна жертва пиара Sun Microsystems...

Погрепай по лору мои сообщения в темах с явой и больше не делай таких обидных заявлений :)

>> Ява шире плюсов. Вот в яве даже рефлексия "искаропки".

> Ява намного уже плюсов.

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

>>Кому еще сдался GObject кроме как для гуя?

>навскидку dbus-сервисы, avahi, libxml, trackerd, приснопамятный libxklavier =) 

Cделал grep -ir gobj /usr/include/libxml2/libxml/*

Ниче не нашел... 

Мой вопрос был не о Грандиозном Вкладе Гнома В Развитие Мировой Цивилизации, а кому нужен GObject кроме как для гуя.

Если libxml как-то юзает GObject, подскажи плиз...

> Если libxml как-то юзает GObject, подскажи плиз...

Я копался там некоторое время назад в libxml++ и видел, что там все строки -- это Glib::ustring, который из glib. А если учесть, что libxml++ -- это c++ - биндинги к libxml2, то наверняка и там на glib опирается.

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

Не согласен. У С++ тоже полно недостатков, которые я с удовольствием буду обсуждать, однако это не мешает ему быть шире явы.

> урезана, что даёт больше искоробочных фишек

Нету никакой связи между урезкой и фишками

>а кому нужен GObject кроме как для гуя.

а ты референс на glib покури.

>Если libxml как-то юзает GObject, подскажи плиз...

внутрь не лазил, детектор работает по зависимостям =)

> в libxml++ и видел, что там все строки -- это Glib::ustring

Сделал grep -ir glib /usr/include/libxml2/libxml/*

Ничего не нашел...

И кстати в Дебиане libxml2:

Depends: libc6 (>= 2.3.2.ds1-21), zlib1g (>= 1:1.2.1)

А zlib1g:

Depends: libc6

З.Ы.: libxml++ могли добавить GObject -- но похоже можно обойтись и без него, особенно в парсинге ХМЛ

> У С++ тоже полно недостатков, которые я с удовольствием буду обсуждать, однако это не мешает ему быть шире явы.

Да, потенциально там можно сделать больше.

Но сериализацию в c++ нельзя сделать так же быстро, как в той же яве(implements Serializable плюс определить hashCode и serialVersionUUID). А всё из-за того, что ява "урезана".

>> урезана, что даёт больше искоробочных фишек

> Нету никакой связи между урезкой и фишками

Есть. Например, управляемый heap можно сделать(не нарушая идеологию языка) только в языке с урезанными указателями и без адресной арифметики(java, c#).

> З.Ы.: libxml++ могли добавить GObject -- но похоже можно обойтись и без него, особенно в парсинге ХМЛ

Ну фиг знает...

Вообще, говорят, что glib в многих структурах дублирует stl, может оттуда что-то типа list, map и прочего брали.

> Да, потенциально там можно сделать больше.

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

>> Да, потенциально там можно сделать больше.

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

Дело не в тьюринг-полноте. Дело в низкоуровневом доступе к ресурсам.

Например, где ядро ос, написанное от корки до корки на жабе? Или как мне переслать произвольную структуру данных по сети с интела на спарк в c/c++?

>> Да, потенциально там можно сделать больше.

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

Ещё порция бреда(я в прошлом посте ответил скорее в тему "урезанность vs фишки").

Как я могу написать на яве свой менеджер памяти для явы?

>> Да, потенциально там можно сделать больше.

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

Хороший вопрос, однако строго формально ответа на него нет. Ибо если бы качество языка определялось его тьюринг-полнотой, все программили бы исключительно на ассемблере.

Начнем:

1. переносимость

2. эмоционально приятный синтаксис

3. легкость модификации программы при изменении требований к задаче

...

> Или как мне переслать произвольную структуру данных по сети с интела на спарк в c/c++?

CORBA ?

> эмоционально приятный синтаксис

У плюсов? Глядя на те конструкции, которые были приведены чуть выше, мне не кажутся они эмоционально приятными.

>> Или как мне переслать произвольную структуру данных по сети с интела на спарк в c/c++?

> CORBA ?

Да хоть и корба. Только для этого мне _придётся_ перелопатить всю структуру дабы сделать её конвертируемой в нужный вид. Потому что стандартного способа доступа к метаинформации в C нет.

>> эмоционально приятный синтаксис

> У плюсов? Глядя на те конструкции, которые были приведены чуть выше, мне не кажутся они эмоционально приятными

Это про тензоры? Вот этим как раз и хороша перегрузка операторов, имеющаяся в c++, что мысля "мне надо сложить тензор a и тензор b" я пишу именно "a+b", а не "TensorAdd(a,b)" и не "a.add(b)"

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

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

Да я понимаю. Просто при всех тех некрасивостях есть ещё и приятности.

> Да хоть и корба. Только для этого мне _придётся_ перелопатить всю структуру дабы сделать её конвертируемой в нужный вид. Потому что стандартного способа доступа к метаинформации в C нет.

способ называется dwarf2 (и на нем есть рефлекшн)

а как ты думал gdb работает?

>> Да хоть и корба. Только для этого мне _придётся_ перелопатить всю структуру дабы сделать её конвертируемой в нужный вид. Потому что стандартного способа доступа к метаинформации в C нет.

> способ называется dwarf2 (и на нем есть рефлекшн).

Разве я могу его портабельно заюзать из любого c-шного кода?

> а как ты думал gdb работает?

Читает debug info, который можно и отрезать.

>з.ы. для ембедед систем думаю mono тоже можно допилить. есть ведь .NET CF

Для N800 моно есть. Но идея писать приложения со скоростью девелопмента в моно и скоростью выполнения C-кода весьма заманчива...

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

> Да я понимаю. Просто при всех тех некрасивостях есть ещё и приятности.

Нет. Это был камушек в сторону Лиспа, что инфоман конечно понял.

Я не фанатик плюсов. И очень даже за его критику. Только по делу, а не из-за невежества.

с лиспом не особо знаком.

>> способ называется dwarf2 (и на нем есть рефлекшн).

> Разве я могу его портабельно заюзать из любого c-шного кода?

При gcc и любом другом компиляторе, юзающем dwarf2 -- можешь.

>> а как ты думал gdb работает?

> Читает debug info, который можно и отрезать.

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

>>> способ называется dwarf2 (и на нем есть рефлекшн).

>> Разве я могу его портабельно заюзать из любого c-шного кода?

> При gcc и любом другом компиляторе, юзающем dwarf2 -- можешь.

Это есть в стандарте? Или только в некоторых компиляторах, в число которых входит gcc?

>> Читает debug info, который можно и отрезать.

> Так ты его перед тем как отрезать используй для рефлексии...

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

> мне уже тяжело объяснять очевидные вещи, тем более что это уже сделано.

Ну извини, такой вот я непонятливый :)

> Ну извини, такой вот я непонятливый :)

ISO-шного стандарта нет конечно, иначе бы разговор про dwarf2 не шел -- заранее отвечаю: да, плохо что не исошный стандарт, да, найдешь ты компилятор для которого это не заработает, нет, это не хуже чем в яве, поскольку в яве тоже сильная привязка к сановскому компиллятору -- какой компилятор щас поддерживает явовские generics?

впрочем, моя инфа может быть устревшей -- поправьте кто может -- есть ли щас не-сановский компилятор, поддерживающий все фичи явы 6?

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

Плохо :(

> нет, это не хуже чем в яве,

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

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

Ну в яве это вроде б в стандарте.