Mono 1.9 Released

> Когда я смогу объявить функцию типа auto f(auto x, auto y), тогда поговорим, а пока даже не смешно.

Хм... а

template<class A1, class A2, class A3> A1 f(A2 a2, A3 a3) { /* ... */}

не подойдет? Если нет, то почему?

>>>в следующем году, вроде бы, будет следующая редакция стандарта с++. в котором будет тип auto, который, если я не путаю, реализует выведение типов :)

>>А через сколько лет это появится в коммерческих компиляторах? Думаю, уже никогда.

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

У Intel C++ качество кодогенерации знаете ли получше. Асмовые листинги -O0 у icc визуально похожи на -O1 или даже -O2 у gcc.

> в котором будет тип auto, который, если я не путаю, реализует выведение типов :) 

А почему будет? он собссно уже есть, толко какое здесь "выведение типов"? 


class A
{
private:
    int _a;
public:

    this(int iInit)
    {
        _a = iInit;
    }

    int afunc(int iArg)
    {
        return iArg * _a;
    }
}

auto a = new A( 100 );
writefln("fac = %d\n", a.afunc(10));

>> Когда я смогу объявить функцию типа auto f(auto x, auto y), тогда поговорим, а пока даже не смешно.

>template<class A1, class A2, class A3> A1 f(A2 a2, A3 a3) { /* ... */}

>не подойдет? Если нет, то почему?

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

> template<class A1, class A2, class A3> A1 f(A2 a2, A3 a3) { /* ... */}

Я, вообще-то, намекал на типизацию Хиндли-Милнера, лол. А от вашего шаблона толку ноль, вместо того, чтобы молча определить тип аргументов и результата функции по её содержимому, а потом выдавать ошибки, если я неправильно эту функцию вызываю, компилятор молча насоздаёт столько функций, сколько комбинаций типов параметров я спьяну насочиняю, и вместо внятного сообщения "параметр X функции Y имеет неправильный тип" я получу мутную непредсказуемую байду типа "не определён оператор + для такого-то класса".

> Вообще в реальном проекте я бы не хотел видеть шаблоны вообще.

vector не юзить?

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

>> template<class A1, class A2, class A3> A1 f(A2 a2, A3 a3) { /* ... */}

> Я, вообще-то, намекал на типизацию Хиндли-Милнера, лол

Ты находишь типизвацию Хиндли-Милнера смешной, лол?

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

Кто-то из нас неправильно понимает type inference и ее реализацию компилятором.

> и вместо внятного сообщения "параметр X функции Y имеет неправильный тип" я получу мутную непредсказуемую байду типа "не определён оператор + для такого-то класса".

Да уж. Хаскел известен своими кристально ясными сообщениями об ошибках с типами, лол.

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

>> Вообще в реальном проекте я бы не хотел видеть шаблоны вообще.

>vector не юзить?

Нет, не юзить. Сделать свою коллекцию которая хранит объекты имплементирующие IСollectionItem и послать Страуструпу мысленный превед.

>> Ты пишешь "Из-за типов данных нестыковок не было ни разу" -- так ЗНАЧИТ ТЫ КАК-ТО ОПРЕДЕЛЯЕШЬ ЧТО ОНИ БЫЛИ ИЗ-ЗА ИЛИ НЕ ИЗ-ЗА ТИПОВ ДАННЫХ? КАК???

>У меня есть переменная a = A()

>я вызываю метод a.afunc1()

>что будет есть я вызову a.func1(), если a не будет экземпляром A?

>> А если она не будет кортежом 1 раз в 100 запусков программы?

>с какого вдруг перепугу? если функцию f вызывали всегда с кортежем, то почему 1 раз из 100 она вызовется не с кортежем?

Потому что вызывалось f(g(user_data)), и вдруг попались такие неожиданные user_data (от хакера ломающего веб-сайт :-), что g(user_data) вернула не кортеж, а число?

или:

if day_of_month<28 : x=a.method_of_A(day_of_month) else: x=a.not_method_of_A(day_of_month )

>>vector не юзить?

>Нет, не юзить. Сделать свою коллекцию которая хранит объекты имплементирующие IСollectionItem и послать Страуструпу мысленный превед.

Так, штоле?

typedef std::vector<ICollectionItem *> PrevedStraus;

:D

> Кто-то из нас неправильно понимает type inference и ее реализацию компилятором.

Точно, Билл. И знаешь, что? Сдаётся мне, что это ты.

>> Кто-то из нас неправильно понимает type inference и ее реализацию компилятором.

> Точно, Билл. И знаешь, что? Сдаётся мне, что это ты.

А знаешь, Робин... мне кажется, что это ты :D

>в следующем году, вроде бы, будет следующая редакция стандарта с++. в котором будет тип auto, который, если я не путаю, реализует выведение типов :)

Хмм. Динамическая типизация побеждает?

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

Зачем в stl есть std::list и std::map я не понял. std::list начинает обгонять std::vector при объеме коллекции более тысячи элементов. Такие объемы не один здоровый человек в ОЗУ хранить не будет. Для lookup-таблиц вместо std::map подошел бы отсортированный массив или хэш. Большие индексы хранятся в БД, или если нет БД то нужно уже не красно-черное дерево, а B* дерево которое лежит на диске и выфетчивается кусками.

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

Анонимус, напиши подробно, зачем тебе ауто?

>> в следующем году, вроде бы, будет следующая редакция стандарта с++. в котором будет тип auto, который, если я не путаю, реализует выведение типов :)

> Хмм. Динамическая типизация побеждает?

Ггг... где ты там динамиескую типизацию увидел? А насчет "побеждает" - ага, она уже лет 50 всё побеждает и побеждает...

>>>vector не юзить?

>>Нет, не юзить. Сделать свою коллекцию которая хранит объекты имплементирующие IСollectionItem и послать Страуструпу мысленный превед.

>typedef std::vector<ICollectionItem *> PrevedStraus;

Чтобы избежать терок типа "сам stl юзает, а нам не дает" придеццо таки сделать велосипедик.

> std::list начинает обгонять std::vector при объеме коллекции более тысячи элементов. Такие объемы не один здоровый человек в ОЗУ хранить не будет

Признайся - ты начинал программировать на PIC'ах? 8)

>2. Проект Mono продвигает технологии Micro$oft в Linux.

+1. Почему судьбой МОNО заитересованы более всего M$develores.

>std::list начинает обгонять std::vector при объеме коллекции более тысячи элементов

объясни???

> Для lookup-таблиц вместо std::map подошел бы отсортированный массив

Офигеть как быстро вставить что-то в середину массива длинной 100К...

> или хэш. Большие индексы хранятся в БД, или если нет БД то нужно уже не красно-черное дерево, а B* дерево которое лежит на диске и выфетчивается кусками.

Это ты к чему? Без проблем такое написать на плюсах.

>> std::list начинает обгонять std::vector при объеме коллекции более тысячи элементов. Такие объемы не один здоровый человек в ОЗУ хранить не будет

>Признайся - ты начинал программировать на PIC'ах? 8)

Нет, у меня коллекции обычно бывают элементов по 10. Данные хранятся в БД обычно. Была работка с большими tiff файлами, там я мапил нужный кусок файла в память.

> Жем 2.0!

Это уже будет стерео, может лучше сразу версию 5.1 зарелизить для солидности?

> сразу версию 5.1

Говорят 5.1 уже не модно. уже что-то большее

5.2?

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

> Нет, у меня коллекции обычно бывают элементов по 10.

The reserve() function sets the capacity of the vector to at least size.

А еще можно свой vector в 10 строчек написать вокруг стд::вектор

>>> std::list начинает обгонять std::vector при объеме коллекции более тысячи элементов. Такие объемы не один здоровый человек в ОЗУ хранить не будет

