шаблоны С++ и дженерики С#
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 07.09.09 10:00
Оценка: 1 (1)
Пишу сюда, т.к. интересует мнение вменяемых апологетов сразу двух языков, чья концентрация превышает норму только здесь, в ФП.

В рамках участия в небольшом мирном холиварчике на внутрикорпоративном форуме на тему сабжа, мне выкатили пример использования шаблонов С++ для реализации "псевдо-наследования" в контексте "вот как ты это на шарпе с дженериками сделаешь?", как бы намекая на то, что в шарпе нельзя унаследовать дженерик от его же параметра-типа:

#include<iostream>

using namespace std;

template < class T > 
class Test : public T
{
    public:
        void Test1()
        {
            cout<<"Test1"<<endl;
        };
};

class Papa
{
    public:
        void Papa1()
        {
            cout<<"Papa1"<<endl;
        };
};

class Mama
{
    public:
        void Mama1()
        {
            cout<<"Mama1"<<endl;
        };
};

void main()
{
    Test<Papa> testPapa;
    testPapa.Papa1();
    testPapa.Test1();

    Test<Mama> testMama;
    testMama.Mama1();
    testMama.Test1();
}




в результате ковыряний в студии, я эмперически пришел вот к такому коду:

using System;

namespace Generics1
{
    class Test<T> where T : Test<T>, new()
    {
        public void Test1() {
            Console.WriteLine("Test1");
        }

        public T getInstance() {
            return new T();
        }
    }

    class Papa : Test<Papa>
    {
        public Papa() { }

        public void Papa1() {
            Console.WriteLine("Papa1");
        }
    }

    class Mama : Test<Mama>
    {
        public Mama() { }

        public void Mama1() {
            Console.WriteLine("Mama1");
        }
    }

    class Program
    {
        static void Main(string[] args) {
            var testPapa = new Test<Papa>().getInstance();
            testPapa.Test1();
            testPapa.Papa1();

            var testMama = new Test<Mama>().getInstance();
            testMama.Test1();
            testMama.Mama1();

            Console.ReadKey();
        }
    }
}


Собственно вопрос к местным гуру плюсов и шарпа : действительно ли приведенный шарповый код аналогичен плюсовому? Если нет, то в чем разница (кроме compile-time/runtime)?

И вопрос со звездочкой (я не знаю ответ): почему этот код вообще компилируется и тем более выполняется? (смущает, в основном, "class Test<T> where T : Test<T>")

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re: шаблоны С++ и дженерики С#
От: nikov США http://www.linkedin.com/in/nikov
Дата: 07.09.09 11:27
Оценка: 7 (1)
Здравствуйте, kochetkov.vladimir, Вы писали:

В C# действуют следующие правила:

10.1.4 Class base specification
A base class cannot be a type parameter on its own, though it can involve the type parameters that are in scope.

class Extend<V>: V {}            // Error, type parameter used as base class


10.1.5 Type parameter constraints
In either case, the constraint can involve any of the type parameters of the associated type or method declaration as part of a constructed type, and can involve the type being declared.

Re: шаблоны С++ и дженерики С#
От: 0x7be СССР  
Дата: 07.09.09 11:41
Оценка: +2
Здравствуйте, kochetkov.vladimir, Вы писали:


KV>Собственно вопрос к местным гуру плюсов и шарпа : действительно ли приведенный шарповый код аналогичен плюсовому? Если нет, то в чем разница (кроме compile-time/runtime)?


Как минимум есть такая разница: в плюсовом коде классы Pama & Mama "ничего не знают" о шаблоне Test, в то время
как в шарповой версии вносится зависимость.

Плюс еще то, что количество экземпляров Test<T> в шарповом коде больше: та, которая явно создается через new и та, которая создается как база класса Pama/Mama.

Насчёт легальности указанного ограничения — что не запрещено, то разрешено!
Re: шаблоны С++ и дженерики С#
От: jazzer Россия Skype: enerjazzer
Дата: 07.09.09 13:03
Оценка: 14 (1)
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Собственно вопрос к местным гуру плюсов и шарпа : действительно ли приведенный шарповый код аналогичен плюсовому? Если нет, то в чем разница (кроме compile-time/runtime)?


Нет, не аналогичен, он аналогичен трюку CRTP (Curiously Recurring Template Pattern), это немножко другое.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[2]: шаблоны С++ и дженерики С#
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 07.09.09 13:55
Оценка: 8 (1) :)
Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, kochetkov.vladimir, Вы писали:



KV>>Собственно вопрос к местным гуру плюсов и шарпа : действительно ли приведенный шарповый код аналогичен плюсовому? Если нет, то в чем разница (кроме compile-time/runtime)?


0>Как минимум есть такая разница: в плюсовом коде классы Pama & Mama "ничего не знают" о шаблоне Test, в то время

0>как в шарповой версии вносится зависимость.

В ответ на аналогичный аргумент, я отправил коллеге вот такой код:

using System;
using System.Collections.Generic;
using System.Reflection;

namespace Generics2
{
    public class MultipleInheritedObject
    {
        private Dictionary<Type, Object> _mixins = new Dictionary<Type, Object>();

        public MultipleInheritedObject(params Type[] mixins)
        {
            foreach (Type type in mixins)
                _mixins.Add(type, Activator.CreateInstance(type));
        }

        public Interface As<Interface>()
        {
            Object implementation;
            if (_mixins.TryGetValue(typeof(Interface), out implementation))
                return (Interface)implementation;
            throw new System.InvalidCastException();
        }
    }

    class Test : MultipleInheritedObject
    {
        public Test(params Type[] mixins) : base(mixins) { }

        public void Test1()
        {
            Console.WriteLine("Test1");
        }
    }

    class Papa
    {
        public Papa() { }

        public void Papa1()
        {
            Console.WriteLine("Papa1");
        }
    }

    class Mama
    {
        public Mama() { }

        public void Mama1()
        {
            Console.WriteLine("Mama1");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var test = new Test(typeof(Papa), typeof(Mama));

            test.Test1();
            test.As<Papa>().Papa1();
            test.As<Mama>().Mama1();

            Console.ReadKey();
        }
    }
}


и никаких тебе зависимостей, почти...

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[3]: шаблоны С++ и дженерики С#
От: jazzer Россия Skype: enerjazzer
Дата: 07.09.09 14:19
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>В ответ на аналогичный аргумент, я отправил коллеге вот такой код:


Чем-то он мне неуловимо Python напоминает
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[3]: шаблоны С++ и дженерики С#
От: 0x7be СССР  
Дата: 07.09.09 15:57
Оценка: +1
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>В ответ на аналогичный аргумент, я отправил коллеге вот такой код:

KV> ...
KV>и никаких тебе зависимостей, почти...
Ну, есть там к чему придраться, если честно. Но дело не в этом.
В чем главное различие дженериков и шаблонов, если не вдаваться в тонкости их реализации?
Различие состоит в том, что шаблоны обеспечивают "compile time duck typing", а дженерики — нет.
Отсюда и разница в их возможностях. При этом .NET обладаем всеми необходимыми компонентами, что бы смоделировать эту функциональность в том или ином виде. То, что Вы написали — один их возможных шагов к этому
Re: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.09 19:20
Оценка: 11 (3) +2 -5
Здравствуйте, kochetkov.vladimir, Вы писали:

Скажу так. Это глупый спор.

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

Да, полноценного множественного наследования (МН) на дженериках не реализовать. Но так же точно на шаблонах нельзя реализовать даже что-то похожее на компонентность.

Правильный ответ на притязания С++-ников — в языках с дженериками надо использовать другие паттерны, другие подходы, другие идеомы. Однако С++-ники никогда не поймут этого, так как они мыслят паттернами характерными для С++, которые заучены ими за долгую (или не очень) практику программирования на этом языке.

Проблему МН можно было бы решить добавив в язык пару/тройку расширений. Например, миксины. То как это может выглядеть можно поглядеть в Scala. Там аналогичная возможность называется traits
Автор(ы): Билл Веннерс, Мартин Одерски, Лекс Спун
Дата: 30.07.2007
Scala – статически типизированный, объектно-ориентированный язык программирования, в котором смешиваются императивный и функциональный стили программирования. Одна из причин заинтересоваться программированием на Scala, состоит в том, что Scala позволяет увеличить производительность разработчика по сравнению с Java, сохраняя скорость исполнения JVM, существующие инвестиции в Java-код, знания и множество API, имеющихся для JVM. Scala обладает краткостью языков типа Ruby или Python, но при этом статически типизирована, как и Java.
. Это более узкое нежели МН решение, но оно отлично решает задачу добавления функционала к классу (и не создает при этом проблем). А именно эта задача обычно приводится сторонниками МН в качестве аргумента.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: шаблоны С++ и дженерики С#
От: Константин Б. Россия  
Дата: 10.09.09 10:33
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

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


KV>В рамках участия в небольшом мирном холиварчике на внутрикорпоративном форуме на тему сабжа, мне выкатили пример использования шаблонов С++ для реализации "псевдо-наследования" в контексте "вот как ты это на шарпе с дженериками сделаешь?", как бы намекая на то, что в шарпе нельзя унаследовать дженерик от его же параметра-типа:


А какая практическая польза от такого трюка?
Re[2]: шаблоны С++ и дженерики С#
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 10.09.09 13:17
Оценка:
Здравствуйте, Константин Б., Вы писали:

КБ>Здравствуйте, kochetkov.vladimir, Вы писали:


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


KV>>В рамках участия в небольшом мирном холиварчике на внутрикорпоративном форуме на тему сабжа, мне выкатили пример использования шаблонов С++ для реализации "псевдо-наследования" в контексте "вот как ты это на шарпе с дженериками сделаешь?", как бы намекая на то, что в шарпе нельзя унаследовать дженерик от его же параметра-типа:


КБ>А какая практическая польза от такого трюка?


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

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[3]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.09.09 14:41
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

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


Ну, а тогда какой смысл влезать в подобный спор?

У Карслона, по-моему, было замечательное высказывание:

Не на все вопросы, малыш, можно однозначно ответить "да" или "нет". Вот например — "Ты уже бросил пить коньяк по утрам?".


Точно так же и тут. На такие притязания нельзя дать прямой правильный ответ.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: от модератора
От: Кодт Россия  
Дата: 10.09.09 16:32
Оценка: 10 (1) +5
VD>Правильный ответ на притязания С++-ников — в языках с дженериками надо использовать другие паттерны, другие подходы, другие идеомы. Однако С++-ники никогда не поймут этого, так как они мыслят паттернами характерными для С++, которые заучены ими за долгую (или не очень) практику программирования на этом языке.
Напоминаю закон нетикета: отучаемся говорить за всех.
Любой дальнейший флейм на эту тему, по шаблону "дурак-самдурак-вседураки" будет пресекаться, возможно, жестоко.
http://files.rsdn.org/4783/catsmiley.gif Перекуём баги на фичи!
Re[2]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.09.09 17:35
Оценка: -2
Здравствуйте, VladD2, Вы писали:

VD>Однако С++-ники никогда не поймут этого, так как они мыслят паттернами характерными для С++, которые заучены ими за долгую (или не очень) практику программирования на этом языке.


Поясню тем, кто не понял это самостоятельно, что я понимаю под термином С++-ник.

С++-ник — это не человек хорошо владеющий С++ или просто умеющий писать на нем.
С++-ник это человек знающий (не важно как) С++, и только его!
С++-ник человек думающий исключительно терминами С++ и воспринимающий все программирование через его призму.

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

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

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

Посему когда я говорю "Однако С++-ники никогда не поймут этого, так как они мыслят паттернами характерными для С++" я не говорю за всех кто знает С++, а просто констатирую факт особенности человеческого мышления.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: шаблоны С++ и дженерики С#
От: Кодт Россия  
Дата: 10.09.09 20:01
Оценка: 11 (1) +3 :)
Здравствуйте, VladD2, Вы писали:

VD>Поясню тем, кто не понял это самостоятельно, что я понимаю под термином С++-ник.

<...>

Ну а стоит ли устраивать бой с тенью? Сперва неявно ввёл воображаемого оппонента, а потом начал наголову его громить.
Да ещё и весьма произвольно использовал термин.

"Тракторист — это не тот, кто умеет водить трактор; и не тот, кто зарабатывает вождением трактора; это человек, которому всюду мерещатся трактора — от феррари до аэробуса".

Немудрено, что профессиональные С++ники "не поняли".

Ладно; определённость — пусть даже несколько неожиданная — появилась, можем в эту сторону не развивать разговор.
http://files.rsdn.org/4783/catsmiley.gif Перекуём баги на фичи!
Re[4]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.09.09 20:41
Оценка: -1
Здравствуйте, Кодт, Вы писали:

К>Ну а стоит ли устраивать бой с тенью? Сперва неявно ввёл воображаемого оппонента, а потом начал наголову его громить.

К>Да ещё и весьма произвольно использовал термин.

На мой взгляд термин в самый рез. Он же не один в поле использован? Он в контексте использован.

К>"Тракторист — это не тот, кто умеет водить трактор; и не тот, кто зарабатывает вождением трактора; это человек, которому всюду мерещатся трактора — от феррари до аэробуса".


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

К>Ладно; определённость — пусть даже несколько неожиданная — появилась, можем в эту сторону не развивать разговор.


+1
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 22.09.09 05:50
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Да, полноценного множественного наследования (МН) на дженериках не реализовать. Но так же точно на шаблонах нельзя реализовать даже что-то похожее на компонентность.


Что ты несёшь... заблуждения в массы? Компонентность реализуется инфраструктурой, а не классами, шаблонами или дженериками. Инфраструктурой и сопутствующими соглашениями. Нету инфраструктуры — нету компонентности. Есть инфраструктура — будет тебе компонентность хоть на бейсике.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: шаблоны С++ и дженерики С#
От: Хвост  
Дата: 22.09.09 09:50
Оценка: +1 -2
Здравствуйте, VladD2, Вы писали:

