Здравствуйте, IT, Вы писали:

C>>В Java стараются сейчас все делать конкретными классами...
IT>Java — суксь Немерля — the dest
Для Немерля есть IDEA?

Нет? Значит в сад!

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, IT, Вы писали:

C>>>В Java стараются сейчас все делать конкретными классами...
IT>>Java — суксь Немерля — the dest
C>Для Немерля есть IDEA?

Ты же был поклонником CodeBlocks & XRef, no?

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Курилка, Вы писали:

IT>>Java — суксь Немерля — the dest

К>От destiny?

Очепятался

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Курилка, Вы писали:

IT>>>Java — суксь Немерля — the dest

К>>От destiny?

IT>Очепятался

А все потому, что у тебя нет макроса

$theirStupidLanguage - суксь :))) Немерля - the Best :super:

You will always get what you always got
  If you always do  what you always did

Здравствуйте, IT, Вы писали:
IT>Очепятался
Нееет. Это не может быть случайным совпадением. Это новый термин

Здравствуйте, jazzer, Вы писали:

C>>>>В Java стараются сейчас все делать конкретными классами...
IT>>>Java — суксь Немерля — the dest
C>>Для Немерля есть IDEA?
J>Ты же был поклонником CodeBlocks & XRef, no?
Я вообще на всем пишу (С, С++, Java, C#, Python, Nemerle ). Просто лучшей IDE, чем IDEA я пока просто еще не видел.

Здравствуйте, Cyberax, Вы писали:

>>>Для Немерля есть IDEA?
J>>Ты же был поклонником CodeBlocks & XRef, no?
C>Я вообще на всем пишу (С, С++, Java, C#, Python, Nemerle ). Просто лучшей IDE, чем IDEA я пока просто еще не видел.

Дело не в личных пристрастиях, а в том, что IDE (Idea, Eclipse, MS VS) должна понимать, что происходит в коде.
Тогда она становится "магической" — организовывает поиск, рефакторинг, автодополнения и прочее. Она помогает писать код.
А если IDE не понимает кода, если он для неё просто кусок текста — тогда оно больше мешает писать код, бестолковое.

Тогда что делать мета-языкам, которые ориентированы на макросы и прочие способы расширения? Вносить информацию
о конкретных макросах и мета-данных (аннотациях) в IDE. И что у нас получается в итоге? В итоге — первичным
становится внутрнее описание программы в IDE и компиляторе, а отображением кода оно может свободно манипулировать.
Эти процессы происходят параллельно и в Eclispse, и в Idea, и наверняка в Visual Studio. Это объективная
тенденция — даже не-макросовый язык развивается (новые версии — Java 1.1-1.6, C# 1.0-3.0 и т.д.) и у них
появляются мета-данные, генераторы кода и прочая и прочая.

На что похожа такая среда разработки и доведённый до логического конца язык программирования? Правильно — на
SymADE, на MPS от JetBrains, на среду разработки Intentional Programming.

Поэтому немерле и есть суксь. Она отчаянно цепляется за текстовое представление кода, и для неё принципиально
нельзя создать IDE такого же уровня, как Idea или Eclipse.

Здравствуйте, IT, Вы писали:

IT>Почему, например, расширение linq захардкоженное, прибитое гвоздями к C# и VB это хорошо, а набор макросов, делающий тоже самое — это плохо.

Потому что LINQ прописан в стандарте и его будет обязан знать каждый, претендующий на звание C# developer. И когда я уйду из одной команды и приду в другую, там будет все тот же самый LINQ.

IT>Индустрия банально не имеет макросов, поэтому извращается как может.

Спорно. Идее ситаксических макросов 200 лет в обед. Однако ж не прижились пока что.

IT> Проблемы pre-compile и run-time кодогенерации хорошо известны и, к сожалению, неразрешимы. Я, например, в своё время поимел много гемороя с pre-compile-time генерацей код. Народ по незнаю правил такой код вручную и когда это всплывало через несколько месяцев, то наступал полный паралич.

Это не проблема технических средств, это проблема организации процесса разработки. У меня в текущем проекте масса pre-build и студийных кодогенераторов, однако за последние 4 года еще ни у кого не хватило ума править автогенеренный код, хотя уровень девелоперов был очень разный, вплоть до обезьянок.

IT>У run-time кодогенерации тоже есть свои козявки. Приходится использовать абстрактные классы, которые к тому же всегда должны быть публичные. Классы, которые не генерируются, но для которых что-то генерируется тоже должны обязательно быть публичными.

Это, мягко говоря, неправда. Skip visibility check еще никто не отменял.

Здравствуйте, VladD2, Вы писали:

FR>>>>На C++ шаблонах такое пишется без проблем, используются ленивые вычиления, то есть выражение собирается в operator= скорость не уступает сишной.
VD>>>Решение конечно на шаблонах с применением Буста?
FR>>На шаблонах без буста. Я такой велосипед писал когда про буст еще не слышал.
VD>Дык, изобрази... посмеемся вместе.

Вот очень грубый эскиз

// исходный контейнер
struct vector
{
    int size() const;
    double operator[](int) const;
    double& at(int);
    
    template<class V> operator=(const V& v)
    {
        for(int i=0, n=size(); i!=n; ++i)
            at(i) = v[i];
    }
};

// ленивая арифметика: кирпичики
template<class V> struct vmul_t
{
    const V& v; double m;
    vmul_t(const V& v, double m) : v(v), m(m) {}
    double operator[](int i) const { return v[i]*m; }
};
template<class V>
    vmul_t<V>
        vmul(const V& v, double m) { return vmul_t<V>(v,m); }

template<class V1, class V2> struct vsum_t
{
    const V1& v1; const V2& v2;
    vsum_t(const V1& v1, const V2& v2) : v1(v1), v2(v2) {}
    double operator[](int i) const { return v1[i]+v2[i]; }
};
template<class V1, class V2>
    vsum_t<V1,V2>
        vsum(const V1& v1, const V2& v2) { return vsum_t<V1,V2>(v1,v2); }

// обёртка над кирпичиками позволяет избежать комбинаторного взрыва
template<class V> struct vid_t
{
    const V& v;
    vid_t(const V& v) : v(v) {}
    double operator[](int i) const { return v[i]; }
};
template<class V>
    vid_t<V>
        vid(const V& v) { return vid_t<V>(v); }

// строим выражения: сперва с участием конкретных типов слева (вектор, число)

template<class V>
    vid_t<vmul_t<V> >
        operator* (double m, const V& v) { return vid(vmul(v,m)); }

    vid_t<vmul_t<vector> >
        operator* (const vector& v, double m) { return vid(vmul(v,m)); }
    vid_t<vmul_t<vector> >
        operator/ (const vector& v, double m) { return vid(vmul(v,1/m)); }

template<class V2>
    vid_t<vsum_t<vector,V2> >
        operator+ (const vector& v1, const V2& v2) { return vid(vsum(v1,v2)); }
template<class V2>
    vid_t<vsum_t<vector,vmul_t<V2> > >
        operator- (const vector& v1, const V2& v2) { return vid(vsum(v1,vmul(v2,-1))); }

// а теперь слева шаблон vid_t

template<class V>
    vid_t<vmul_t<V> >
        operator* (const vid_t<V>& v, double m) { return vid(vmul(v,m)); }
template<class V>
    vid_t<vmul_t<V> >
        operator/ (const vid_t<V>& v, double m) { return vid(vmul(v,1/m)); }

template<class V1, class V2>
    vid_t<vsum_t<V1,V2> >
        operator+ (const vid_t<V>& v1, const V2& v2) { return vid(vsum(v1,v2)); }
template<class V1, class V2>
    vid_t<vsum_t<V1,vmul_t<V2> > >
        operator- (const vid_t<V>& v1, const V2& v2) { return vid(vsum(v1,vmul(v2,-1))); }

Здесь можно добавить следующие вещи:
1) избавиться от лишней косвенности (т.е. снимать обёртку)

template<class V> struct clean_t { typedef V type; };
template<class V> struct clean_t<vid_t<V> > { typedef V type; };

template<class V> const V& clean(const V& v) { return v; }
template<class V> const V& clean(const vid_t<V>& v) { return v.v; }

// и пропатчить все операторы вот так:

template<class V1, class V2>
    vid_t<vsum_t<typename clean_t<V1>::type, typename clean_t<V2>::type> >
        operator+ (const vid_t<V>& v1, const V2& v2) { return vid(vsum(clean(v1), clean(v2)); }

2) протащить через выражения не только operator[], но и функцию size()
3) сделать нормальное деление и вычитание вместо эмуляции на сложении и умножении
и т.д. и т.п.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Gaperton, Вы писали:

G>>Собственно, все. Можно сделать чтобы работало как в статике, так и в динамике. Без макросов. Где у нас подвох?
WH>Подвох в том что базового пространства нет.
WH>И завести его без потери точности и эффективности невозможно.
В классе пространств, которые приводятся линейным преобразованием друг к другу (а это, как ты сказал, половина твоих преобразований), такое пространство, через которое ты будешь гнать цвет, в явном виде не нужно. Ты всегда получаешь прямое преобразование перемножением матриц, и потери эфективности и точности здесь не будет. А если ты воспользуешься оптимизированной библиотекой BLAS от Intel, и применишь 32-х битные float для компонент цвета (чего вполне достаточно) то у тебя будет чистый выигрышь в производительности (будет задействовано SSE). Это делается чисто и понятно — без макросов.

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

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

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

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Mikl Kurkov, Вы писали:

G>>>>Индустрия имела макросы в далеких 70-х.
MK>>Ну вот лежит книга Брауна "Макропроцессоры и мобильность ПО".

IT>И где здесь про всю индустрию?

Нужно сказать, что на ЕС ЭВМ была масса операционных систем! Дос — это была простая система с фиксированным числом задач и фиксированным распределением памяти. ОС MFT была значителоьно более развита с точки зрения сервиса файловой системы, но распределение памяти тож было фиксированным. Разделы назначались при генерации (сейчас это называется инсталляцией-установкой) конкретной конфигурации системы.
Генерация — потому что ось представляла собой колоссальное количество макросов. Генерация состояла в том, что создавался пакет макровызовов с конкретными параметрами макросов. Для этого на компьютере была предустановлена минимальная система с транслятором-ассемблером (макроассемблером). Процесс генерации занимал несколько часов, потом ситему проверяли на работоспособность — та еще работа... Часто оказывалось, что параметры заданы не те или не так — не стыковались у некоторых макросов сочетания... И приходилось перегенерировать систему. Поэтому в системные программисты (а они как раз и занимались такой работой) старались брать людей, уже имевших опыт

http://rsdn.ru/Forum/Info.aspx?name=FAQ.Learningtofly.LaptevVV.part8

Автор: LaptevVV
Дата: 13.01.05

Здравствуйте, Gaperton, Вы писали:

G>http://rsdn.ru/Forum/Info.aspx?name=FAQ.Learningtofly.LaptevVV.part8

Автор: LaptevVV
Дата: 13.01.05

Осталось только выяснить о каких макросах идёт речь. В C тоже есть макросы, но, я надеюсь, что мы оба понимаем, что речь не о них.

Здравствуйте, AndrewVK, Вы писали:

IT>>Почему, например, расширение linq захардкоженное, прибитое гвоздями к C# и VB это хорошо, а набор макросов, делающий тоже самое — это плохо.

AVK>Потому что LINQ прописан в стандарте и его будет обязан знать каждый, претендующий на звание C# developer. И когда я уйду из одной команды и приду в другую, там будет все тот же самый LINQ.

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

IT>>Индустрия банально не имеет макросов, поэтому извращается как может.

AVK>Спорно. Идее ситаксических макросов 200 лет в обед. Однако ж не прижились пока что.

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

AVK>Это не проблема технических средств, это проблема организации процесса разработки.

Почему ты тогда считаешь, что его нельзя построить так, чтобы не было проблем с макросами?

AVK>У меня в текущем проекте масса pre-build и студийных кодогенераторов, однако за последние 4 года еще ни у кого не хватило ума править автогенеренный код, хотя уровень девелоперов был очень разный, вплоть до обезьянок.

А у моих ума хватило за полгода. Что теперь делать?

IT>>У run-time кодогенерации тоже есть свои козявки. Приходится использовать абстрактные классы, которые к тому же всегда должны быть публичные. Классы, которые не генерируются, но для которых что-то генерируется тоже должны обязательно быть публичными.

AVK>Это, мягко говоря, неправда. Skip visibility check еще никто не отменял.

Что неправда? То, что генератор, исходный класс и результирующий находятся в разных сборках? Ну так это я тебе как специалист говорю. Могу даже исходники показать.

G>Генерация — потому что ось представляла собой колоссальное количество макросов. Генерация состояла в том, что создавался пакет макровызовов с конкретными параметрами макросов. Для этого на компьютере была предустановлена минимальная система с транслятором-ассемблером (макроассемблером). Процесс генерации занимал несколько часов, потом ситему проверяли на работоспособность — та еще работа... Часто оказывалось, что параметры заданы не те или не так — не стыковались у некоторых макросов сочетания... И приходилось перегенерировать систему. Поэтому в системные программисты (а они как раз и занимались такой работой) старались брать людей, уже имевших опыт

это не синтаксические макросы (используемые для упрощения программирования), а система типа нынешнего configure

Здравствуйте, Gaperton, Вы писали:

G>В классе пространств, которые приводятся линейным преобразованием друг к другу (а это, как ты сказал, половина твоих преобразований),
А где я сказал что это один класс?

Лозунги не имеющие отношения к реальности поскипаны.

G>Также, для прямого оптимизированного перехода между двумя нелинейними пространствами (что надо делать по показаниям) — никто не мешает определить специализированный метод.
И что я с этим методом буду делать?
Это в моей системе я его просто напишу и запущу генератор.
А в твоей?

G>Необходимости в макросах я тут не вижу.
А я вижу.

G>Почему должна просесть точность и производительность — тоже не понимаю.
Долго расказывать.

G>А вот то, что применение макросов — это переусложнение — это понятно.
Это понятно только тебе. А я получил значительное сокращение и упрощение рукописного кода.
И стал он гораздо понятние ибо у меня остались одни декларации вместо кучи императива.

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

Здравствуйте, BulatZiganshin, Вы писали:

G>>Генерация — потому что ось представляла собой колоссальное количество макросов. Генерация состояла в том, что создавался пакет макровызовов с конкретными параметрами макросов. Для этого на компьютере была предустановлена минимальная система с транслятором-ассемблером (макроассемблером). Процесс генерации занимал несколько часов, потом ситему проверяли на работоспособность — та еще работа... Часто оказывалось, что параметры заданы не те или не так — не стыковались у некоторых макросов сочетания... И приходилось перегенерировать систему. Поэтому в системные программисты (а они как раз и занимались такой работой) старались брать людей, уже имевших опыт

BZ>это не синтаксические макросы (используемые для упрощения программирования), а система типа нынешнего configure

Это как раз синтаксические макросы. Речь идет о макроассемблере ЕС ЭВМ — великом и ужасном. Его "компилятор" с библиотеками занимал раза в полтора больше места, чем PL/1 (а это самый навороченный язык был). Про "С" в свое время говорили — это такая штука типа макроассемблера OS/360 — только переносимая?

G>Это как раз синтаксические макросы. Речь идет о макроассемблере ЕС ЭВМ

тогда может отгадка состоит в том, что в 80-х годах отказались от самого ассемблера?

Здравствуйте, WolfHound, Вы писали:

WH>ЗЫ Я с картинками почти год вожусь. За это время я прошолся по тАкому колличеству очень неочивидных граблей... Причем они нигде не описаны ибо практикам не до написания статей, а теоретики забивают на крайние случаи. Короче наивные методы не работают. Вобще.

А раз ты практик, то и от тебя мы статей, похоже, не дождемся?
Все практики, наверное, хранят потом и кровью добытые ноу хау при себе...

You will always get what you always got
  If you always do  what you always did

Здравствуйте, IT, Вы писали:

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

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

Тем же, чем отличается незнакомое русское слово в русской речи от речи, скажем, на турецком языке.

IT> Можно перефразировать в текущем контексте. Чем принципиально отличается необходимость разбираться в незнакомом коде, в котором используются незнакомые тебе классы от от кода, в котором используются незнакомые тебе макросы?

Тем, что возможые эффекты от метода несопоставимы с эффектами от макроса. Т.е. метод делает всегда одно и то же — получает на вход параметры, возможно меняет состояние, и возвращает результат. А вот макрос может делать за кадром что угодно, возможности у него значительно шире (собственно, для этого макросы и придумывали). Too big gun и этим все сказано.

AVK>>Спорно. Идее ситаксических макросов 200 лет в обед. Однако ж не прижились пока что.

IT>Интересно, почему тогда народ с таким самозабвением извращается на плюсовых шаблонах?

Спроси у них. Практически все мои лично знакомые программисты относятся к этому крайне негативно.

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

Т.е. всемирный антимакросовый заговор? И Гейтс, поди, не последнюю роль в нем играет?
Должны же быть какие то причины отсуствия макросов в мейнстриме.

AVK>>Это не проблема технических средств, это проблема организации процесса разработки.

IT>Почему ты тогда считаешь, что его нельзя построить так, чтобы не было проблем с макросами?

Зависит от масштаба применения макросов.

IT>А у моих ума хватило за полгода. Что теперь делать?

Учить, разумеется. ИМХО объяснить, что если в начале файла написано autogenerated, do not touch, то ни в коем случае этот файл не трогать совсем не сложно. В особо запущенных случаях можно для SVN скрипт написать, который запретит коммитить генерируемые файлы.

AVK>>Это, мягко говоря, неправда. Skip visibility check еще никто не отменял.

IT>Что неправда? То, что генератор, исходный класс и результирующий находятся в разных сборках? Ну так это я тебе как специалист говорю. Могу даже исходники показать.

А я тебе как специалист говорю — в случае применения для кодогенерации LWCG достаточно в параметре skipVisibilityCheck передать true, и можно спокойно обращаться к приватным полям любых классов в любой сборке.

Здравствуйте, Gaperton, Вы писали:

G>Также, для прямого оптимизированного перехода между двумя нелинейними пространствами (что надо делать по показаниям) — никто не мешает определить специализированный метод.

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