>>Признайся - ты начинал программировать на PIC'ах? 8)

> Нет, у меня коллекции обычно бывают элементов по 10

А сколько у тебя коллеуций?

> Данные хранятся в БД обычно

Есть куча задач, которые ворочают большими объемами данных, не используя БД; даже без временных файлов.

Ты, наверное, на Яве пишешь? Прикинь, сколько объектов хранит JVM для своих внутренних нужд :D

>>std::list начинает обгонять std::vector при объеме коллекции более тысячи элементов

>объясни???

С точки зрения теории добавление в linked list это O(1) операция, а в массив это O(N) операция. На практике vector растет с запасом 1.5 - 2 занятой емкости, и при серии добавлений элемент перезжает на новое место жительства в среднем 1 раз - экспоненциальный закон. При этом в std::list константные множители при O(1) настолько велики, что при размерах коллекции до ~1000 элементов vector оказывается выстрее.

>> Для lookup-таблиц вместо std::map подошел бы отсортированный массив

>Офигеть как быстро вставить что-то в середину массива длинной 100К...

lookup-таблица длиной в 100K ? что-то не так в консерватории.

>> или хэш. Большие индексы хранятся в БД, или если нет БД то нужно уже не красно-черное дерево, а B* дерево которое лежит на диске и выфетчивается кусками.

>Это ты к чему? Без проблем такое написать на плюсах.

Только вот как интерфейс B* дерева ляжет в принятый в stl кодинг стандарт?

> Нет, не юзить. Сделать свою коллекцию которая хранит объекты имплементирующие IСollectionItem и послать Страуструпу мысленный превед.

Что тебя раздражает? Что std::list на пару тактов дольше чем список который хранит объекты имплементирующие IСollectionItem ?

>> Нет, у меня коллекции обычно бывают элементов по 10

>А сколько у тебя коллеуций?

Какая разница - для коллекций в 10 элементов ничего проме плоского массива не нужно.

>> Данные хранятся в БД обычно

>Есть куча задач, которые ворочают большими объемами данных, не используя БД; даже без временных файлов.

Тут нужен особый подход типа маппинга файла в память по кускам. Я уже писал про это в своем посте.

>Ты, наверное, на Яве пишешь? Прикинь, сколько объектов хранит JVM для своих внутренних нужд :D

Объекты jvm не критичны. Пользователь не боится их потерять. А вот если из-за скачка напряжения пользователь потеряет свои данные из-за того что приложение ими оперирует чисто в ОЗУ, то это плохо.

>> Нет, не юзить. Сделать свою коллекцию которая хранит объекты имплементирующие IСollectionItem и послать Страуструпу мысленный превед.

>Что тебя раздражает? Что std::list на пару тактов дольше чем список который хранит объекты имплементирующие IСollectionItem ?

Я не шлаковод чтобы такты считать. Не хочу превращать проект в помойку, вот и все.

>Как заорёт батька Баллмер - "ДевелоПЁРЗ! А ну сосать 3.5!!! " ... и будете сосать аж причмокивая - куда ж вы денетесь :)

Они не девелопёрз больше. Поднимай выше - они Герои! http://heroes2008.ru// Герои среди {НАС}

> С точки зрения теории добавление в linked list это O(1) операция, а в массив это O(N) операция. На практике vector растет с запасом 1.5 - 2 занятой емкости, и при серии добавлений элемент перезжает на новое место жительства в среднем 1 раз - экспоненциальный закон.

О(1) это если тебе не надо искать эл-т после/до которого ты вставляешь. А если надо... то будет O(N).

> При этом в std::list константные множители при O(1) настолько велики, что при размерах коллекции до ~1000 элементов vector оказывается выстрее.

Не может такого быть. Видимо ты ищещь долго куда надо вставить. А std::list совсем не для этого.

>> А сколько у тебя коллеуций?

> Какая разница

Просто интересно - сколько объектов у тебя в программе, раз список в 1000 элементов вызывает такие чувства.