VD>Правильный ответ на притязания С++-ников — в языках с дженериками надо использовать другие паттерны, другие подходы, другие идеомы. Однако С++-ники никогда не поймут этого, так как они мыслят паттернами характерными для С++, которые заучены ими за долгую (или не очень) практику программирования на этом языке.


простите барин, это бред.

P.S.
и не надо строить из себя интеллект. Лично по твоим постам (и по твоим мегаисходникам столетней давности в которых ты осилил RAII в С++ и смог обернуть хендлы win32) у меня абсолютно стойкое убеждение что ты С++ знаешь максимум на уровне "Си с классами". Т.к. других сведений о твоей компетенции в С++ у меня нет, то и слушать твои росказни о С++(никах) нет желания.

P.P.S.
и напоследок, у тебя клёвая идеология. То что есть в С++ и С++ники указывают на отсутствие этого в других языках это по-твоему "закостенелость сознания, неумение видить другие идиомы, подходы". Зато с обратной стороны ты готов ... изойтись указывая на то что отсутствует в С++. Может ты просто не умеешь использовать "другие паттерны, другие подходы" ?
People write code, programming languages don't.
Re[4]: шаблоны С++ и дженерики С#
От: ZevS Россия  
Дата: 22.09.09 15:01
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>

VD>Не на все вопросы, малыш, можно однозначно ответить "да" или "нет". Вот например — "Ты уже бросил пить коньяк по утрам?".


Да.

VD>На такие притязания нельзя дать прямой правильный ответ.


Нет.

Шутка.
Re[3]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.09.09 16:22
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Что ты несёшь... заблуждения в массы?


Тебе это только кажется.

ГВ>Компонентность реализуется инфраструктурой, а не классами, шаблонами или дженериками. Инфраструктурой и сопутствующими соглашениями. Нету инфраструктуры — нету компонентности. Есть инфраструктура — будет тебе компонентность хоть на бейсике.


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

Дженерике же проектировались с расчетом на компонентные решения.

В общем, сам ты несешь... заблуждения в массы. Наличие COM-а а так же разных ATL-ов и расширений MFC четко демонстрирует, что сам язык не компонентный и ему требуется "инфрастркутура" (читай, костыли) чтобы добиться оной.
Когда же язык и его рантайм исходно поддерживают компонентность, то костыли не требуются. Любой класс является компонентом и может быть использован в рантайме без дополнительных приседаний.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 23.09.09 06:12
Оценка: -1 :)
Здравствуйте, VladD2, Вы писали:

ГВ>>Компонентность реализуется инфраструктурой, а не классами, шаблонами или дженериками. Инфраструктурой и сопутствующими соглашениями. Нету инфраструктуры — нету компонентности. Есть инфраструктура — будет тебе компонентность хоть на бейсике.

VD>Как раз бэйсике она была заложена в язык начиная с 3-ей версии.

Угу, на основе инфраструктуры COM.

VD>А вот в С++ компонентности не было, нет и, похоже, уже не будет.


И это есть хорошо и хорошо весьма. Поскольку выбор компонентных инфраструктур весьма велик. В общем, в этом и прелесть C++ по сравнению с навороченными вагонами всех-правильных-практик в одном флаконе. (Язвительне комментарии по поводу того, что в C++ совсем нет правильных практик ==> /dev/null/please)

VD>Дженерике же проектировались с расчетом на компонентные решения.


Читай: в расчёте на инфраструктуру .Net.

VD>В общем, сам ты несешь... заблуждения в массы. Наличие COM-а а так же разных ATL-ов и расширений MFC четко демонстрирует, что сам язык не компонентный и ему требуется "инфрастркутура" (читай, костыли) чтобы добиться оной.


COM — это одна из возможных инфрастуктур. Понимаешь? Одна из мириад возможных. Чтобы ввести в язык "компонентность" сначала необходим некоторый набор соглашений, соответствующий этой самой инфраструктуре. Что за чем создаётся, что чем управляет, кто кому и как сигналит и т.п. Любая ОС — это компонентная инфраструктура, кстати (соглашения о формате файлов, о файловых системах и т.п.). Отсюда мораль: COM-приблуды MFC, ATL и вся остальная требуха свидетельствует только о том, что C++ может поддерживать, в числе прочих и такую компонентную инфраструктуру (привет капитану Очевидность).

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


Угу, угу. Осталось только уточнить, какая именно компонентность полагается самой правильной — вплоть до ABI.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[4]: шаблоны С++ и дженерики С#
От: snaphold  
Дата: 23.09.09 06:15
Оценка:
А скажите для несведующих, что имеется ввиду под фразой

VD>А вот в С++ компонентности не было, нет и, похоже, уже не будет.


и под этой

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


Спасибо
Re[5]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.09.09 12:52
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

VD>>Как раз бэйсике она была заложена в язык начиная с 3-ей версии.


ГВ>Угу, на основе инфраструктуры COM.


А не странно, что с помощью препроцессора к С Страуструп создал С++, а помощью полноценного отдельного компилятора-генератора кода (midl) получается всего лишь инфраструктура? Мидл и из С делает "компонентный язык".

VD>>А вот в С++ компонентности не было, нет и, похоже, уже не будет.


ГВ>И это есть хорошо и хорошо весьма.


Агащазблин.

ГВ> Поскольку выбор компонентных инфраструктур весьма велик.


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

ГВ> В общем, в этом и прелесть C++ по сравнению с навороченными вагонами всех-правильных-практик в одном флаконе.


Как отсутствие чего-то может быть преимуществом? Другие языки и технологии точно так же могут подерживать разные ифраструктуры и т.п. Делать это или нет определяется исключительно необходимостью оных. Скажем то что в дотнет встроена поддержка COM-а не запрещает использовать дотнет в Корба-приложениях.

ГВ>(Язвительне комментарии по поводу того, что в C++ совсем нет правильных практик ==> /dev/null/please)


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

VD>>Дженерике же проектировались с расчетом на компонентные решения.


ГВ>Читай: в расчёте на инфраструктуру .Net.


Не читай. Дженерики — это весьма абстрактное проектное решение. То что они были разработаны для платформы CLI (они, между прочем поддерживаются в Моно ни чем не хуже) ни как не мешает использованию их в других языках. Та же Ява имеет очень похожее решение.

VD>>В общем, сам ты несешь... заблуждения в массы. Наличие COM-а а так же разных ATL-ов и расширений MFC четко демонстрирует, что сам язык не компонентный и ему требуется "инфрастркутура" (читай, костыли) чтобы добиться оной.


ГВ>COM — это одна из возможных инфрастуктур. Понимаешь?


Понимаю. Но понимаю и то, что родилась она (как и альтернатива, коих кот наплакал) в основном потому, что в С++ не было нужных возможностей.
Обратимся к близкой аналогии к C API. До его укоренения в качестве стандарта де-факто ведь была туча других языков каждый из которых имел схожий процедурный API. Можно было создать много разных стандартов и балдеть от наличия альтернативы. Только вот в данном случае наличие альтернативы — это зло! C API победил и всем от этого хорошо. И это при том, что C API — это весьма кривое и не полноценное решение. Скажем, такие вопросы как безопасность данных/памяти в нем вообще не рассматривается. При этом С++ который, казалось бы, на голову круче так и не смог предложить ничего стандартного. Теперь обратимся к DLL. Это — корпоративный стандарт Майкрософта. Он конечно хорош для своих целей. Но плох он в первую очередь тем, что не коросплатформен. В линукс свои динамические библиотеки где-то еще — свои. Кроме того формат не предлагает никаких решений для переноса кода в машинах/СО с разной разрядностью.
Теперь вернемся к сборкам дотнета. Точнее к сборкам CLI. Это своего рода такой же стандарт библиотек заменяющий C API, DLL, SO и т.п. Он переносим между платформами. Модуль скомпилированный с помощью Моно можно запустить на Windows 7, Windows Mobile, Linux, FreeBSD и т.д. Нет никаких проблем если целевая платформа отличается разрядностью. Главное чтобы для нее существовала виртуальная машина.
В общем, это идеальный API. Ну, а для связи с предыдущими API существуют поддержка тех самых C API, COM-а, Корбы и т.п.

ГВ>Одна из мириад возможных.


Ерунду говоришь.
Перечисли, плиз эти мириады. Увидишь, что их все на пальцах одной руки посчитать можно. Более того. Основная часть — это сабсэты COM-а. Скажем тот же XCOM — это фактически COM абстрагированный от "инфраструктуры" МС и упрощенный до предела. Особняком стоит Корба. Но она вымирает.

И это не просто так. COM ко всему прочему — это интерфейс взаимодействия программ. А тут стандартны намного важнее чем конкуренция.

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


Ты пошел не в ту степь. Любой стандарт — это соглашения. Компонентный или нет уже не важно.

ГВ>Любая ОС — это компонентная инфраструктура, кстати (соглашения о формате файлов, о файловых системах и т.п.). Отсюда мораль: COM-приблуды MFC, ATL и вся остальная требуха свидетельствует только о том, что C++ может поддерживать, в числе прочих и такую компонентную инфраструктуру (привет капитану Очевидность).


ОС есть ОС. Она так же стандарт, но компонентной она быть не обязана. Отличный прмер — MS DOS. Большая часть возможностей встроена в ядро.

ГВ>Угу, угу. Осталось только уточнить, какая именно компонентность полагается самой правильной — вплоть до ABI.


Компетентность нужна для самих программ. И им по фигу как она получена. Главное чтобы по проще.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.09.09 15:07
Оценка:
Здравствуйте, snaphold, Вы писали:

S>А скажите для несведующих, что имеется ввиду под фразой


VD>>А вот в С++ компонентности не было, нет и, похоже, уже не будет.


То что сказано. Если это непонятно, то наверно стоит начать с общих сведений о компонентах и КООП:
http://en.wikipedia.org/wiki/Component-oriented_programming

С++ не имеет встроенных средств поддержки КООП. В нем нет таких понятий как:
1. Отчуждаемые модули которые можно передавать в бинарном виде и из которых можно создавать экзепляры классов (компонентов).
2. Системы динамического создания экзепляров. Тип создаваемого объекта должен быть известен заранее.
3. Метаинформации позволяющей выявлять наличие компонентов и анализировать их свойства (возможности).

Для решения этих проблем были созданы разные технологии. Самая известная из них — это MS COM.

S>и под этой


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


Опять же то что написано. Все перечисленные возможности уже встроены в язык и его рантайм. Скажем в дотнете и яве можно:
1. Размещать код компонентов в отдельных модулях (сорки дотнета и jar-архивы явы и class-файлы).
2. Экземпляры типом можно создавать на основании их текстовых имен или другой информаци.
3. О каждом типе и модуле можно получить исчерпывающую информацию даже если нет их исходников.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: шаблоны С++ и дженерики С#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.09.09 20:02
Оценка: +1
Здравствуйте, Хвост, Вы писали:

Х>и не надо строить из себя интеллект. Лично по твоим постам (и по твоим мегаисходникам столетней давности в которых ты осилил RAII в С++ и смог обернуть хендлы win32) у меня абсолютно стойкое убеждение что ты С++ знаешь максимум на уровне "Си с классами". Т.к. других сведений о твоей компетенции в С++ у меня нет, то и слушать твои росказни о С++(никах) нет желания.


Продолжишь обсуждать квалификацию собеседника, тем более в таком тоне — получишь по шапке, уж извини.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[6]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.09.09 02:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Как раз бэйсике она была заложена в язык начиная с 3-ей версии.

ГВ>>Угу, на основе инфраструктуры COM.
VD>А не странно, что с помощью препроцессора к С Страуструп создал С++, а помощью полноценного отдельного компилятора-генератора кода (midl) получается всего лишь инфраструктура? Мидл и из С делает "компонентный язык".

Ничего странного не вижу. MIDL не делает из C "компонентный язык" (к счастью). MIDL помогает подвязать COM API к программам на C. Компонентным от этого C не становится (обратно таки — это хорошо).

ГВ>> Поскольку выбор компонентных инфраструктур весьма велик.

VD>А что в этом хорошего? Компонентность нужна сама по себе. А инфраструктура она нужна только потому, что без нее нельзя. В общем, костыли они и есть остыли.

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

ГВ>> В общем, в этом и прелесть C++ по сравнению с навороченными вагонами всех-правильных-практик в одном флаконе.

VD>Как отсутствие чего-то может быть преимуществом?

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

VD>Другие языки и технологии точно так же могут подерживать разные ифраструктуры и т.п. Делать это или нет определяется исключительно необходимостью оных. Скажем то что в дотнет встроена поддержка COM-а не запрещает использовать дотнет в Корба-приложениях.


Конечно же не запрещает. Только если мне понадобится исключительно корба, то я выбирать буду между Java и C++, а отнюдь не между C# и F#. С другой стороны, если будет предполагаться обилие COM, то выбор будет из C++ и C#. А вот если потребуется и то, и другое и ещё что-то третье... Ну ты понял. И произойдёт это ровно потому, что C++ не содержит каких-то встроенных "компонентизирующих" средств, которые, к тому же, нельзя оторвать от языка.

VD>>>Дженерике же проектировались с расчетом на компонентные решения.

ГВ>>Читай: в расчёте на инфраструктуру .Net.
VD>Не читай. Дженерики — это весьма абстрактное проектное решение. То что они были разработаны для платформы CLI (они, между прочем поддерживаются в Моно ни чем не хуже) ни как не мешает использованию их в других языках. Та же Ява имеет очень похожее решение.

Угу, ключевое слово — "похожее". Только не надо говорить, что дженерики CLI проектировались в расчёте на JVM. И тогда зачем тут вообще Java упоминать?

VD>>>В общем, сам ты несешь... заблуждения в массы. Наличие COM-а а так же разных ATL-ов и расширений MFC четко демонстрирует, что сам язык не компонентный и ему требуется "инфрастркутура" (читай, костыли) чтобы добиться оной.

ГВ>>COM — это одна из возможных инфрастуктур. Понимаешь?
VD>Понимаю. Но понимаю и то, что родилась она (как и альтернатива, коих кот наплакал) в основном потому, что в С++ не было нужных возможностей.

Ага, и поэтому не только унаследовала от C++ такую штуку, как VMT, но ещё и прямо заявлялась всегда как инфраструктура взаимодействия программ на разных языках, а отнюдь не как метод борьбы мифическими недостатками C++. Влад, по-моему только ты всё время борешься с C++ за светлое будущее.

VD>Обратимся к близкой аналогии к C API. До его укоренения в качестве стандарта де-факто ведь была туча других языков каждый из которых имел схожий процедурный API. Можно было создать много разных стандартов и балдеть от наличия альтернативы. Только вот в данном случае наличие альтернативы — это зло! C API победил и всем от этого хорошо. И это при том, что C API — это весьма кривое и не полноценное решение. Скажем, такие вопросы как безопасность данных/памяти в нем вообще не рассматривается.


Ну ты смешал всё в одну кучу... Во-первых, не надо путать интерфейс взаимодействия программы на языках X и Y (коих может быть N^2/2, где N — общее количество языков), и обобщённый интерфейс взаимодействия программ (коих, само собой, много меньше, но и то они друг с другом перегрызутся). Они решают несколько разные задачи.

Во-вторых, ключевые "соглашения C API" оговаривают только одну вещь в смысле управления ресурсами — кто и когда освобождает стек после вызова (не считая имени точки входа). Просто и понятно, может запросто поддерживаться микропроцессорами. Потому, вероятно, API с бинарным интерфейсом в стиле C и распространились так широко — они практически ничего не требуют для своей реализации: нужно только очистить стек от помещённых туда параметров после вызова процедуры. Всё остальное — дело взаимодействующих программ: политика управления памятью, соглашения о порядке вызова, согласование жизненных циклов данных и всё, что заблагорассудится. Ключевой момент, без которого ни хрена работать не будет, то есть бинарное согласование — проще некуда.

VD>При этом С++ который, казалось бы, на голову круче так и не смог предложить ничего стандартного.


Ну скажем так, интеловский ABI, он всё же есть.

VD>Теперь обратимся к DLL. Это — корпоративный стандарт Майкрософта. Он конечно хорош для своих целей. Но плох он в первую очередь тем, что не коросплатформен. В линукс свои динамические библиотеки где-то еще — свои. Кроме того формат не предлагает никаких решений для переноса кода в машинах/СО с разной разрядностью.


Хорош-плох, это всегда очень спорная дихотомия. DLL так или иначе связаны с Майкрософтовскими ОС в силу требований к бинарному формату, это верно. Но также очевидно, что для того, чтобы DLL можно было переносить между разными ОС (от MS и нет), необходима всего лишь поддержка со стороны загрузчиков библиотек. Теоретически нет никакой проблемы в загрузке DLL под Unix-ом или любой другой гипотетической ОС, которая работает на интеловском процессоре, если сама эта библиотека не привязана к другим библиотекам, существующим только в Windows. По сути библиотека — это просто размеченный файл с машинным кодом. Поддержать его загрузку можно без особых проблем, если, конечно, не слишком озабочиваться вопросами "мирового зла", исходящего от Майкрософт.

VD>Теперь вернемся к сборкам дотнета. Точнее к сборкам CLI. Это своего рода такой же стандарт библиотек заменяющий C API, DLL, SO и т.п.


Заменяющий? Чёрта-с-два он заменяет. Он использует эти самые DLL, SO и т.п. Вот когда .Net будет работать сам по себе, тогда и будет что-то заменять. Тут скорее уместно упомянуть явовские JAR-ы.

VD>Он переносим между платформами. Модуль скомпилированный с помощью Моно можно запустить на Windows 7, Windows Mobile, Linux, FreeBSD и т.д. Нет никаких проблем если целевая платформа отличается разрядностью. Главное чтобы для нее существовала виртуальная машина.


Правильно. Виртуальная машина — тоже часть инфраструктуры.

VD>В общем, это идеальный API. Ну, а для связи с предыдущими API существуют поддержка тех самых C API, COM-а, Корбы и т.п.


Объектный API "идеальным" не может быть по определению своей "объектности", то есть большого количества сопутствующих соглашений. Подтверждением тому — альтернатива в виде JAR-файлов и байт-кода явы. Кто из них идеальней — оставим этот вопрос за скобками, меня он, во всяком случае, не колышет.

ГВ>>Одна из мириад возможных.

VD>Ерунду говоришь.
VD>Перечисли, плиз эти мириады. Увидишь, что их все на пальцах одной руки посчитать можно.

Не перечислю. Мне для своих-то собственных моделей пальцев на обоих руках не хватит.

VD>Более того. Основная часть — это сабсэты COM-а. Скажем тот же XCOM — это фактически COM абстрагированный от "инфраструктуры" МС и упрощенный до предела.


Так XCOM своего наследия от COM и не скрывает. А ещё есть XPCOM от Mozilla, а ещё есть GObject из GTK+. Он тоже похож в чём-то на COM-овский объект, но ведь даже не C++-ный.

VD>Особняком стоит Корба. Но она вымирает.


Корба вымирает? Это новость. Пруфлинк не дашь?

VD>И это не просто так.


Угу, и даже причина понятна: концепция объектного интерфейса, почти повсеместно положенная в основу компонентной инфраструктуры. Потому распространённые компонентные инфраструктуры можно в той или иной степени уподобить COM. Кто у кого что позаимствовал сейчас уже не разберёшься.

VD>COM ко всему прочему — это интерфейс взаимодействия программ. А тут стандартны намного важнее чем конкуренция.


Вот именно, что борьба с недостатками C++ — это как раз прочее, по большей части вымышленное. В основном COM — интерфейсная технология для разных языков.

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

VD>Ты пошел не в ту степь. Любой стандарт — это соглашения. Компонентный или нет уже не важно.

Так вопрос как раз в том, что именно стандартизировать под обложкой "стандарта языка". Компонентные соглашения — они как бы "за пределами" языка вообще, поскольку определяют работу программ, написанных на этом языке. Очевидно, что язык влияет на соглашения о взаимодействии программ, но если сделать наоборот, то мы мистическим образом получаем язык, зависящий от компонентной инфраструктуры. Примеры ты сам хорошо знаешь: Оберон, Java, C#...

ГВ>>Любая ОС — это компонентная инфраструктура, кстати (соглашения о формате файлов, о файловых системах и т.п.). Отсюда мораль: COM-приблуды MFC, ATL и вся остальная требуха свидетельствует только о том, что C++ может поддерживать, в числе прочих и такую компонентную инфраструктуру (привет капитану Очевидность).

VD>ОС есть ОС. Она так же стандарт, но компонентной она быть не обязана. Отличный прмер — MS DOS. Большая часть возможностей встроена в ядро.

Плохой пример — DOS. Из-за достославного INT 21H И ещё из-за обилия резидентных программ. ОС, которая пишется для поддержки прикладного программирования (а больше она ни для чего не нужна), вообще не может быть в том или ином смысле "не компонентной". Вопрос только в том, какие обязанности она делегирует загружаемым программам. Короче, это всё совпадает с компонентной инфраструктурой "с точностью до изоморфизма". Там — порядок управления ресурсами, тут — порядок управления ссылками и т.п.

ГВ>>Угу, угу. Осталось только уточнить, какая именно компонентность полагается самой правильной — вплоть до ABI.

VD>Компетентность нужна для самих программ. И им по фигу как она получена. Главное чтобы по проще.

Я сказал не "кому?", а "какая?" Давай без абстракций менеджерского пошиба. И кстати, о том, что "проще всего" я тут уже выше высказался.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: ошибка
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.09.09 03:16
Оценка:
ГВ>интерфейс взаимодействия программы на языках X и Y (коих может быть N^2/2, где N — общее количество языков)

Хе-хе, N^2-N, разумеется, если считать, что средства взаимодействия встраиваются в соответствующие языки.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: Довесок
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.09.09 03:34
Оценка:
Здравствуйте, VladD2, Вы писали:

S>>А скажите для несведующих, что имеется ввиду под фразой

VD>>>А вот в С++ компонентности не было, нет и, похоже, уже не будет.

VD>То что сказано. Если это непонятно, то наверно стоит начать с общих сведений о компонентах и КООП:

VD>http://en.wikipedia.org/wiki/Component-oriented_programming

Я уж от себя добавлю, для полноты картины: http://www.rsdn.ru/forum/philosophy/133200.1.aspx
Автор: Геннадий Васильев
Дата: 17.11.02


Обрати внимание на дату.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: шаблоны С++ и дженерики С#
От: FR  
Дата: 24.09.09 06:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Теперь вернемся к сборкам дотнета. Точнее к сборкам CLI. Это своего рода такой же стандарт библиотек заменяющий C API, DLL, SO и т.п. Он переносим между платформами. Модуль скомпилированный с помощью Моно можно запустить на Windows 7, Windows Mobile, Linux, FreeBSD и т.д. Нет никаких проблем если целевая платформа отличается разрядностью. Главное чтобы для нее существовала виртуальная машина.

VD>В общем, это идеальный API. Ну, а для связи с предыдущими API существуют поддержка тех самых C API, COM-а, Корбы и т.п.

Для C++ и других нативных языков такая среда тоже уже есть http://llvm.org/
В общем-то есть большой шанс что она станет еще одной крупной платформой.
Re[7]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.09.09 14:01
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:
VD>>Как отсутствие чего-то может быть преимуществом?

ГВ>Хламу меньше. И меньше встроенных ограничений.


Ты сам то часто писал КОМ-объекты на С?
Хламу там получается ужас сколько. И это по сравнению с чем? С тем, что просто любой объект дотнета — это уже автоматом компонент!
Для С++ для борьбы с халмом были разработаны библоитеки которые все равно не смогли полностью скрыть хлам от разработчика. В Дельфи и дотнете поддержку кома встроели в рантайм и языки. Результа — писать КОМ-объекты на Дельфи или ВБ в десятки раз проще чем на С++.

ГВ>ИМХО, возможность ограниченными усилиями реализовать тот же интерфейс средствами имеющегося языка куда как лучше, чем необходимость метаться между наилучшими инфраструктурами и подвязанными к ним языками, решая нерешаемую задачу выбора самой-самой подходящей для всех-всех случаев.


Не ограниченными возможностями. А костылями, да еще и с огромной болью в заднице.

ГВ>Конечно же не запрещает. Только если мне понадобится исключительно корба, то я выбирать буду между Java и C++, а отнюдь не между C# и F#.


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

ГВ> С другой стороны, если будет предполагаться обилие COM, то выбор будет из C++ и C#. А вот если потребуется и то, и другое и ещё что-то третье... Ну ты понял. И произойдёт это ровно потому, что C++ не содержит каких-то встроенных "компонентизирующих" средств, которые, к тому же, нельзя оторвать от языка.


А зачем отрывать средства от языка? Ты пишешь не программу на С++, а просто программу. Если язык или рантайм позволяет решить стоящие перед тобой задачи максимально просто, то разумно этим воспользоваться, а не тянуть черти-что с боку бантик (например, корбу) обосновывая это какими-то там идеями вроде универсальности стандарта.

ГВ>Угу, ключевое слово — "похожее". Только не надо говорить, что дженерики CLI проектировались в расчёте на JVM. И тогда зачем тут вообще Java упоминать?


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

VD>>Понимаю. Но понимаю и то, что родилась она (как и альтернатива, коих кот наплакал) в основном потому, что в С++ не было нужных возможностей.


ГВ>Ага, и поэтому не только унаследовала от C++ такую штуку, как VMT, но ещё и прямо заявлялась всегда как инфраструктура взаимодействия программ на разных языках, а отнюдь не как метод борьбы мифическими недостатками C++. Влад, по-моему только ты всё время борешься с C++ за светлое будущее.


Дык это аргумент против твоей теории. Сам видишь, что для разработки универсального компонентного АПИ были взяты средства специфичные для конкретного языка, что сделано другие языки спроектированные без расчета на КОМ менее удобными для использования КОМ-а. В дальнейшем все языки которым было важно поддерживать КОМ тем или иным образом включили в себя поддержку аналога ВМТ. Только С эмулирует его на массивах.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: шаблоны С++ и дженерики С#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.09.09 14:43
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Что ты несёшь... заблуждения в массы? Компонентность реализуется инфраструктурой, а не классами, шаблонами или дженериками.


Коль скоро так — продемонстрируй дженерик СОМ интерфейс, чтобы он был доступен из любого клиента СОМ именно как дженерик.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[8]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.09.09 15:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Как отсутствие чего-то может быть преимуществом?

ГВ>>Хламу меньше. И меньше встроенных ограничений.
VD>Ты сам то часто писал КОМ-объекты на С?
VD>Хламу там получается ужас сколько. И это по сравнению с чем? С тем, что просто любой объект дотнета — это уже автоматом компонент!

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

VD>Для С++ для борьбы с халмом были разработаны библоитеки которые все равно не смогли полностью скрыть хлам от разработчика.


Хм. У меня сложилось устойчивое ощущение, что библиотеки (это ты про ATL/MFC?) никогда и не пытались что-то кардинально скрывать от разработчика. Тут скорее другая позиция — оставить все возможные пути использования и слегка упростить то, что по-разному использовать нельзя. Высокая идея спасения всех от десятка лишних строчек, похоже, разработчиков ATL трогает мало — важнее дать некий "концептуальный каркас", дальше специалисты прекрасно разберутся, что можно и чего нельзя. Но это на правах имхи.