>>Есть куча задач, которые ворочают большими объемами данных, не используя БД; даже без временных файлов.

>Тут нужен особый подход типа маппинга файла в память по кускам.

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

>>Ты, наверное, на Яве пишешь? Прикинь, сколько объектов хранит JVM для своих внутренних нужд :D

>Объекты jvm не критичны. Пользователь не боится их потерять

lookup-таблицы тоже некритичны. И AST/GIMPLE/RTL, которые достигают десятков и сотен мегабайт - некритичны. И еще много чего - не критично, но много по оъему, и всё это нужно где-то хранить.

> Я не шлаковод чтобы такты считать. Не хочу превращать проект в помойку, вот и все.

Я так и не понял что бедному несчастному Абсурду надо. У с++ полно узких мест, но все, что я пока от абсурда слышал, можно сделать на с++ с комфортом.

>1. Mono является конкурентом Java.

>2. Проект Mono продвигает технологии Micro$oft в Linux.

Давай, родненький, мы все ждем. http://www.linux.org.ru/view-message.jsp?msgid=2584991 Продвинь нам в линукс программу на технологии Microsoft, ага.

>> С точки зрения теории добавление в linked list это O(1) операция, а в массив это O(N) операция. На практике vector растет с запасом 1.5 - 2 занятой емкости, и при серии добавлений элемент перезжает на новое место жительства в среднем 1 раз - экспоненциальный закон.

>О(1) это если тебе не надо искать эл-т после/до которого ты вставляешь.

Поиск элемента в связанном списке это O(N) операция. А вообще, код в котором важен порядок элементов в коллекции - это быдлокод. Должно хватать знания отсортирована коллекция или нет. Добавлять всегда нужно в конец.

>> При этом в std::list константные множители при O(1) настолько велики, что при размерах коллекции до ~1000 элементов vector оказывается выстрее.

>Не может такого быть. Видимо ты ищещь долго куда надо вставить. А std::list совсем не для этого.

Это у Саттера написано. Страус тоже советует не думать, а брать сразу std::vector.

>>> А сколько у тебя коллеуций?

>> Какая разница

>Просто интересно - сколько объектов у тебя в программе, раз список в 1000 элементов вызывает такие чувства.

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

>>Тут нужен особый подход типа маппинга файла в память по кускам.

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

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

>>Просто интересно - сколько объектов у тебя в программе, раз список в 1000 элементов вызывает такие чувства.

>Каждый случай когда нужен список в 1000 элементов c большим количеством вставок/удалений из середины отличается, скажем так, индивидуальностью, и штамповка с применением стандартной библиотеки тут не прокатит.

Сказал - как отрезал. А приводить доводы - не царское это дело.

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

>А как это должно масштабироваться?

Ы? Причем здесь масштабирование? Я говорю о задачах, в которых длина внутренних списков - тысячи и десятки тысяч элементов, и вполне "здравые люди" хранят их в ОЗУ (блин, ОЗУ для этого и сделано).

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

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

> Как они между собой будут шарить память?

Зачем?

P.S. лехкое масштабирование с единиц мегабайтов до сотен гигабайт - это из области антинаучной фантастики. Наверняка архитектуры программ буду сильно разными... но внутри них всё равно будет STL и списки в много тысяч объектов :)

>Понимаешь, еще не у всех на десктопе стоит двухпроцессорный комп с двумя четырехядерными ксеонами и 64 гигами оперативки...

Понимаем, и сами мы не местные... Да, но гастарбайтерам Рамшану и Джамшуду не нужен комп, даже с одним процом, солнце еще высоко, так что работайте там, давайте. А уж если мы здесь, в 1500км за МКАД, можем себе купить для работы и развлечения Core2 с 4Гб оперы, то уж вам там за кремлевскими стенами вообще стыдно жаловаться, уж 2-то гига памяти купить не такие дикие и деньги сейчас

>Вот что есть в моно, чего нет в JVM: структуры и делегаты.