VD>В Дельфи и дотнете поддержку кома встроели в рантайм и языки. Результа — писать КОМ-объекты на Дельфи или ВБ в десятки раз проще чем на С++.


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

ГВ>>ИМХО, возможность ограниченными усилиями реализовать тот же интерфейс средствами имеющегося языка куда как лучше, чем необходимость метаться между наилучшими инфраструктурами и подвязанными к ним языками, решая нерешаемую задачу выбора самой-самой подходящей для всех-всех случаев.


VD>Не ограниченными возможностями. А костылями, да еще и с огромной болью в заднице.


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

ГВ>>Конечно же не запрещает. Только если мне понадобится исключительно корба, то я выбирать буду между Java и C++, а отнюдь не между C# и F#.


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


Повторяю ключевые слова: "...если мне понадобится исключительно корба". Кстати, пруфлинк о загибании корбы таки дашь или нет?

ГВ>> С другой стороны, если будет предполагаться обилие COM, то выбор будет из C++ и C#. А вот если потребуется и то, и другое и ещё что-то третье... Ну ты понял. И произойдёт это ровно потому, что C++ не содержит каких-то встроенных "компонентизирующих" средств, которые, к тому же, нельзя оторвать от языка.


VD>А зачем отрывать средства от языка? Ты пишешь не программу на С++, а просто программу. Если язык или рантайм позволяет решить стоящие перед тобой задачи максимально просто, то разумно этим воспользоваться, а не тянуть черти-что с боку бантик (например, корбу) обосновывая это какими-то там идеями вроде универсальности стандарта.


А это ты, вероятно, никогда не сталкивался с необходимостью поддерживать несколько разных интерфейсов для одной программы. Иными словами, составляющая задачи — поддержка COM, CORBA, SOAP, C API, и т.п. При том COM-ов может быть несколько вариантов.

ГВ>>Угу, ключевое слово — "похожее". Только не надо говорить, что дженерики CLI проектировались в расчёте на JVM. И тогда зачем тут вообще Java упоминать?

VD>Денерики явы и дотнета проектировались в расчете на использование в компонентной среде. И это очень важно. Я не могу объявить обобщенный интерфейс в С++. При этом я спокойно могу сделать это как в яве, так и в дотнете.

Хм. Почему я могу объявить обобщённый интерфейс в C++? Разница только в моменте инстанцирования, но это к компонентности, мягко говоря, ортогонально. Обратно аргументы из серии "пришёл неизвестный ранее тип, под который мы резко инстанцировались и утонули в шоколаде" тоже отпраляются в /dev/trash — никогда ничего "совершенно неизвестного" компьютерные системы не обрабатывают.

VD>>>Понимаю. Но понимаю и то, что родилась она (как и альтернатива, коих кот наплакал) в основном потому, что в С++ не было нужных возможностей.

ГВ>>Ага, и поэтому не только унаследовала от C++ такую штуку, как VMT, но ещё и прямо заявлялась всегда как инфраструктура взаимодействия программ на разных языках, а отнюдь не как метод борьбы мифическими недостатками C++. Влад, по-моему только ты всё время борешься с C++ за светлое будущее.
VD>Дык это аргумент против твоей теории. Сам видишь, что для разработки универсального компонентного АПИ были взяты средства специфичные для конкретного языка, что сделано другие языки спроектированные без расчета на КОМ менее удобными для использования КОМ-а. В дальнейшем все языки которым было важно поддерживать КОМ тем или иным образом включили в себя поддержку аналога ВМТ. Только С эмулирует его на массивах.

Это аргумент в пользу тезиса о странностях, присущих Майкрософт. COM за эту самую VMT поругивали ещё в девяностолохматом году. И уж никак это не пришивается к рассуждениям о необходимости вставить поддержку компонентной среды в C++.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[4]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.09.09 15:12
Оценка:
Здравствуйте, AndrewVK, Вы писали:

ГВ>>Что ты несёшь... заблуждения в массы? Компонентность реализуется инфраструктурой, а не классами, шаблонами или дженериками.


AVK>Коль скоро так — продемонстрируй дженерик СОМ интерфейс, чтобы он был доступен из любого клиента СОМ именно как дженерик.


Чего-чего? Как это соотносится с моим высказыванием?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: шаблоны С++ и дженерики С#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.09.09 15:22
Оценка: +2
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Чего-чего? Как это соотносится с моим высказыванием?


Того. Влад совершенно понятно сказал, что шаблоны не компонентны. А уж как это соотносится с твоим высказыванием — ты сам решай.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[6]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.09.09 15:31
Оценка: -2 :))
Здравствуйте, AndrewVK, Вы писали:

ГВ>>Чего-чего? Как это соотносится с моим высказыванием?


AVK>Того. Влад совершенно понятно сказал, что шаблоны не компонентны. А уж как это соотносится с твоим высказыванием — ты сам решай.


Нет уж, твои ассоциации, ты и разъясняй. Что до меня, то на мой взгляд, твоя реплика никак не связана с нашей с Владом дискуссией.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.09.09 16:25
Оценка:
Здравствуйте, FR, Вы писали:

FR>Для C++ и других нативных языков такая среда тоже уже есть http://llvm.org/

FR>В общем-то есть большой шанс что она станет еще одной крупной платформой.

Такая да не такая. Компонентным она язык не сделает. Но согласен, что именно на таких бэкэндах имеет смысл строить современные компиляторы.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.09.09 16:44
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:
VD>>Ты сам то часто писал КОМ-объекты на С?
VD>>Хламу там получается ужас сколько. И это по сравнению с чем? С тем, что просто любой объект дотнета — это уже автоматом компонент!

ГВ>На C — да, лишнего кода много больше, чем на C++. Но и то в основном из-за отсутствия поддержки исключений и автоматических деструкторов.


...которые в КОМ-е не применимы так как ком испоьзует свою систему обработки ошибок основанную на кодах возвратов и свою систему управления жизни основанную на подсчете ссылок.

ЗЫ

В общем, это бесполезный разговор который пора завершать.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: шаблоны С++ и дженерики С#
От: FR  
Дата: 24.09.09 16:59
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Такая да не такая. Компонентным она язык не сделает. Но согласен, что именно на таких бэкэндах имеет смысл строить современные компиляторы.


Угу, но кроме бакэндов дает две важные вещи интероперабельность и кроссплатформенность, этого достаточно чтобы сформировать платформу.
Re[10]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.09.09 17:04
Оценка: +1 -2 :)
Здравствуйте, VladD2, Вы писали:

VD>В общем, это бесполезный разговор который пора завершать.


Угу, всё равно у тебя по делу одна мысль: "C++ — отстой и маздай потому что отстой и маздай, .Net рулит потому что рулит". Хорошо, что есть что-то постоянное в этом мире.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.09.09 17:10
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Угу, всё равно у тебя по делу одна мысль: "C++ — отстой и маздай потому что отстой и маздай, .Net рулит потому что рулит". Хорошо, что есть что-то постоянное в этом мире.


С++ это технологически отсталый язык. Но то что он маздай я никогда не утверждал. Он вполне применим при некоторых условиях. Просто применяя его нужно это четко понимать, а не гордиться черти-чем.

Скажем, если у компании есть много денег и ей нужно выпустить продукт критичный к объему используемых ресурсов и сильно оптимизированный под аппаратуру, а алгоритмически задачи не очень сложные, то С++ вполне себе инструмент. Но нужно понимать, что это альтернатива ассемблеру. Эдакий ассемблер с классами и шаблонами.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: А есле не согласен...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.09.09 17:11
Оценка:
...то дай, будь добр пруфлинк на "загибающуюся корбу" и сформулируй требования к идеальной компонентной среде. Требования должны быть получены каким-то иным путём, отличным от индукции из того, что ты увидел в .Net и JVM.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.09.09 17:35
Оценка: +3
Здравствуйте, VladD2, Вы писали:

ГВ>>Угу, всё равно у тебя по делу одна мысль: "C++ — отстой и маздай потому что отстой и маздай, .Net рулит потому что рулит". Хорошо, что есть что-то постоянное в этом мире.

VD>С++ это технологически отсталый язык. Но то что он маздай я никогда не утверждал. Он вполне применим при некоторых условиях. Просто применяя его нужно это четко понимать, а не гордиться черти-чем.

А кто тут чем-то гордится? По-моему, неуёмная г... кхм, гордость и высокомерие замечены как раз за противниками C++.

VD>Скажем, если у компании есть много денег и ей нужно выпустить продукт критичный к объему используемых ресурсов и сильно оптимизированный под аппаратуру, а алгоритмически задачи не очень сложные, то С++ вполне себе инструмент. Но нужно понимать, что это альтернатива ассемблеру. Эдакий ассемблер с классами и шаблонами.


Нет, разумеется. Прежде всего, реальные преимущества C++ начинаются там, где начинаются его мнимые недостатки. Первый фактор — стабильность, надёжность и распространённость компиляторов; второй фактор — количество программистов; третий — возможность получать программы, которые не обязаны тащить за собой "фреймворк"; четвёртый — возможность получить быстрый бинарный код (не всегда, в прочем, реализованная в реальных программах); пятый — защищённость от декомпиляции; шестой — огромное количество библиотек на C и C++ и такая же распространённость интерфейсов к C.

А вот потом уже — языковые изыски, паттернопарадигмы и прочая дребедень.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: шаблоны С++ и дженерики С#
От: EvilChild Ниоткуда  
Дата: 24.09.09 18:42
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Не читай. Дженерики — это весьма абстрактное проектное решение. То что они были разработаны для платформы CLI (они, между прочем поддерживаются в Моно ни чем не хуже) ни как не мешает использованию их в других языках. Та же Ява имеет очень похожее решение.


А в каком месте джавовские дженерики компонентны? Там же type erasure — они не являются сущностью рантайма.
now playing: Oblivion — Marche (Boris Brejcha Mix)
Re[13]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.09.09 19:11
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

VD>>С++ это технологически отсталый язык. Но то что он маздай я никогда не утверждал. Он вполне применим при некоторых условиях. Просто применяя его нужно это четко понимать, а не гордиться черти-чем.


ГВ>А кто тут чем-то гордится?


А где тут? Если на форуме, то на нем таких хватает. Как хватает и совершенно адекватно оценивающих инструмент людей использующих его по назначению.

ГВ>По-моему, неуёмная г... кхм, гордость и высокомерие замечены как раз за противниками C++.


Кто что хочет, то и замечает.

VD>>Скажем, если у компании есть много денег и ей нужно выпустить продукт критичный к объему используемых ресурсов и сильно оптимизированный под аппаратуру, а алгоритмически задачи не очень сложные, то С++ вполне себе инструмент. Но нужно понимать, что это альтернатива ассемблеру. Эдакий ассемблер с классами и шаблонами.


ГВ>Нет, разумеется.


Да, разумеется. Но, разумеется все останутся при своем мнении. Почему я говорю — пора завязывать.

ГВ>Прежде всего, реальные преимущества C++ начинаются там, где начинаются его мнимые недостатки.


Ага. И основное преимущество — близость к железу. Оно же основной недостаток. В прочем недостатков больше, на мой взгляд.

ГВ> Первый фактор — стабильность, надёжность и распространённость компиляторов;


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

ГВ> второй фактор — количество программистов;


По этому фактору Ява и даже дотнет (что спорно, но не суть) уже обогнали С++. И тенденция явно не в пользу С++.

ГВ> третий — возможность получать программы, которые не обязаны тащить за собой "фреймворк";


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

ГВ> четвёртый — возможность получить быстрый бинарный код


Э... А я о чем говорил? Только быстрый бинарный код получается и на дотнете с явой. Вот возможности по оптимизации конечно у языка более близкого к железу несомненно выше.

ГВ>(не всегда, в прочем, реализованная в реальных программах);


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

ГВ>пятый — защищённость от декомпиляции;


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

ГВ> шестой — огромное количество библиотек на C и C++ и такая же распространённость интерфейсов к C.


Чушь полнешая. Один дотнет фрэймворк или ява содержат больше чем все дступные бесплатно С++-библиотеки. А уж поставщиков библиотек вообще предлагают универсальный код на любой вкус. К тому же С++-ники очень не охотно используют чужой код. И это оправдано. Совместимость чужого кода в С++ между собой очень фиговая. По этому обычно все заканчивается на STL и boost-е. Ну, возможно еще чем-то очень необходимого. Зато велосипедов в С++-проектах всегда выше крыши. Вряд ли это можно списать на тупость тех кто использует С++. Это побочные эффекты недостатков языка.

Ну, и все вышеперечисленное можно точно так же отнести скажем к Haskell-ю, OCaml-у, Lisp-у или D. Но почему-то выбирают С++. Мне кажется, что тут логично было бы применить принцип бритвы Окамма. Наиболее простое объяснение верно. А простое объяснение — это как раз то, что С++ — это очень распространенный высокоуровневый ассемблер позволяющий за счет усложнения и удорожания разработки добиться меньшего потребления ресурсов. Плюс, конечно, человеческая косность мышления и стереотипы.

ГВ>А вот потом уже — языковые изыски, паттернопарадигмы и прочая дребедень.


А языковые изыски это точно не про С++. Человек выбирающий С++ из-за языковых изысков — это человек с очень узким кругозором и знаниями.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: А есле не согласен...
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.09.09 19:14
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>...то дай, будь добр пруфлинк на "загибающуюся корбу" и сформулируй требования к идеальной компонентной среде. Требования должны быть получены каким-то иным путём, отличным от индукции из того, что ты увидел в .Net и JVM.


Лучше ты дай другой где бы корба использовалась. Или тупо пошукай по гуглю на слова "Is Corba dead?" или "Corba is dead".