Уга. Структуры это такие объекты без методов? Ну и нахера они спрашивается в ООП могут быть нужны?

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

Ога, 7 лет назад появился мощный конкурент в виде .NET, а ява даже ухом не повела. Уж теперь-то наконец дааа, ява испугается мощного конкурента mono, ага щас. Только носки подтянет и кааааак побежит догонять!

>>Кто будет толкать моно в Gnome/KDE? >Оно уже в гноме, и толкают его мигель и новелл. В кедах пока слава богу моны нет

Хрена, оно и в кеды проберётся: Qyoto (Qt4 bindings for .NET (MONO))

>>Каждый случай когда нужен список в 1000 элементов c большим количеством вставок/удалений из середины отличается, скажем так, индивидуальностью, и штамповка с применением стандартной библиотеки тут не прокатит.

>Сказал - как отрезал. А приводить доводы - не царское это дело.

В моей практике это так. Мне всегда удавалось чанки по 1000+ элементов обрабатывать потоковым образом. И очень часто приходилось рефакторить быдлокод сжиравший весь своп из-за того что какой-то Петя Вупкин не видит другого способа работы с данными кроме как загнать все в массив и дальше фигаить свой любимый fot i = 0 to data.size()

>>А как это должно масштабироваться?

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

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

> и вполне "здравые люди" хранят их в ОЗУ (блин, ОЗУ для этого и сделано)

Когда ОЗУ не существовало, уже были аппараты для цифрового масштабирования фотографий, на кратные порядки разумеется. ОЗУ всегда было окном для текущего scope данных, необходимых алгоритму + кэш чтобы слишком часто диском не трещать. Все остальное всегда писали на диск. Даже в видеоиграх, где дан целый город или страна для исследования типа Ultima 9 данные в фоне подсасываются с диска.

> Когда ОЗУ не существовало, уже были аппараты для цифрового масштабирования фотографий, на кратные порядки разумеется.

Эт... если у тебя BMP 4Кх4К пикселей, и тебе надо получить ВМР 2Кх2К, то без 2К ОЗУ ты ниче не сможешь... а если мне дать 2К ОЗУ, то я тебе уменьшу и НЕ на кратный порядок, причем за один проход :-)

> если у тебя BMP 4Кх4К пикселей, и тебе надо получить ВМР 2Кх2К, то без 2К ОЗУ ты ниче не сможешь

я имел в виду один проход конечно

_________________________________

А stl написана совсем не в стиле "глотаем все и фигачим for"

>>Вот что есть в моно, чего нет в JVM: структуры и делегаты.

>Уга. Структуры это такие объекты без методов? Ну и нахера они спрашивается в ООП могут быть нужны?

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

Притом до структур С++ они все ж не дотягивают.

> ОЗУ всегда было окном для текущего scope данных, необходимых алгоритму + кэш чтобы слишком часто диском не трещать.

Поправь меня, если я ошибаюсь, но ОЗУ появилось раньше диска :D А потом появилась виртуальная память.

По-любому, ОЗУ нужно использовать в полной мере.

>Понимаешь, еще не у всех на десктопе стоит двухпроцессорный комп с двумя четырехядерными ксеонами и 64 гигами оперативки...

Господи, как достали придурки! Для запуска хэлловорда достаточно -Xmx1m (этого хватит для запуска JVM 1.6 и вывода хэлловорда). Для всех остальных софтин жаба потребляет столько памяти, сколько требуется по коду, а если код писал индус или любитель пхп/питона (что в принципе одно и тоже), то медицина здесь бессильна!. И никакие четырехядерные ксеоны не нужны - софтина с полусотней активных потоков может замечательно крутится на каком-нибудь целере. Хотя если вам нужно чтобы все эти потоки ворочали по несколько миллионов записей БД в режиме 24/7 - тут уж извольте раскошелится, но я сомневаюсь что на питоне получилось бы проще/быстрее.

худей