Я за Корбой следил довольно давно и долго. С тех времен люди которые во всю популяризировали корбу перешли на яву, а про корбу забыли. То место где кораба должна была занять рынок сейчас занаяла Ява. И очень редко когда яво-вские АПИ опираются на корбу. В свое время Борланд развивал эту тему, но мирно почил вместе со своими идеями. В прочем, формально Борланд тоже жив...
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.09.09 19:17
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>А в каком месте джавовские дженерики компонентны? Там же type erasure — они не являются сущностью рантайма.


Они не противоречат компонентным идеям. Их легко можно реализовать в компонентах и на них легко можно устраивать компонентные абстракции.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: шаблоны С++ и дженерики С#
От: EvilChild Ниоткуда  
Дата: 24.09.09 19:25
Оценка:
Здравствуйте, VladD2, Вы писали:

EC>>А в каком месте джавовские дженерики компонентны? Там же type erasure — они не являются сущностью рантайма.


VD>Они не противоречат компонентным идеям.

Это аргумент в пользу компонентности?

VD>Их легко можно реализовать в компонентах и на них легко можно устраивать компонентные абстракции.

Можно эту фразу пояснить? Обе её части.
now playing: Deadmau5 — The 16th Hour
Re[12]: А есле не согласен...
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.09.09 19:27
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>...то дай, будь добр пруфлинк на "загибающуюся корбу" и сформулируй требования к идеальной компонентной среде. Требования должны быть получены каким-то иным путём, отличным от индукции из того, что ты увидел в .Net и JVM.


Со своей стороны предлагаю привести "пруф линк" подтвердающий утверждение, что компонентных "инфраструктур" мириады. Устрит даже список из 20-30 реализаций. Мириады не надо приводить. .
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: шаблоны С++ и дженерики С#
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.09.09 19:28
Оценка:
Здравствуйте, EvilChild, Вы писали:

VD>>Они не противоречат компонентным идеям.

EC>Это аргумент в пользу компонентности?

Это обяснение, почему в Яве такие жденерики, а не С++-ные шаблоны.
Ты тему то читал?

VD>>Их легко можно реализовать в компонентах и на них легко можно устраивать компонентные абстракции.

EC>Можно эту фразу пояснить? Обе её части.

Какие из букв тебе не ясны?
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: шаблоны С++ и дженерики С#
От: EvilChild Ниоткуда  
Дата: 24.09.09 19:43
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Они не противоречат компонентным идеям.

EC>>Это аргумент в пользу компонентности?
VD>Это обяснение, почему в Яве такие жденерики, а не С++-ные шаблоны.
VD>Ты тему то читал?
А то. Меня заинтересовало вполне конкретное утверждение:

VD>>Дженерике же проектировались с расчетом на компонентные решения.

Хочу понять в каком месте джавовские дженерики компонентны.
Я вот знаю в каком .NET'ные компонентны, а джавовские — нет.
И как относятся С++-ные шаблоны к компонентности дженериков?

VD>>>Их легко можно реализовать в компонентах и на них легко можно устраивать компонентные абстракции.

EC>>Можно эту фразу пояснить? Обе её части.
VD>Какие из букв тебе не ясны?
Мы вроде говорим на вполне определённую техническую тему, а ты какой-то туман напускаешь когда тебе конкретный вопрос задают.
Не настроен общаться конструктивно — на здоровье, никто не неволит.
now playing: Maxime Dangles — Automne Bizard
Re[14]: шаблоны С++ и дженерики С#
От: Хвост  
Дата: 24.09.09 21:30
Оценка: +4
Здравствуйте, VladD2, Вы писали:

VD>Чушь полнешая. Один дотнет фрэймворк или ява содержат больше чем все дступные бесплатно С++-библиотеки.


People write code, programming languages don't.
Re[13]: А есле не согласен...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.09.09 00:26
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Со своей стороны предлагаю привести "пруф линк" подтвердающий утверждение, что компонентных "инфраструктур" мириады. Устрит даже список из 20-30 реализаций. Мириады не надо приводить. .


Я возьму ссылку из твоего соседнего
Автор: VladD2
Дата: 23.09.09
сообщения: http://en.wikipedia.org/wiki/Component-oriented_programming

В конце статьи как раз порядка двух десятков ссылок на компонентные инфраструктуры.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[13]: А есле не согласен...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.09.09 01:36
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>...то дай, будь добр пруфлинк на "загибающуюся корбу" и сформулируй требования к идеальной компонентной среде. Требования должны быть получены каким-то иным путём, отличным от индукции из того, что ты увидел в .Net и JVM.

VD>Лучше ты дай другой где бы корба использовалась.

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

VD>Или тупо пошукай по гуглю на слова "Is Corba dead?" или "Corba is dead".


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

VD>Я за Корбой следил довольно давно и долго. С тех времен люди которые во всю популяризировали корбу перешли на яву, а про корбу забыли. То место где кораба должна была занять рынок сейчас занаяла Ява. И очень редко когда яво-вские АПИ опираются на корбу. В свое время Борланд развивал эту тему, но мирно почил вместе со своими идеями. В прочем, формально Борланд тоже жив...


Ничего не понятно. Что за люди, какое место, почему явовские API должны опираться на корбу? "Есть у нас оружие!" (c)
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[14]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.09.09 02:36
Оценка: +1
Здравствуйте, VladD2, Вы писали:

ГВ>>Нет, разумеется.

VD>Да, разумеется. Но, разумеется все останутся при своем мнении. Почему я говорю — пора завязывать.

Ладно, ещё по постингу и завязываем. Тем более, что разговор уже уходит в вечно больную сторону "C++ vs VladD2".

ГВ>> Первый фактор — стабильность, надёжность и распространённость компиляторов;

VD>О, как? Тому противоречат масса вопросов совместимости которые можно увидеть на наших форумах.
VD>Так что не надо выдавать желаемое за действительное.

Вопросы совместимости возникают везде, где декларируется совместимость. В принципе, проблем с переносом особых нет, если не используются vendor-specific конструкции. Да даже если и используются, то рефакторинг, как правило, достаточно примитивный. В прочем, за всех не скажу.

ГВ>> второй фактор — количество программистов;

VD>По этому фактору Ява и даже дотнет (что спорно, но не суть) уже обогнали С++. И тенденция явно не в пользу С++.

Ладно, на счёт количества программистов я загнул. Их просто так же (не-)просто найти, как порядочных Java- и .Net-программистов. А в том, что в целом Java- и .Net-программистов должно быть больше, чем "плюсовиков" я ни минуты и не сомневаюсь. Причины ты и сам отлично знаешь.

ГВ>> третий — возможность получать программы, которые не обязаны тащить за собой "фреймворк";

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

Угу, поскольку есть ещё соображение N6.

ГВ>>пятый — защищённость от декомпиляции;

VD>Это совсем глупый домысел. Покажи пример того как компания пострадала от декомпиляции управляемого кода.

Это не домысел, это вполне реальное соображение, изложенное мне коллегами.

VD>При некоторых объемах ты не разберешься даже с декомпилированным кодом.

VD>А при некоторой необходимости (например, взломать защиту) люди готовы разбираться и с в доску бинарным кодом (примеры ломаных программ интересуют?).

Конечно. Всё дело в цене на билет.

ГВ>> шестой — огромное количество библиотек на C и C++ и такая же распространённость интерфейсов к C.


VD>Чушь полнешая. Один дотнет фрэймворк или ява содержат больше чем все дступные бесплатно С++-библиотеки. А уж поставщиков библиотек вообще предлагают универсальный код на любой вкус. К тому же С++-ники очень не охотно используют чужой код. И это оправдано. Совместимость чужого кода в С++ между собой очень фиговая. По этому обычно все заканчивается на STL и boost-е. Ну, возможно еще чем-то очень необходимого. Зато велосипедов в С++-проектах всегда выше крыши. Вряд ли это можно списать на тупость тех кто использует С++. Это побочные эффекты недостатков языка.


Мда, ну и каша же у тебя в голове по поводу C++, во всяком случае. На самом деле, C++ world'09 уже очень сильно отличается от того, из которого ты уходил... Сколько там лет назад? А проблемы новичков или не отработанных библиотек — они во все времена одни и те же. С совместимостью тоже, в общем и целом особых проблем нет, если библиотека написана без использования специфики GCC, MSVC, ICC и т.п. Так что, что-то ты тут либо преувеличиваешь, либо пользуешься впечатлениями в прямом смысле седой старины. С "велосипедами" ситуация примерно та же — с развитием буста большинство велосипедов корова языком слизала. Так что, прекращай уже повторять замшелые стереотипы, это вредно в смысле косности мышления.

VD>Ну, и все вышеперечисленное можно точно так же отнести скажем к Haskell-ю, OCaml-у, Lisp-у или D. Но почему-то выбирают С++. Мне кажется, что тут логично было бы применить принцип бритвы Окамма. Наиболее простое объяснение верно. А простое объяснение — это как раз то, что С++ — это очень распространенный высокоуровневый ассемблер позволяющий за счет усложнения и удорожания разработки добиться меньшего потребления ресурсов. Плюс, конечно, человеческая косность мышления и стереотипы.


Так... Опять сказка про белого бычка. Ладно, мнение есть мнение. Мни, раз мнится.

ГВ>>А вот потом уже — языковые изыски, паттернопарадигмы и прочая дребедень.

VD>А языковые изыски это точно не про С++. Человек выбирающий С++ из-за языковых изысков — это человек с очень узким кругозором и знаниями.

Не, ты не понял. Языковые изыски — это вообще отдельная штука.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[15]: шаблоны С++ и дженерики С#
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 25.09.09 11:41
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вопросы совместимости возникают везде, где декларируется совместимость. В принципе, проблем с переносом особых нет, если не используются vendor-specific конструкции. Да

ГВ>Мда, ну и каша же у тебя в голове по поводу C++, во всяком случае. На самом деле, C++ world'09 уже очень сильно отличается от того, из которого ты уходил... Сколько там лет назад? А проблемы новичков или не отработанных библиотек — они во все времена одни и те же. С совместимостью тоже, в общем и целом особых проблем нет, если библиотека написана без использования специфики GCC, MSVC, ICC и т.п. Так что, что-то ты тут либо преувеличиваешь, либо пользуешься впечатлениями в прямом смысле седой старины. С "велосипедами" ситуация примерно та же — с развитием буста большинство велосипедов корова языком слизала. Так что, прекращай уже повторять замшелые стереотипы, это вредно в смысле косности мышления.
Как интересно. И что, уже есть какой-то устоявшийся стандарт на представление хотя бы аналогов DateTime и TimeSpan? Или по-прежнему каждая библиотека использует своё уникальное видение мира? А строки — уже решили, как надо делать? Или по-прежнему в QString нет конструктора от CString, и оба несовместимы с std::string?

Может быть, есть какой-то стандарт на интерфейс к XML парсеру / XSLT трансформатору? Или опять-таки смена одной либы на другую потребует массового исправления исходников программы?
Кстати, этот парсер — он какие строки возвращает?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[16]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.09.09 14:51
Оценка: :))
Здравствуйте, Sinclair, Вы писали:

ГВ>>Так что, прекращай уже повторять замшелые стереотипы, это вредно в смысле косности мышления.

S>Как интересно. И что, уже есть какой-то устоявшийся стандарт на представление хотя бы аналогов DateTime и TimeSpan? Или по-прежнему каждая библиотека использует своё уникальное видение мира? А строки — уже решили, как надо делать? Или по-прежнему в QString нет конструктора от CString, и оба несовместимы с std::string?

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

S>Может быть, есть какой-то стандарт на интерфейс к XML парсеру / XSLT трансформатору? Или опять-таки смена одной либы на другую потребует массового исправления исходников программы?

S>Кстати, этот парсер — он какие строки возвращает?

Смена одной либы на другую очень часто требует переработки исходников.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[14]: А есле не согласен...
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.09.09 06:21
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Я возьму ссылку из твоего соседнего
Автор: VladD2
Дата: 23.09.09
сообщения: http://en.wikipedia.org/wiki/Component-oriented_programming


ГВ>В конце статьи как раз порядка двух десятков ссылок на компонентные инфраструктуры.


Где же ты там два десятка усмотрел? Или ты технологии по ссылкам считаешь?

Ты попробуй, все же, списочек то составить...
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: А есле не согласен...
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.09.09 06:25
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Я возьму ссылку из твоего соседнего
Автор: VladD2
Дата: 23.09.09
сообщения: http://en.wikipedia.org/wiki/Component-oriented_programming


ГВ>В конце статьи как раз порядка двух десятков ссылок на компонентные инфраструктуры.


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

Component-oriented programming
    * SOFA component system [1] from ObjectWeb
    * Fractal component model [2] from ObjectWeb
    * rCOS method of component-based model driven design [3] from UNU-IIST
    * Visual Basic Extensions, OCX/ActiveX/COM and DCOM from Microsoft
    * XPCOM from Mozilla Foundation
    * VCL and CLX from Borland and similar free LCL library.
    * Enterprise JavaBeans from Sun Microsystems
    * UNO from the OpenOffice.org office suite
    * Eiffel programming language
    * Oberon programming language and BlackBox
    * Bundles as defined by the OSGi Service Platform
    * The System.ComponentModel namespace in Microsoft .NET
    * Flow-based programming
    * MidCOM[4] component framework for Midgard and PHP
    * Common Component Architecture (CCA) - Common Component Architecture Forum [5], Scientific/HPC Component Software
          o TASCS [6] - SciDAC [7] Center for Technology for Advanced Scientific Component Software
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: А есле не согласен...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.09.09 16:54
Оценка: -1
Здравствуйте, VladD2, Вы писали:

ГВ>>Я возьму ссылку из твоего соседнего
Автор: VladD2
Дата: 23.09.09
сообщения: http://en.wikipedia.org/wiki/Component-oriented_programming


ГВ>>В конце статьи как раз порядка двух десятков ссылок на компонентные инфраструктуры.


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


VD>
VD>Component-oriented programming
VD>    * SOFA component system [1] from ObjectWeb
VD>    * Fractal component model [2] from ObjectWeb
VD>    * rCOS method of component-based model driven design [3] from UNU-IIST
VD>    * Visual Basic Extensions, OCX/ActiveX/COM and DCOM from Microsoft
VD>    * XPCOM from Mozilla Foundation
VD>    * VCL and CLX from Borland and similar free LCL library.
VD>    * Enterprise JavaBeans from Sun Microsystems
VD>    * UNO from the OpenOffice.org office suite
VD>    * Eiffel programming language
VD>    * Oberon programming language and BlackBox
VD>    * Bundles as defined by the OSGi Service Platform
VD>    * The System.ComponentModel namespace in Microsoft .NET
VD>    * Flow-based programming
VD>    * MidCOM[4] component framework for Midgard and PHP
VD>    * Common Component Architecture (CCA) - Common Component Architecture Forum [5], Scientific/HPC Component Software
VD>          o TASCS [6] - SciDAC [7] Center for Technology for Advanced Scientific Component Software
VD>


Прочесть текст по ссылке до конца тебе, как я понимаю, принципы не позволили:

Component-based software frameworks for specific domains
    * Earth System Modeling Framework (ESMF)
Compound document technologies
    * Bonobo (component model), a part of GNOME
    * KPart, the KDE Compound document technology
    * Object linking and embedding (OLE)
    * OpenDoc
    * Fresco
Business object technologies
    * Newi
Distributed computing software components
    * 9P distributed protocol developed for Plan 9, and used by Inferno and other systems.
    * CORBA and the CORBA Component Model from the Object Management Group
    * D-BUS from the freedesktop.org organization
    * DCOM and later versions of COM (and COM+) from Microsoft
    * DCOP from KDE
    * DSOM and SOM from IBM (now scrapped)
    * ICE from ZeroC
    * Java EE from Sun
    * .NET Remoting from Microsoft
    * Web Services
          o REST
    * Universal Network Objects (UNO) from OpenOffice.org
    * Zope from Zope Corporation
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[15]: А есле не согласен...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.09.09 16:58
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>В конце статьи как раз порядка двух десятков ссылок на компонентные инфраструктуры.

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

См. соседнее сообщение. Конечно, я считаю в том числе и OpenOffice/UNO. Вполне себе компонентная приблуда. Всё, что заявляет о себе, как о компонентной среде/инфраструктуре/технологии — является таковым в виду размытости самого термина "компонентность".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[16]: А есле не согласен...
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.09.09 17:17
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Прочесть текст по ссылке до конца тебе, как я понимаю, принципы не позволили:


Там не инфрмструктуры, а специализации которые повтояют исходный список. Например, OLE и DCOM — это все COM.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: А есле не согласен...
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.09.09 17:24
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>См. соседнее сообщение. Конечно, я считаю в том числе и OpenOffice/UNO. Вполне себе компонентная приблуда. Всё, что заявляет о себе, как о компонентной среде/инфраструктуре/технологии — является таковым в виду размытости самого термина "компонентность".


UNO, как я понимаю не универсальная вещь. Это только интерфейс к OpenOffice. Если я ошибаюсь, то UNO тоже можно записывать в компонентный фрэймворк. Даже, пожалуй это круче. Это — объеденяющий компонентный фрэймворк. Но что-то мне подсказывает, что за пределами OpenOffice это использовать дует затруднительно.

Что касается ссылки, то там написана чушь. Еще раз предлагаю самостоятельно сделать список и убедиться, что там весма не много пунктов большая часть из которых будет как раз являться реализацией компонентности в других языках или конкретных продуктах (т.е. не универсальные решения).
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: А есле не согласен...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.09.09 20:49
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>См. соседнее сообщение. Конечно, я считаю в том числе и OpenOffice/UNO. Вполне себе компонентная приблуда. Всё, что заявляет о себе, как о компонентной среде/инфраструктуре/технологии — является таковым в виду размытости самого термина "компонентность".


VD>UNO, как я понимаю не универсальная вещь. Это только интерфейс к OpenOffice. Если я ошибаюсь, то UNO тоже можно записывать в компонентный фрэймворк. Даже, пожалуй это круче. Это — объеденяющий компонентный фрэймворк. Но что-то мне подсказывает, что за пределами OpenOffice это использовать дует затруднительно.


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

VD>Что касается ссылки, то там написана чушь.


Так я и не предлагаю читать то, что там написано помимо списка ссылок.

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


Да, не универсальные. Да, будет много специфичных инфраструктур. Что это меняет? Я просто не понимаю, что ты мне пытаешься доказать.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[17]: А есле не согласен...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.09.09 20:57
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>Прочесть текст по ссылке до конца тебе, как я понимаю, принципы не позволили:

VD>Там не инфрмструктуры, а специализации которые повтояют исходный список. Например, OLE и DCOM — это все COM.

Хм. Только в разделе Distributed computing software components — 12 ссылок на относительно широко известные инфраструктуры. Мало, что ли? Откуда я знаю, кто ещё чего выдумал?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: шаблоны С++ и дженерики С#
От: vdimas Россия  
Дата: 27.09.09 17:11
Оценка: +2
Здравствуйте, VladD2, Вы писали:


VD>Понимаю. Но понимаю и то, что родилась она (как и альтернатива, коих кот наплакал) в основном потому, что в С++ не было нужных возможностей.


COM родился вместе с OLE, и решал прблему компонентности не С++, а прикладных программ вообще, написанных на различных языках. Да и вообще, обсуждать сейчас это бессмысленно, хотя бы потому, что на тот момент это было отличное решение. У меня на двойке с 2M памяти запускался 2-й виндоуз и я в MS Word писал диплом, с графиками и картинками... Ну разве могли быть тогда компонентые решение навроде .Net, у которой системные сборки (много)метровые?

В общем, было бы что обсуждать.
Re[17]: шаблоны С++ и дженерики С#
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 28.09.09 03:05
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>С одной стороны часть этого есть в бусте. С другой, преобразования строк — это не настолько большая проблема, как рисуется в воображении, я тебе уже приводил примеры шаблонных реализаций операторов над строками.

Толку-то с этих шаблонных операторов. В любом случае, если одна либа порождает CString, а другая — потребляет QString, то постоянно нужно выполнять операции преобразования.

ГВ>Смена одной либы на другую очень часто требует переработки исходников.

Попробуй попрограммировать на Java. На дотнете не так заметно — там среднее количество библиотек на заданную тему равно единице.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[18]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.09.09 04:18
Оценка:
Здравствуйте, Sinclair, Вы писали:

ГВ>>С одной стороны часть этого есть в бусте. С другой, преобразования строк — это не настолько большая проблема, как рисуется в воображении, я тебе уже приводил примеры шаблонных реализаций операторов над строками.

S>Толку-то с этих шаблонных операторов.

Кому как. Можно и шаблонные алгоритмы для разных вариаций строк писать на таких операторах.

S>В любом случае, если одна либа порождает CString, а другая — потребляет QString, то постоянно нужно выполнять операции преобразования.


Верно. Правда, драматичность этой проблемы серьёзно преувеличена, ИМХО.

ГВ>>Смена одной либы на другую очень часто требует переработки исходников.

S>Попробуй попрограммировать на Java. На дотнете не так заметно — там среднее количество библиотек на заданную тему равно единице.

Это понятно, только ты не путай калий с кальцием. "Разные библиотеки" Java можно, в общем-то, считать разными версиями одной и той же библиотеки, API которой считается референсным, так что, пример не совсем в кассу — для C++, например, тоже есть разные реализации тех же malloc/free или STL. Ну и потом, ИМХО, библиотеки C++ представляют большую функциональность на единицу кода, нежели библиотеки Java, отсюда и большая вариабельность API — каждому же хочется реализовать всего и побольше, понятно, что почти никто друг на друга при этом не оглядывается.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.09.09 04:36
Оценка:
Здравствуйте, vdimas, Вы писали:

V>В общем, было бы что обсуждать.


А кроме того, OLE появился где-то в начале 90-х, когда C++ ещё толком не устоялся и определённо, в роль главного пугала индустрии не вошёл. Скорее наоборот — OLE хаяли все, кому не лень: кто за глючность, кто за сложность.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[19]: шаблоны С++ и дженерики С#
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 28.09.09 05:04
Оценка: +2 :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Кому как. Можно и шаблонные алгоритмы для разных вариаций строк писать на таких операторах.

Можно. Но никто этого не делает.

ГВ>Верно. Правда, драматичность этой проблемы серьёзно преувеличена, ИМХО.

Да. В С++ драматичных проблем нет. Вот только стандарты в нём по факту отсутствуют. Вот и приходится выбирать нее язык, а платформу — типа MFC, ATL, WTL, QT, boost, или ещё чего-нибудь.

ГВ>Это понятно, только ты не путай калий с кальцием. "Разные библиотеки" Java можно, в общем-то, считать разными версиями одной и той же библиотеки, API которой считается референсным, так что, пример не совсем в кассу — для C++, например, тоже есть разные реализации тех же malloc/free или STL.

Ой-ой-ой. Можно считать их чем угодно. Но по факту, любые сервлеты, к примеру, совместимы между собой. Доступ к реляционнным данным всегда делается через JDBC. Криптография вся делается через стандартизованную механику провайдеров. Что, будем считать SHA и PGP "разными версиями одной и той же библиотеки"?

ГВ>Ну и потом, ИМХО, библиотеки C++ представляют большую функциональность на единицу кода, нежели библиотеки Java, отсюда и большая вариабельность API — каждому же хочется реализовать всего и побольше, понятно, что почти никто друг на друга при этом не оглядывается.

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

Вариабельность API — исключительно синдром NIH плюс отсутствие внятного стандарта. Как мы уже выяснили, даже стандарта строк (самый частовстречаемый класс) в природе не существует. Ну вот объясни мне, почему до сих пор, невзирая на 100% внедрение STL, все серъёзные пакеты библиотек делают свои строки? Ну ладно, CString, возможно, старше std::string, к тому же это не один класс, а целая пачка. А QString откуда взялся? Что, кутешники сделали какую-то сильно более хорошую строку? Или, может быть, они не смогли заставить себя оглянуться на std::string?
Покажи мне банальную вещь — библиотеку конверсии кодировок строк, которая совместима с тремя основными семействами строк. Где она? Невозможно написать. Поэтому мы и имеем зоопарк программ на С++, которые работают только с одной кодировкой.

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

На практике в С++ стандартным является только отсутствие сколь бы то ни было поддержанных стандартов.
Есть только STL. Но он покрывает пренебрежимо малую часть потребной функциональности. Ничего сложнее консольной Hello World с таким "стандартом" написать невозможно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[20]: шаблоны С++ и дженерики С#
От: Cyberax Марс  
Дата: 28.09.09 05:25
Оценка: +1 :)
Здравствуйте, Sinclair, Вы писали:

ГВ>>Это понятно, только ты не путай калий с кальцием. "Разные библиотеки" Java можно, в общем-то, считать разными версиями одной и той же библиотеки, API которой считается референсным, так что, пример не совсем в кассу — для C++, например, тоже есть разные реализации тех же malloc/free или STL.

S>Ой-ой-ой. Можно считать их чем угодно. Но по факту, любые сервлеты, к примеру, совместимы между собой. Доступ к реляционнным данным всегда делается через JDBC. Криптография вся делается через стандартизованную механику провайдеров. Что, будем считать SHA и PGP "разными версиями одной и той же библиотеки"?
Не надо сказки рассказывать. В Java не меньший зоопарк API. Ты просто выбрал то, что является исключением.

Т.е. интерфейс сервлетов хорошо специфицирован. А вот web framework'и, которые на нём построены, образуют огромный зоопарк, несовместимый ни с чем. И официальный JSF не является даже самым распространённым.

Библиотек криптографии в Java тоже полно, в том числе и не [полностью] предоставляющих интерфейс Java CryptoAPI — http://www.bouncycastle.org/ , к примеру.

S>Вариабельность API — исключительно синдром NIH плюс отсутствие внятного стандарта. Как мы уже выяснили, даже стандарта строк (самый частовстречаемый класс) в природе не существует. Ну вот объясни мне, почему до сих пор, невзирая на 100% внедрение STL, все серъёзные пакеты библиотек делают свои строки? Ну ладно, CString, возможно, старше std::string, к тому же это не один класс, а целая пачка. А QString откуда взялся? Что, кутешники сделали какую-то сильно более хорошую строку? Или, может быть, они не смогли заставить себя оглянуться на std::string?

У QT-шников строка более мощная, чем std::string. И она таки легко преобразуется в std::string.

S>Покажи мне банальную вещь — библиотеку конверсии кодировок строк, которая совместима с тремя основными семействами строк. Где она? Невозможно написать. Поэтому мы и имеем зоопарк программ на С++, которые работают только с одной кодировкой.

Ээээ... А какие проблемы-то? Берёшь любую и используешь — тот же QString это умеет.
Sapienti sat!
Re[21]: шаблоны С++ и дженерики С#
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 28.09.09 06:12
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

S>>Покажи мне банальную вещь — библиотеку конверсии кодировок строк, которая совместима с тремя основными семействами строк. Где она? Невозможно написать. Поэтому мы и имеем зоопарк программ на С++, которые работают только с одной кодировкой.

C>Ээээ... А какие проблемы-то? Берёшь любую и используешь — тот же QString это умеет.
Простые очень проблемы — нет никакого стандарта. QString, допустим, умеет. Ну, то есть QString, понятное дело, умеет только латин1 и utf-8, что абсолютно верно. А всё остальное умеет, понятное дело, QTextCodec. И он, конечно же, никакого стандарта не реализует. Поэтому, к примеру, прикрутить это к CString будет крайне затруднительно. Ну, то есть самый простой способ — работать на уровне char*, что и есть единственный реальный "стандарт строки в С++". При этом, конечно же, внезапно окажется, что производительность такого конвертера сильно хуже, чем у соседей — потому, что у char* нет заранее известной длины, и кодеку придётся многократно перевыделять внутренний буфер.

Вот поэтому мы и имеем то, что имеем, а не то, о чем грезят фанаты плюсов. То есть вместо суперомптимальных надёжных программ мы имеем тормозное ненадёжное унылое понятно что.
И куда ни ткни — везде такой бардак.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[20]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.09.09 16:09
Оценка:
Здравствуйте, Sinclair, Вы писали:

ГВ>>Кому как. Можно и шаблонные алгоритмы для разных вариаций строк писать на таких операторах.

S>Можно. Но никто этого не делает.

Я делаю. Этого вполне достаточно.

ГВ>>Верно. Правда, драматичность этой проблемы серьёзно преувеличена, ИМХО.

S>Да. В С++ драматичных проблем нет. Вот только стандарты в нём по факту отсутствуют.

По факту — присутствуют. Только это стандарт на язык, а не на каждый чих.

S>Вот и приходится выбирать нее язык, а платформу — типа MFC, ATL, WTL, QT, boost, или ещё чего-нибудь.


Угу. И все платформы на одном и том же языке — красота!

ГВ>>Это понятно, только ты не путай калий с кальцием. "Разные библиотеки" Java можно, в общем-то, считать разными версиями одной и той же библиотеки, API которой считается референсным, так что, пример не совсем в кассу — для C++, например, тоже есть разные реализации тех же malloc/free или STL.

S>Ой-ой-ой. Можно считать их чем угодно. Но по факту, любые сервлеты, к примеру, совместимы между собой.

Между собой? В смысле? Может, ты имел в виду совместимость с контейнерами?

S>Доступ к реляционнным данным всегда делается через JDBC.


Много ты знаешь распространённых "тяжёлых" СУБД, для которых интерфейс Java роднее C? Вот и я не знаю. Далее делаем простые выводы.

S>Криптография вся делается через стандартизованную механику провайдеров. Что, будем считать SHA и PGP "разными версиями одной и той же библиотеки"?


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

ГВ>>Ну и потом, ИМХО, библиотеки C++ представляют большую функциональность на единицу кода, нежели библиотеки Java, отсюда и большая вариабельность API — каждому же хочется реализовать всего и побольше, понятно, что почти никто друг на друга при этом не оглядывается.

S>О да. Конечно. Конечно же, не хочется признавать безнадёжную убогость плюсов в плане стандартизации и интеропа по сравнению с практически любой альтернативой.

О, теперь твоя очередь заставлять меня признавать какую-нибудь хрень. Времена идут, люди не меняются.

Давай так: стандартизация API — отдельно, котлеты — отдельно, интероп — на третье. Кому что надо, те то стандартизируют. И вообще, ИМХО, обилие стандартов в Java как раз свидетельствует о неких врождённых недостатках самой Java: без "синергии миллионов стандартизаторов" ни бэ, ни мэ, ни кукареку.

Потом, что касается интеропа, то вот тут как раз C и C++ равных нет в смысле возможностей интеропа с кем угодно. Причины я кратко объяснил чуть выше. И ничего ты с этим не сделаешь, сколько ни исходи. Другой вопрос — насколько это удобно реализовано в том или ином случае.

S>Вариабельность API — исключительно синдром NIH плюс отсутствие внятного стандарта. Как мы уже выяснили, даже стандарта строк (самый частовстречаемый класс) в природе не существует. Ну вот объясни мне, почему до сих пор, невзирая на 100% внедрение STL, все серъёзные пакеты библиотек делают свои строки? Ну ладно, CString, возможно, старше std::string, к тому же это не один класс, а целая пачка. А QString откуда взялся? Что, кутешники сделали какую-то сильно более хорошую строку? Или, может быть, они не смогли заставить себя оглянуться на std::string?


Так он же тоже старше std::string, если мне не изменяет HDD и не привирает википедия:

Haavard Nord and Eirik Chambe-Eng (the original developers of Qt and the CEO and President, respectively, of Trolltech) began development of "Qt" in 1991, three years before the company was incorporated as Quasar Technologies, then changed the name to Troll Tech, and then to Trolltech.


Посему оглядываться им было, ИМХО, некуда.

S>Покажи мне банальную вещь — библиотеку конверсии кодировок строк, которая совместима с тремя основными семействами строк. Где она? Невозможно написать. Поэтому мы и имеем зоопарк программ на С++, которые работают только с одной кодировкой.


Требования по API сформулируешь? Нет требований — нет библиотек. И вообще — что такое "невозможно написать" в смысле упаковки кучи API под другим API? Этих слов моя не знать.

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


"Нет" по последнему утверждению, по остальным — "да". Только ты что-то путаешь, это не мантры, а объективная реальность. Я понимаю, что ступаю тут на зыбкую почву попыток убедить собеседника в том, что он считает нечто действующее мантрами, но...

S>На практике в С++ стандартным является только отсутствие сколь бы то ни было поддержанных стандартов.

S>Есть только STL. Но он покрывает пренебрежимо малую часть потребной функциональности. Ничего сложнее консольной Hello World с таким "стандартом" написать невозможно.

Ну, извини, если ты считаешь, что без оглядки на "стандарты" ничего нельзя писать, это уж и не знаю, прямо. Какое-то сильно крутое колдунство для меня, во всяком случае.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.09.09 16:37
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>>Покажи мне банальную вещь — библиотеку конверсии кодировок строк, которая совместима с тремя основными семействами строк. Где она? Невозможно написать. Поэтому мы и имеем зоопарк программ на С++, которые работают только с одной кодировкой.

C>>Ээээ... А какие проблемы-то? Берёшь любую и используешь — тот же QString это умеет.
S>Простые очень проблемы — нет никакого стандарта.

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

S>QString, допустим, умеет. Ну, то есть QString, понятное дело, умеет только латин1 и utf-8, что абсолютно верно. А всё остальное умеет, понятное дело, QTextCodec. И он, конечно же, никакого стандарта не реализует. Поэтому, к примеру, прикрутить это к CString будет крайне затруднительно. Ну, то есть самый простой способ — работать на уровне char*, что и есть единственный реальный "стандарт строки в С++". При этом, конечно же, внезапно окажется, что производительность такого конвертера сильно хуже, чем у соседей — потому, что у char* нет заранее известной длины, и кодеку придётся многократно перевыделять внутренний буфер.


Почему обязательно нужно пользоваться самым простым способом — через char*, когда нужна скорость и под боком имеется длина? Зачем многократно перевыделять буфер? Максимальный размер кода символа в указанной кодировке — неизвестная величина?

Антон, прекращай уже с менеджерами тусоваться, они тебя плохому учат!

S>Вот поэтому мы и имеем то, что имеем, а не то, о чем грезят фанаты плюсов. То есть вместо суперомптимальных надёжных программ мы имеем тормозное ненадёжное унылое понятно что.


Ха-ха. Ну ты молодец, ё-моё. Сам придумал, сам и поругал.

S>И куда ни ткни — везде такой бардак.


Анархия — мать порядка. Как раз в таком "бардаке" и воспитывается умение организовывать свои собственные мысли. А эта пушка посильнее любых стандартов будет.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[23]: шаблоны С++ и дженерики С#
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 30.09.09 07:59
Оценка: +2
Здравствуйте, Геннадий Васильев, Вы писали:

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

При чём тут мантра? Это — констатация факта. Ты его опровергнуть хочешь? Ну так покажи мне стандарт на приведение кодировок.

S>>QString, допустим, умеет. Ну, то есть QString, понятное дело, умеет только латин1 и utf-8, что абсолютно верно. А всё остальное умеет, понятное дело, QTextCodec. И он, конечно же, никакого стандарта не реализует. Поэтому, к примеру, прикрутить это к CString будет крайне затруднительно. Ну, то есть самый простой способ — работать на уровне char*, что и есть единственный реальный "стандарт строки в С++". При этом, конечно же, внезапно окажется, что производительность такого конвертера сильно хуже, чем у соседей — потому, что у char* нет заранее известной длины, и кодеку придётся многократно перевыделять внутренний буфер.


ГВ>Почему обязательно нужно пользоваться самым простым способом — через char*, когда нужна скорость и под боком имеется длина? Зачем многократно перевыделять буфер? Максимальный размер кода символа в указанной кодировке — неизвестная величина?

Ну, покажи мне непростой способ. Вот есть у меня, скажем CEdit. И хочу введённую туда пользователем строку теперь сконвертировать в, скажем, UTF7 и сохранить в файл. Покажи мне, как это делается умными людьми.

ГВ>Анархия — мать порядка. Как раз в таком "бардаке" и воспитывается умение организовывать свои собственные мысли. А эта пушка посильнее любых стандартов будет.

Да-да-да. Это всё мы уже слышали. "С++ — насолько сложный язык, что в нём выживают только самые умные программисты". Увы, это враньё. Практика ничего подобного не показывает.
Всё, чему помогает сложность языка — это удорожание разработки на нём.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[21]: шаблоны С++ и дженерики С#
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 30.09.09 08:16
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>По факту — присутствуют. Только это стандарт на язык, а не на каждый чих.

В наше время это всё равно, что стандарт на кодировку символов в исходниках.

ГВ>Угу. И все платформы на одном и том же языке — красота!

Толку-то! Не получается взять так и просто подружить две платформы — приходится писать много boilerplate кода.
Там, где программист на C# или Java пишет в отчёте "выбор библиотеки — 8 часов, проверка в проекте — 2 часа", С++ программист пишет "выбор библиотеки — 1 час, прикручивание в проект и написание врапперов — 40 часов".

ГВ>Между собой? В смысле? Может, ты имел в виду совместимость с контейнерами?

И между собой, и с контейнерами.
S>>Доступ к реляционнным данным всегда делается через JDBC.
ГВ>Много ты знаешь распространённых "тяжёлых" СУБД, для которых интерфейс Java роднее C? Вот и я не знаю. Далее делаем простые выводы.
Термин "роднее" мне неизвестен. Как неизвестны и СУБД, для которых нет JDBC-драйвера. Вот и делаем простые выводы: низкоуровневые С-библиотеки хороши для написания vendor-specific tools, а для написания бизнес-приложений никто dblib уже десять лет как неиспользует. Спуститесь с небес на землю (или вам там наоборот, подняться надо?)

ГВ>Угу, будем. В случае общего API вполне допустимая абстракция.


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

ГВ>Давай так: стандартизация API — отдельно, котлеты — отдельно, интероп — на третье. Кому что надо, те то стандартизируют. И вообще, ИМХО, обилие стандартов в Java как раз свидетельствует о неких врождённых недостатках самой Java: без "синергии миллионов стандартизаторов" ни бэ, ни мэ, ни кукареку.

Вот то-то и оно. Пока С++ безнадёжно пытается стандартизовать хотя бы compiled templates, то есть самый низкий уровень платформы, парни в Виллариба уже давно стандартизуют что-то поинтереснее.

ГВ>Потом, что касается интеропа, то вот тут как раз C и C++ равных нет в смысле возможностей интеропа с кем угодно. Причины я кратко объяснил чуть выше. И ничего ты с этим не сделаешь, сколько ни исходи. Другой вопрос — насколько это удобно реализовано в том или ином случае.

Да, согласен. В случае С++ всё реализовано максимально неудобно.

ГВ>Посему оглядываться им было, ИМХО, некуда.

А, ну ладно. Тогда интересно то, что STL, который вроде как младше Qt, оказался настолько хуже.

ГВ>Требования по API сформулируешь? Нет требований — нет библиотек. И вообще — что такое "невозможно написать" в смысле упаковки кучи API под другим API? Этих слов моя не знать.

Зачем тут требования по API? Вот у меня есть задача: получив строку unicode символов, перекодировать её в кодировку X. Где X, скажем, заранее неизвестно.
Вторичная задача: эта библиотека должна быть совместима с максимальным количеством других библиотек, которые работают со строками. Потому что сама по себе задача преобразования кодировок не нужна. Нужно, например, уметь читать письма по IMAP протоколу, и я не хочу, чтобы этот конвертер был привязан к конкретной библиотеке работы с IMAP.

Это всё очевидные вещи для всех разработчиков, которые работают на взрослых платформах. См. например System.Text.Encoding.

ГВ>"Нет" по последнему утверждению, по остальным — "да". Только ты что-то путаешь, это не мантры, а объективная реальность. Я понимаю, что ступаю тут на зыбкую почву попыток убедить собеседника в том, что он считает нечто действующее мантрами, но...

Жду в студию убедительных доказательств.

ГВ>Ну, извини, если ты считаешь, что без оглядки на "стандарты" ничего нельзя писать, это уж и не знаю, прямо. Какое-то сильно крутое колдунство для меня, во всяком случае.

Ну почему же нельзя — можно. Вот только без стандартов это очень неэффективно. Повторное использование затруднено. Получается, что нельзя просто взять и использовать некую произвольную библиотеку "на языке С++". Потому что она не на языке, а на платформе. Ну вот нужна мне, скажем, работа с Zip — архивами. Для MFC-приложения она должна быть написана в одном стиле, для QT — в другом, для boost — в третьем. Либо потребуется некий wrapper для каждой платформы, который буду писать либо я либо автор библиотеки.

Весь этот код — лишний. Вы можете сколько угодно делать вид, что всё в порядке и никаких проблем нету. Суровая реальность от этого никак не изменится: С++ — это не платформа, это инструмент для построения платформ.
А прикладным программистам инструмент не нужен; им нужна платформа, на которой они могут писать полезные приложения. И чем больше вопросов платформа покрывает, и чем больше вариантов ответов на эти вопросы она даёт, тем более зрелой эта платформа является.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[24]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 02.10.09 20:24
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

S>При чём тут мантра? Это — констатация факта. Ты его опровергнуть хочешь? Ну так покажи мне стандарт на приведение кодировок.

Мантру я углядел в смысле ужасности отсутствия стандартов.

S>>>QString, допустим, умеет. Ну, то есть QString, понятное дело, умеет только латин1 и utf-8, что абсолютно верно. А всё остальное умеет, понятное дело, QTextCodec. И он, конечно же, никакого стандарта не реализует. Поэтому, к примеру, прикрутить это к CString будет крайне затруднительно. Ну, то есть самый простой способ — работать на уровне char*, что и есть единственный реальный "стандарт строки в С++". При этом, конечно же, внезапно окажется, что производительность такого конвертера сильно хуже, чем у соседей — потому, что у char* нет заранее известной длины, и кодеку придётся многократно перевыделять внутренний буфер.


ГВ>>Почему обязательно нужно пользоваться самым простым способом — через char*, когда нужна скорость и под боком имеется длина? Зачем многократно перевыделять буфер? Максимальный размер кода символа в указанной кодировке — неизвестная величина?

S>Ну, покажи мне непростой способ. Вот есть у меня, скажем CEdit. И хочу введённую туда пользователем строку теперь сконвертировать в, скажем, UTF7 и сохранить в файл. Покажи мне, как это делается умными людьми.

MultiByteToWideChar, ы? Уж коль скоро мы про CEdit. Да, если очень захочется универсальности, то придётся накрыть её шаблоном. Возможность предвыделения буфера прямо зависит от того, реализована оная в той или иной строке или нет. CString, например, это допускает. Но если остро нужна скорость, то здесь будут другие подходы, например, буфер сразу полетит на диск, минуя промежуточное заворачивание в строковые объекты. WriteFile, знаешь такую? Буфер для UTF7 вообще можно выделять на стеке, коль острая нужда есть. Я тебя что-то не совсем понимаю, ты точно понял, о чём я говорил?

ГВ>>Анархия — мать порядка. Как раз в таком "бардаке" и воспитывается умение организовывать свои собственные мысли. А эта пушка посильнее любых стандартов будет.

S>Да-да-да. Это всё мы уже слышали. "С++ — насолько сложный язык, что в нём выживают только самые умные программисты". Увы, это враньё. Практика ничего подобного не показывает.

Угу, я уже это давно заметил. Особенно интересно звучит в рамках другой максимы: "Умные нам не нужны, нам нужны послушные". Гы-гы.

S>Всё, чему помогает сложность языка — это удорожание разработки на нём.


Ясное дело, дежурный жупел.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 02.10.09 20:25
Оценка:
Здравствуйте, Sinclair, Вы писали:

ГВ>>Угу. И все платформы на одном и том же языке — красота!

S>Толку-то! Не получается взять так и просто подружить две платформы — приходится писать много boilerplate кода.
S>Там, где программист на C# или Java пишет в отчёте "выбор библиотеки — 8 часов, проверка в проекте — 2 часа", С++ программист пишет "выбор библиотеки — 1 час, прикручивание в проект и написание врапперов — 40 часов".

Ну это твои мрачные фантазии. Заморочки. которые потребуют потратить 40 часов на прикручивание могут встретиться в любой библиотеке на любом языке. Так уж оно всё устроено.

ГВ>>Между собой? В смысле? Может, ты имел в виду совместимость с контейнерами?

S>И между собой, и с контейнерами.

Ну так, раз написаны под определённые контейнеры, то очевидно с ними и совместимы. Если кому-то взбредёт в голову написать свою версию контейнеров, не согласованную со спецификацией EJB, то окажутся не совместимыми.

S>>>Доступ к реляционнным данным всегда делается через JDBC.

ГВ>>Много ты знаешь распространённых "тяжёлых" СУБД, для которых интерфейс Java роднее C? Вот и я не знаю. Далее делаем простые выводы.
S>Термин "роднее" мне неизвестен. Как неизвестны и СУБД, для которых нет JDBC-драйвера. Вот и делаем простые выводы: низкоуровневые С-библиотеки хороши для написания vendor-specific tools, а для написания бизнес-приложений никто dblib уже десять лет как неиспользует. Спуститесь с небес на землю (или вам там наоборот, подняться надо?)

Земля, небеса... Для всех СУБД есть и ODBC-драйвера. Я имел в виду, что JDBC разрабатывался очень сильно после интерфейсов основных СУБД.

ГВ>>Угу, будем. В случае общего API вполне допустимая абстракция.

S>
S>Боюсь, это всё же разные библиотеки. Особенно с учётом того, что их можно использовать одновременно.

Я сказал про абстракцию использования. Понятно, что "внутри" они разные.

ГВ>>Давай так: стандартизация API — отдельно, котлеты — отдельно, интероп — на третье. Кому что надо, те то стандартизируют. И вообще, ИМХО, обилие стандартов в Java как раз свидетельствует о неких врождённых недостатках самой Java: без "синергии миллионов стандартизаторов" ни бэ, ни мэ, ни кукареку.

S>Вот то-то и оно. Пока С++ безнадёжно пытается стандартизовать хотя бы compiled templates, то есть самый низкий уровень платформы, парни в Виллариба уже давно стандартизуют что-то поинтереснее.

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

ГВ>>Потом, что касается интеропа, то вот тут как раз C и C++ равных нет в смысле возможностей интеропа с кем угодно. Причины я кратко объяснил чуть выше. И ничего ты с этим не сделаешь, сколько ни исходи. Другой вопрос — насколько это удобно реализовано в том или ином случае.

S>Да, согласен. В случае С++ всё реализовано максимально неудобно.

По первой части предложения, как я понимаю, возражений нет. Хорошо. А удобство — дело наживное.

ГВ>>Посему оглядываться им было, ИМХО, некуда.

S>А, ну ладно. Тогда интересно то, что STL, который вроде как младше Qt, оказался настолько хуже.

Он не хуже, он другой. Почему разработчики STL должны были оглядываться именно на Qt?

ГВ>>Требования по API сформулируешь? Нет требований — нет библиотек. И вообще — что такое "невозможно написать" в смысле упаковки кучи API под другим API? Этих слов моя не знать.

S>Зачем тут требования по API?

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

S>Вот у меня есть задача: получив строку unicode символов, перекодировать её в кодировку X. Где X, скажем, заранее неизвестно.

S>Вторичная задача: эта библиотека должна быть совместима с максимальным количеством других библиотек, которые работают со строками. Потому что сама по себе задача преобразования кодировок не нужна. Нужно, например, уметь читать письма по IMAP протоколу, и я не хочу, чтобы этот конвертер был привязан к конкретной библиотеке работы с IMAP.

Вот и давай — построй индукцию на обобщённый API для решения этой задачи. Выведи универсальные требования, а там и посмотрим, что реализуемо, а что — нет.

S>Это всё очевидные вещи для всех разработчиков, которые работают на взрослых платформах. См. например System.Text.Encoding.


И почему я не удивлён, что ты отослал меня именно к System.Text.Encoding?

ГВ>>"Нет" по последнему утверждению, по остальным — "да". Только ты что-то путаешь, это не мантры, а объективная реальность. Я понимаю, что ступаю тут на зыбкую почву попыток убедить собеседника в том, что он считает нечто действующее мантрами, но...

S>Жду в студию убедительных доказательств.

Мои доказательства ничего тебе не докажут, и это большая проблема. Ты будешь ждать решения в одну строку, взятое из "стандартов", а меня привлекают понятные механизмы реализации. Не договоримся. Так что, придётся тебе просто принять на веру, что не все умозрительные рассуждения об "ужасах C++" соответствуют практической действительности — в конце концов, это не более, чем эмоционально окрашенные мнения.

ГВ>>Ну, извини, если ты считаешь, что без оглядки на "стандарты" ничего нельзя писать, это уж и не знаю, прямо. Какое-то сильно крутое колдунство для меня, во всяком случае.

S>Ну почему же нельзя — можно. Вот только без стандартов это очень неэффективно. Повторное использование затруднено.

Ошибка. Повторное использование затрудняется при отсутствии повторно используемых компонент. Если таковые или их аналоги есть, то нет проблемы и в повторном использовании. А стандарты — дело десятое.

S>Получается, что нельзя просто взять и использовать некую произвольную библиотеку "на языке С++". Потому что она не на языке, а на платформе. Ну вот нужна мне, скажем, работа с Zip — архивами.


Zlib — и понеслась.

S>Для MFC-приложения она должна быть написана в одном стиле, для QT — в другом, для boost — в третьем. Либо потребуется некий wrapper для каждой платформы, который буду писать либо я либо автор библиотеки.


И снова ошибка. Она никому ничего не должна. И я, как пользователь boost+Qt+zlib тоже никому ничего не должен, враппер над zlib пишется по необходимости и под требования задачи или предполагаемой задачи. Нет никакой нужды пользоваться Qt-specific или boost-specific style исключительно потому, что они вот такие вот большие и красивые. Я уж давно пишу в нескольких стилях одновременно и ни капли не огорчаюсь.

S>Весь этот код — лишний. Вы можете сколько угодно делать вид, что всё в порядке и никаких проблем нету. Суровая реальность от этого никак не изменится: С++ — это не платформа, это инструмент для построения платформ.


Молодец, правильно. C++ никто никогда в здравом уме и трезвой памяти "платформой" и не называл за исключением апологетов разнообразных "платформ". Только это инструмент с богатым выбором дополнительного проблемно-ориентированного инструментария, реализованного на нём же. Понятно, что он не обладает теми же чертами, что и специализированные инструменты для прикладного программирования (GC как раз из этой области). Проблема в другом — это не повод называть его "убогим" на основании, скажем, сравнения ISO/IEC 14882:1998 со спецификацией EJB, само сравнение некорректно. Сравнивайте на здоровье .Net, Java, что там у нас ещё на слуху? C++ вообще ортогонален этим платформам.

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


Угу, им универсальный всемогутер нужен.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: Тьфу, опечатка
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 02.10.09 20:29
Оценка:
ГВ>MultiByteToWideChar, ы?

WideCharToMultiByte, разумеется.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: шаблоны С++ и дженерики С#
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 04.10.09 16:40
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>MultiByteToWideChar, ы?

Пример — в студию. С нетерпением жду применения этой функции для конверсии в UTF7.
ГВ>Уж коль скоро мы про CEdit. Да, если очень захочется универсальности, то придётся накрыть её шаблоном. Возможность предвыделения буфера прямо зависит от того, реализована оная в той или иной строке или нет.
ГВ> CString, например, это допускает. Но если остро нужна скорость, то здесь будут другие подходы, например, буфер сразу полетит на диск, минуя промежуточное заворачивание в строковые объекты. WriteFile, знаешь такую? Буфер для UTF7 вообще можно выделять на стеке, коль острая нужда есть. Я тебя что-то не совсем понимаю, ты точно понял, о чём я говорил?
Я точно уверен только в одном: ты вообще не понял, о чём я говорил. Ты вот не умничай, а напиши пример с записью строки из CEdit на диск в кодировке UTF-7. Желательно, конечно, так, чтобы это не было пессимизацией на ровном месте.
Может быть, после этого на одного из нас снизойдёт просветление?

ГВ>Угу, я уже это давно заметил. Особенно интересно звучит в рамках другой максимы: "Умные нам не нужны, нам нужны послушные". Гы-гы.

Это ты сам себе придумал. Наша практика показывает, что на удобном языке умные достигают лучших результатов, чем на корявом. А неумным никакой язык не помогает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[26]: шаблоны С++ и дженерики С#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.10.09 22:01
Оценка:
Здравствуйте, Sinclair, Вы писали:

ГВ>>MultiByteToWideChar, ы?

S> Пример — в студию. С нетерпением жду применения этой функции для конверсии в UTF7.

В MSDN посмотри. Только не MultiByteToWideChar, а WideCharToMultiByte, я рядом написал. Для UTF7 применение проще пареной репы.

ГВ>>Уж коль скоро мы про CEdit. Да, если очень захочется универсальности, то придётся накрыть её шаблоном. Возможность предвыделения буфера прямо зависит от того, реализована оная в той или иной строке или нет.

ГВ>> CString, например, это допускает. Но если остро нужна скорость, то здесь будут другие подходы, например, буфер сразу полетит на диск, минуя промежуточное заворачивание в строковые объекты. WriteFile, знаешь такую? Буфер для UTF7 вообще можно выделять на стеке, коль острая нужда есть. Я тебя что-то не совсем понимаю, ты точно понял, о чём я говорил?
S>Я точно уверен только в одном: ты вообще не понял, о чём я говорил.

Тогда объясни так, чтобы стало понятно.

S>Ты вот не умничай, а напиши пример с записью строки из CEdit на диск в кодировке UTF-7. Желательно, конечно, так, чтобы это не было пессимизацией на ровном месте.

S>Может быть, после этого на одного из нас снизойдёт просветление?

Ты тень на плетень не наводи, а объясни сначала толком, под какую задачу. Апелляция к преждевременной пессимизации в контексте извлечения строки из CEdit, это, мягко говоря, весьма необычная синтетика. Или ты про вот это:

Зачем тут требования по API? Вот у меня есть задача: получив строку unicode символов, перекодировать её в кодировку X. Где X, скажем, заранее неизвестно.
Вторичная задача: эта библиотека должна быть совместима с максимальным количеством других библиотек, которые работают со строками. Потому что сама по себе задача преобразования кодировок не нужна. Нужно, например, уметь читать письма по IMAP протоколу, и я не хочу, чтобы этот конвертер был привязан к конкретной библиотеке работы с IMAP.


?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.