CLI/C++
От: Аноним  
Дата: 30.12.03 23:34
Оценка:
Добрый день!

У меня возник простой вопрос: КОГДА ВЫЙДЕТ CLI/C++,
то есть это будет реализовано в новой версии студии?
И в каком году, в каком месяце можно ждать его появления....

Спасибо — С новым годом

10.01.04 12:52: Перенесено модератором из '.NET' — TK
Re: CLI/C++
От: IT Россия linq2db.com
Дата: 31.12.03 00:22
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>У меня возник простой вопрос: КОГДА ВЫЙДЕТ CLI/C++,

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

Manager C++ существует уже почти два года — Управляемый C++
Автор(ы): Игорь Ткачёв
Дата: 05.02.2002
До сих пор трудно ответить на вопрос, что такое .Net. Эта статья, являясь введением в Managed Extensions for C++ (MC++), содержит описание ряда смелых экспериментов советских ученых, наконец-то позволяющих понять, что же такое .Net вообще, и место MC++ в нем, в частности.
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: CLI/C++
От: WolfHound  
Дата: 31.12.03 06:12
Оценка:
Здравствуйте, IT, Вы писали:

IT>Manager C++ существует уже почти два года — Управляемый C++
Автор(ы): Игорь Ткачёв
Дата: 05.02.2002
До сих пор трудно ответить на вопрос, что такое .Net. Эта статья, являясь введением в Managed Extensions for C++ (MC++), содержит описание ряда смелых экспериментов советских ученых, наконец-то позволяющих понять, что же такое .Net вообще, и место MC++ в нем, в частности.

Сравнил...
Пример из презентации.

2IT: Поврори на МС++...
void Transfer() 
{
    MessageQueue    source( "server\\sourceQueue" );
    String^ qname = (String^)source.Receive().Body;
    MessageQueue    dest1( "server\\" + qname ),
                      dest2( "backup\\" + qname );
    Message^ message = source.Receive();
    dest1.Send( message );
    dest2.Send( message );
}


Minimal C# equivalent:
void Transfer() 
{  
    using( MessageQueue source = new MessageQueue( "server\\sourceQueue" ) ) 
    {
        String qname = (String)source.Receive().Body;
        using( MessageQueue    dest1 = new MessageQueue( "server\\" + qname ),
                                dest2 = new MessageQueue( "backup\\" + qname ) ) 
        {
            Message message = source.Receive();
            dest1.Send( message );
            dest2.Send( message );
        }
    }
}


Minimal VB/Java equivalent (in C# syntax):
void Transfer() 
{
    MessageQueue    source = null, 
                    dest1 = null, 
                    dest2 = null;
    try 
    {
        source = new MessageQueue( "server\\sourceQueue" );
        String qname = (String)source.Receive().Body;
        dest1 = new MessageQueue( "server\\" + qname );
        dest2 = new MessageQueue( "backup\\" + qname );
        Message message = source.Receive();
        dest1.Send( message );
        dest2.Send( message );
    }
    finally 
    {
        if( dest2 != null ) 
        { 
            dest2.Dispose(); 
        }
        if( dest1 != null ) 
        { 
            dest1.Dispose(); 
        }
        if( source != null ) 
        { 
            source.Dispose(); 
        }
    }
}


ЗЫ По слухам в бетте Видби должен быть немного не доделаный C++/CLI
ЗЗЫ Презентация для тех кто еще не видел. (1,414,656 bytes)
ЗЗЗЫ Of course, any type can be templated:
    template<class T>
    ref class ARefTemplate { /*…*/ };    // ok
2IT: Ну и где твой МС++ после этого?
...
ЗЗЗЗЫ Продолжать можно долго. Короче MC++ рядом с C++/CLI не стояло.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: CLI/C++
От: IT Россия linq2db.com
Дата: 31.12.03 07:27
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

2IT: Ну и где твой МС++ после этого?

Мой MC++ установлен на моей машине и я им пользуюсь когда мне это необходимо. А вот где твой C++/CLI? В бете видби? И выйдет в свет не раньше чем через год? Ну-ну. Пока можешь развлекаться разглядыванием презентаций

Кстати, насчёт нововведений. Видимо доработать C++ и при этом не изуродовать его, так у них и неполучилось. А жаль.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: CLI/C++
От: alexkro  
Дата: 31.12.03 21:07
Оценка:
Здравствуйте, IT, Вы писали:

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


IT>2IT: Ну и где твой МС++ после этого?


IT> Мой MC++ установлен на моей машине и я им пользуюсь когда мне это необходимо. А вот где твой C++/CLI? В бете видби? И выйдет в свет не раньше чем через год?


Release должен быть в конце 2004. А beta — в начале.

> Ну-ну. Пока можешь развлекаться разглядыванием презентаций


IT>Кстати, насчёт нововведений. Видимо доработать C++ и при этом не изуродовать его, так у них и неполучилось. А жаль.


В смысле? Где это он изуродован?

Меня больше волнует будет ли ощутимое различие в стиле программирования. Ведь C++ — это язык с copy semantics (объекты предпочтительно передаются по значению, отсюда swap идиома, и т.д.), а .NET с его GC предпологает move semantics (все по ссылке). Это то, что для меня прежде всего отличало C++ от C#, например. Так как на C++/CLI еще никто ничего существенного не писал, остается только предпологать какое влияние это на него окажет. Хотя возможность создавать объекты reference типов на стеке, несомненно, радует.
Re[4]: CLI/C++
От: WolfHound  
Дата: 31.12.03 21:24
Оценка:
Здравствуйте, IT, Вы писали:

IT> Мой MC++ установлен на моей машине и я им пользуюсь когда мне это необходимо. А вот где твой C++/CLI? В бете видби? И выйдет в свет не раньше чем через год? Ну-ну. Пока можешь развлекаться разглядыванием презентаций

Я пока буду писать на С++ всеравно текущий проект еще черти сколько времени писать будем.

IT>Кстати, насчёт нововведений. Видимо доработать C++ и при этом не изуродовать его, так у них и неполучилось. А жаль.

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

ЗЫ Дык как на счет того чтобы на МС++ примерчик повторить? Там в оригинале на C++/CLI всего 7 строк. Ы?
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: CLI/C++
От: IT Россия linq2db.com
Дата: 31.12.03 23:33
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Я пока буду писать на С++ всеравно текущий проект еще черти сколько времени писать будем.


Так зачем тебе тогда C++/CLI?
И вообще, переходи на C#, как минимум в два раза быстрее получится

IT>>Кстати, насчёт нововведений. Видимо доработать C++ и при этом не изуродовать его, так у них и неполучилось. А жаль.

WH>И что же они изуродовали?

Ты находишь что два синтаксических элемента для определения одной программной сущности это найс?

WH>Ты знаешь что мой основной язык С++, ты знаешь что я на нам могу сделать...


Ой-ой-ой! А ты знаешь что я могу на шарпе сделать? Все твои шаблоны по сравнению с эмитом и атрибутами — это детский сад. А если Влад напишет R#, то я ваще молчу.

WH>И я ни чего уродливого в этих нововведениях (судя по презентации) не заметил. Про МС++ я тоже самое сказать не могу.


Да ну? А конструкции типа __gc, __box и т.п. тебя не коробят? Хотя видимо после прочтения Александреску уже мало что поможет

WH>ЗЫ Дык как на счет того чтобы на МС++ примерчик повторить? Там в оригинале на C++/CLI всего 7 строк. Ы?


А ты сам то сможешь? Говорят ты такое можешь делать...
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: CLI/C++
От: WolfHound  
Дата: 01.01.04 10:54
Оценка:
Здравствуйте, IT, Вы писали:

IT>Так зачем тебе тогда C++/CLI?

Для будущих проектов
IT>И вообще, переходи на C#, как минимум в два раза быстрее получится
Чем на C++/CLI? Сильно сомневаюсь.

WH>>И что же они изуродовали?

IT>Ты находишь что два синтаксических элемента для определения одной программной сущности это найс?
Это где? Ах да ты про SomeType^ и SomeType*? Если да то это не одно и тоже. Первый вариант это совсем не С++ указатель это больше похоже на смартпоинтер что-то типа gc_ptr<SomeType> только вынесено на уровень языка. Надеюсь не надо обьяснять что С++ указатель в отличии от смартпоинтера является итератором произвольного доступа (для смартпоинтеров это не имеет смысла).

IT>Ой-ой-ой! А ты знаешь что я могу на шарпе сделать?

Мне извесны возможности шарпа. Крайне не удобный язык. Средств для повторного использования кода по сравнения с С++ почти нет. Скоро появятся генерики это конечно уже коечто но подключения реализации всеравно не будет.
IT>Все твои шаблоны по сравнению с эмитом и атрибутами — это детский сад.
Ага и чтобы это работало на Win95 с 4М памяти(я конечно слегка утрировал но тачки с Win98 и 16М у наших клиентов пока не редкость начальство обещает боротся но это требует времени)... Надеюсь ты не думал что такие тачки уже совсем вымерли... Это еще что... у меня прорва ресурсов... наши соседи на асме пишут... байты считают...
IT>А если Влад напишет R#, то я ваще молчу.
Безумству храбрых... Только мне почемуто кажется что MS C++/CLI раньше выпустит. И наворотов в C++/CLI будет мнОго больше.

WH>>И я ни чего уродливого в этих нововведениях (судя по презентации) не заметил. Про МС++ я тоже самое сказать не могу.

IT>Да ну? А конструкции типа __gc, __box и т.п. тебя не коробят? Хотя видимо после прочтения Александреску уже мало что поможет
Еще раз MC++ != C++/CLI гды ты в C++/CLI видел __gc, __box...? Ы?
И насколько я понял Саттера, Александреску принимает участие в разработке C++/CLI в качастве консультанта. Смотрит за тем чтобы C++/CLI был максимально в стиле С++.

WH>>ЗЫ Дык как на счет того чтобы на МС++ примерчик повторить? Там в оригинале на C++/CLI всего 7 строк. Ы?

IT> А ты сам то сможешь? Говорят ты такое можешь делать...
Ты от ответа не уходи. Не я считаю что MC++ == C++/CLI.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: CLI/C++
От: WolfHound  
Дата: 01.01.04 14:05
Оценка: 5 (1) :))
Здравствуйте, alexkro, Вы писали:

A>Меня больше волнует будет ли ощутимое различие в стиле программирования.

По сравнению с чем если с С++ то не думаю.
A>Ведь C++ — это язык с copy semantics (объекты предпочтительно передаются по значению, отсюда swap идиома, и т.д.), а .NET с его GC предпологает move semantics (все по ссылке).
Хм. У меня в программе на С++ очень много ссылочных объектов.
A>Это то, что для меня прежде всего отличало C++ от C#, например.
А по мне главное преймущество С++ перед шарпом это возможность без гемороя сделать детерминированое разрушение объектов.
A>Так как на C++/CLI еще никто ничего существенного не писал, остается только предпологать какое влияние это на него окажет.
Ни на что ссылочные объекты не повлияют. Ибо в нормальных С++ программах всеравно почти ни что не копируется.
A>Хотя возможность создавать объекты reference типов на стеке, несомненно, радует.
Нет такой возможности. Это всеголишь небольшой трюк разработчиков. На стеке создается лишь объект который дергает Dispose.
Это просто болие удобная запись такой конструкции.
C++/CLI
MessageQueue source( "server\\sourceQueue" );

C#
using( MessageQueue source = new MessageQueue( "server\\sourceQueue" ) )

Но! Это еще семечки.
C++/CLI
ref class some_class
{
    MessageQueue source;
    some(String^ path)
        :source(path)
    {}
};

C#
class some_class
    :IDisposable
{
    MessageQueue source;
    some(String path)
    {
        source=new MessageQueue(path);
    }
    void Dispose()
    {
        source->Dispose();
    }
};


Про шаблоны я вобще молчу... И не надо мне про генерики я знаю на что они способны. Да и будут они в C++/CLI.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: CLI/C++
От: alexkro  
Дата: 01.01.04 20:48
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


A>>Хотя возможность создавать объекты reference типов на стеке, несомненно, радует.

WH>Нет такой возможности. Это всеголишь небольшой трюк разработчиков. На стеке создается лишь объект который дергает Dispose.

В языке есть. А как это реализуется это уже совсем другой вопрос.
Re[7]: CLI/C++
От: IT Россия linq2db.com
Дата: 01.01.04 21:42
Оценка: 14 (1) +1 -2 :)
Здравствуйте, WolfHound, Вы писали:

IT>>Так зачем тебе тогда C++/CLI?

WH>Для будущих проектов

Понятно. А пока довольствуемся презентациями

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

WH>Чем на C++/CLI? Сильно сомневаюсь.

Не сомневайся. Быстрее как минимум на год

WH>Это где? Ах да ты про SomeType^ и SomeType*? Если да то это не одно и тоже. Первый вариант это совсем не С++ указатель это больше похоже на смартпоинтер что-то типа gc_ptr<SomeType> только вынесено на уровень языка. Надеюсь не надо обьяснять что С++ указатель в отличии от смартпоинтера является итератором произвольного доступа (для смартпоинтеров это не имеет смысла).


Это всё твои домыслы. Это та же ссылка, только в хипе GC. По большому счёту это и есть вся разница. Тем не менее я как программист должен постоянно помнить в какой куче был создан объект и использовать разные козябры. При этом компилятор и без меня лучше знает что к чему. В общем, чушь. Лишний элемент, делающий из C++ динозавра типа PL/1.

IT>>Ой-ой-ой! А ты знаешь что я могу на шарпе сделать?

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

Ты на шарпе сколько строчек написал? Хотя бы один более менее серьёзный проект сделал? Вот сначала сделай, а потом скажешь какой язык крайне не удобный.

IT>>Все твои шаблоны по сравнению с эмитом и атрибутами — это детский сад.

WH>Ага и чтобы это работало на Win95 с 4М памяти(я конечно слегка утрировал но тачки с Win98 и 16М у наших клиентов пока не редкость начальство обещает боротся но это требует времени)... Надеюсь ты не думал что такие тачки уже совсем вымерли... Это еще что... у меня прорва ресурсов... наши соседи на асме пишут... байты считают...

Так а зачем тебе тогда C++/CLI? Он тебе тоже не поможет. У тебя прямой путь в веб-интерфейс, там ресурсов много не надо и даже такой металлолом работать будет.

IT>>А если Влад напишет R#, то я ваще молчу.

WH> Безумству храбрых... Только мне почемуто кажется что MS C++/CLI раньше выпустит. И наворотов в C++/CLI будет мнОго больше.

Что там будет понятно. Все навороты описаны в презентации.

WH>>>И я ни чего уродливого в этих нововведениях (судя по презентации) не заметил. Про МС++ я тоже самое сказать не могу.

IT>>Да ну? А конструкции типа __gc, __box и т.п. тебя не коробят? Хотя видимо после прочтения Александреску уже мало что поможет
WH>Еще раз MC++ != C++/CLI гды ты в C++/CLI видел __gc, __box...? Ы?

Выделенное разве не твоё?

WH>>>ЗЫ Дык как на счет того чтобы на МС++ примерчик повторить? Там в оригинале на C++/CLI всего 7 строк. Ы?

IT>> А ты сам то сможешь? Говорят ты такое можешь делать...
WH>Ты от ответа не уходи. Не я считаю что MC++ == C++/CLI.

А кто тебе сказал что я так считаю? Я считаю, что лучше использовать то, что уже есть и вполне прилично работает, а не ждать годами новых фич от MS.
Хотя, каждому своё
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: CLI/C++
От: WolfHound  
Дата: 02.01.04 13:20
Оценка:
Здравствуйте, IT, Вы писали:

WH>>Чем на C++/CLI? Сильно сомневаюсь.

IT>Не сомневайся. Быстрее как минимум на год
Судя по презентции код на C++/CLI короче чем на шарпе дык с какого ты взял целый год тормозов на C++/CLI?
Короче в чем C++/CLI уступает шарпу. Только не надо размытых фраз типа шарп проще. Давай конкретно.

IT>Это всё твои домыслы. Это та же ссылка, только в хипе GC. По большому счёту это и есть вся разница. Тем не менее я как программист должен постоянно помнить в какой куче был создан объект и использовать разные козябры. При этом компилятор и без меня лучше знает что к чему. В общем, чушь. Лишний элемент, делающий из C++ динозавра типа PL/1.

Ты вобще презентушку смотрел? Компилятор не может знать где создан объект исходя из его типа (ибо new и gcnew) ибо натив обьект можно создать в ГЦ хипе и ГЦ объект в натив хипе.
Надеюсь не надо обьяснять в чем разница между натив указателем и ГЦ ссылкой.

IT>Ты на шарпе сколько строчек написал? Хотя бы один более менее серьёзный проект сделал? Вот сначала сделай, а потом скажешь какой язык крайне не удобный.

Около 20К строк. Знаю что не много но для того чтобы получить представление об языке ИМХО достаточно.

WH>>Ага и чтобы это работало на Win95 с 4М памяти(я конечно слегка утрировал но тачки с Win98 и 16М у наших клиентов пока не редкость начальство обещает боротся но это требует времени)... Надеюсь ты не думал что такие тачки уже совсем вымерли... Это еще что... у меня прорва ресурсов... наши соседи на асме пишут... байты считают...

IT>Так а зачем тебе тогда C++/CLI? Он тебе тоже не поможет. У тебя прямой путь в веб-интерфейс, там ресурсов много не надо и даже такой металлолом работать будет.
См выделеное. А с интерфейсом проблем нет. Его очень не плохо в дебилдере рисуют.
А что касается C++/CLI то у меня кроме интерфейса столько делать надо что Короче в следующем проекте фреймворк, рефлекшен, емит, генерики, шаблоны и препроцессор будут задействованы на всю катушку(не или почти на всю).

WH>> Безумству храбрых... Только мне почемуто кажется что MS C++/CLI раньше выпустит. И наворотов в C++/CLI будет мнОго больше.

IT>Что там будет понятно. Все навороты описаны в презентации.
И что мало? Что такое революционное собирается сделать Влад? И сможет ли он сделать компилятор промышленного качества? А сколько займет это времени? А бета Видби будет в мае.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: CLI/C++
От: IT Россия linq2db.com
Дата: 02.01.04 15:56
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>Чем на C++/CLI? Сильно сомневаюсь.

IT>>Не сомневайся. Быстрее как минимум на год
WH>Судя по презентции код на C++/CLI короче чем на шарпе дык с какого ты взял целый год тормозов на C++/CLI?

С такого, что релиз C++/CLI будет только через год

WH>Короче в чем C++/CLI уступает шарпу. Только не надо размытых фраз типа шарп проще. Давай конкретно.


См. выше.

WH>Ты вобще презентушку смотрел? Компилятор не может знать где создан объект исходя из его типа (ибо new и gcnew) ибо натив обьект можно создать в ГЦ хипе и ГЦ объект в натив хипе.


Нейтив объект нельзя создать в GC-хипе, это понятно и без презентации. В GC-хипе создаётся проксик. Тоже самое и с GC-объектами. Они создаются только в GC-хипе, а на стеке для них опять же создаётся только прокси. При этом прокси лишь управляют временем жизни объекта, но никак не влияют не его тип. Соответственно информация о том в каком хипе создан объект может быть однозначно получена из его типа. А раз так, то зачем вводить дополнительные языковые конструкции. Для того лишь что-бы отделять прокси от ссылок? Ну тут, во первых, я бы с лёгкостью пожертвовал такой возможностью (создание прокси для GC-объектов на стеке при этом всё равно синтаксически остаётся возможным) ради упрощения языка. А во-вторых, ту же самую возможность можно было бы добавить путём введения дополнительных встроенных типов аля gc_ptr<>. Сейчас же получается, что возможность, которая не нужна в 99% случаев будет заставлять тебя помнить о ней и использовать её постоянно.

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

WH>Надеюсь не надо обьяснять в чем разница между натив указателем и ГЦ ссылкой.


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

IT>>Ты на шарпе сколько строчек написал? Хотя бы один более менее серьёзный проект сделал? Вот сначала сделай, а потом скажешь какой язык крайне не удобный.

WH>Около 20К строк. Знаю что не много но для того чтобы получить представление об языке ИМХО достаточно.

И после этого ты утвержаешь, что разработка на C++ круче? Значит ты не делал больших проектов на C++

WH>См выделеное. А с интерфейсом проблем нет. Его очень не плохо в дебилдере рисуют.


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

WH>А что касается C++/CLI то у меня кроме интерфейса столько делать надо что Короче в следующем проекте фреймворк, рефлекшен, емит, генерики, шаблоны и препроцессор будут задействованы на всю катушку(не или почти на всю).


Понятно. Из одной крайности в другую.

IT>>Что там будет понятно. Все навороты описаны в презентации.

WH>И что мало? Что такое революционное собирается сделать Влад?

Расширяемый компилятор, AOP во всей красе, может ещё чего.

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




WH>А сколько займет это времени?


Ровно столько на сколько у него хватит энтузизизма

WH>А бета Видби будет в мае.


Бета — это не релиз. Ни один вменяемый мэнеджер не станет делать проект на бете.
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: CLI/C++
От: WolfHound  
Дата: 02.01.04 20:00
Оценка: +1
Здравствуйте, IT, Вы писали:

IT>Нейтив объект нельзя создать в GC-хипе, это понятно и без презентации. В GC-хипе создаётся проксик. Тоже самое и с GC-объектами. Они создаются только в GC-хипе, а на стеке для них опять же создаётся только прокси. При этом прокси лишь управляют временем жизни объекта, но никак не влияют не его тип. Соответственно информация о том в каком хипе создан объект может быть однозначно получена из его типа. А раз так, то зачем вводить дополнительные языковые конструкции. Для того лишь что-бы отделять прокси от ссылок? Ну тут, во первых, я бы с лёгкостью пожертвовал такой возможностью (создание прокси для GC-объектов на стеке при этом всё равно синтаксически остаётся возможным) ради упрощения языка. А во-вторых, ту же самую возможность можно было бы добавить путём введения дополнительных встроенных типов аля gc_ptr<>. Сейчас же получается, что возможность, которая не нужна в 99% случаев будет заставлять тебя помнить о ней и использовать её постоянно.

Хоть бы 3 минуты подумал почему это сделано. См ниже.
IT>Возможно, есть более глубокие причины, почему сделано именно так, но пока я не могу найти вразумительного ответа.
А то.
Есть нативный класс SomeNativeClass создаем объект этого класса при помощи gcnew SomeNativeClass если следовать твоей логике то указатель на SomeNativeClass ВСЕГДА должен быть нативным и тот прокси который создавал gcnew должен быть проигнорирован те сразуже после создания объекта не остается ни одной живой ГЦ ссылки те даже если на объект будут продолжать ссылатся ГЦ об этом не узнает ни когда и убет обект при первой же сборке мусора не смотря на то что бъект все еще нужен.
Для ГЦ классов созлданных с помощью new таже фигня указатель на нативный прокси будет утерян без возвратно сразуже после создвния объекта и ГЦ всегда будет видеть покрайней мере одну живую ссылку (ту что в потеряной проксе).
Продолжая следовать твоей логие приходим к выводу что gcnew стал вреден ибо прокси всеравно всегда игнорируются, а проигнорированые прокси как показано выше очень большие грабли следовательно к чертям gcnew пусть компилятор сам разбирается что есть где...
Итого:
Это как я понял тебе не нужно
Semantically, a C++ program can create object of any type T in any storage location:
    On the native heap:    T* t1 = new T;
        As usual, pointers (*) are stable, even during GC
        As usual, failure to explicitly call delete will leak
    On the gc heap:        T^ t2 = gcnew T;
        Handles (^) are object references (to whole objects)
        Calling delete is optional: "Destroy now, or finalize later."
И это мелочи
Native pointers (*) and handles (^):
^ is like *, except ^ points to a whole object on the gc heap, 
can’t be ordered, and can’t be cast to void* (or integral type) and back. (There is no void^.)
И это тудаже
Boxing is implicit and strongly typed:
    int^ i = 42;    // strongly typed boxed value
    Object^ o = i;    // usual derived-to-base conversions ok

Unboxing is explicit:
Dereferencing a V^ indicates the value inside the box, and this syntax is also used for unboxing:
    int k = *i;    // unboxing to take a copy
    int% i2 = *i;    // refer into the box (no copy)
    swap( *i, k );    // swap contents of box with stack variable
                // (no copy, modifies the contents of box)

Да к стати а как в твоей системе создать int в ГЦ хипе и отправить его в шарп? Ы?
А что делать в этом случае
int* i;
int j[40]={};
if(rand()%2)
{
    i=j;
}
else
{
    i=<какимто образом создаем в ГЦ хипе>int(243);
}
...i+12...

Давать ошибку ибо для объекта в ГЦ хипе это не имеет смысла или молча выполнять адресную арифметику?

Уверен если немного покопатся можно еще много чего раскопать. К томуже в таком виде в котором это есть сейчас сразу видно где ГЦ, а где надо ручками следить.

[понты и наезды поскипаны]

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

Если ты подумал что я тебя не понял то ты заблуждаешься. У нас есть куча объектов на которых стоит ОДИН(иногда больше но это большая редкость) комп с нашим 7х24 софтом.
А то что ты считаешь что я не могу додуматься до тонких клиентов это ИМХО вобще на гране оскорбления.

IT>Расширяемый компилятор, AOP во всей красе, может ещё чего.

Поставлю вопрос по другому что там будет такого чего не будет в C++/CLI?

IT>Ровно столько на сколько у него хватит энтузизизма

Промышленного качаства компилятор это штука ооочень не простая... энтузизизма ооочень много надо.

IT>Бета — это не релиз. Ни один вменяемый мэнеджер не станет делать проект на бете.

Проект нет. А вот прототип в фоновом режиме для освоения новой технологии очень даже можно начать и к релизу получить кучу опыта из серии что хорошо, а что геморой. И изходя из этого проектировать.(В принципе проектировать можно начать еще до релиза)
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: CLI/C++
От: IT Россия linq2db.com
Дата: 03.01.04 07:36
Оценка: 109 (9)
Здравствуйте, WolfHound, Вы писали:

WH> Хоть бы 3 минуты подумал почему это сделано. См ниже.


При чём тут сделано? Что сделано, то сделано. Ты бы хоть на секунду задумался почему это ИМЕННО ТАК сделано, и хотя бы на две, как можно сделать иначе.

WH>Есть нативный класс SomeNativeClass создаем объект этого класса при помощи gcnew SomeNativeClass если следовать твоей логике то указатель на SomeNativeClass ВСЕГДА должен быть нативным и тот прокси который создавал gcnew должен быть проигнорирован те сразуже после создания объекта не остается ни одной живой ГЦ ссылки те даже если на объект будут продолжать ссылатся ГЦ об этом не узнает ни когда и убет обект при первой же сборке мусора не смотря на то что бъект все еще нужен.


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

WH>Для ГЦ классов созлданных с помощью new таже фигня указатель на нативный прокси будет утерян без возвратно сразуже после создвния объекта и ГЦ всегда будет видеть покрайней мере одну живую ссылку (ту что в потеряной проксе).


Ты не понял главного. Не надо new и gcnew. Надо только один new и всё.

WH>Уверен если немного покопатся можно еще много чего раскопать. К томуже в таком виде в котором это есть сейчас сразу видно где ГЦ, а где надо ручками следить.


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

WH>[понты и наезды поскипаны]


О! Воспитание не прошло даром

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

WH>Если ты подумал что я тебя не понял то ты заблуждаешься. У нас есть куча объектов на которых стоит ОДИН(иногда больше но это большая редкость) комп с нашим 7х24 софтом.

Всего один? Слабак!

WH>А то что ты считаешь что я не могу додуматься до тонких клиентов это ИМХО вобще на гране оскорбления.


Надо будет запомнить, потом использую против тебя же.

IT>>Расширяемый компилятор, AOP во всей красе, может ещё чего.

WH>Поставлю вопрос по другому что там будет такого чего не будет в C++/CLI?

Я тебе попробую ответить по-другому и немножко не на твой вопрос.

AOP проповедует (если я его правильно понимаю) вынесение всего служебного кода из собственно кода. И использование для такого кода исключительно декларативных средств языка. Под служебным кодом может пониматься всё, что так или иначе выполняется исключительно для обеспечения поддержки функциональности, но не сама функциональность. Т.е. в идеале код должен содержать чистый сироп из бизнес-логики. Все остальные вспомогательные составляющие кода должны быть отжаты и вынесены в декларативную часть.

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

.NET привнёс ещё один элемент — атрибуты. К сожелению это мощнейшее средство находится пока в самом зародыше. А идея могла бы быть революционной, сдеалай MS ещё один маленький шажочек. А именно — дайте воможность расширять компилятор своими средствами и дополнять генерацию кода после его компиляции.

Например, наследование реализации:

class MyClass : IActivatable
{
    // ...
}


Не надо даже объявлять соответсвующие методы, компилятор всё что надо достроит сам. Конечно, тоже самое можно сделать и в C++ при помощи шаблонов и наследования. Но как насчёт разнородных классов? Правильно, множественное наследование! Ты хорошо знаешь этому цену? А так?

class MyClass : IActivatable, ISavable
{
    // ...
}


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

Ну а с этим уж совсем тоска:

class MyClass : IActivatable, ISavable, IEditable
{
    int    ID          { get; }
    string Description { get; set; }
}


Здесь я не просто хочу от компилятора добавления соответсвующих методов интерфейса, но так же реализации свойств. Да не просто так, а что бы свойства только возвращали int и string, а внутренне были представлены классами EditableInt32 и EditabelString.

А теперь я хочу, чтобы метод save открывал транзакцию и закрывал её, если не произошло никаких исключений:

[Transaction(Required)]
void Save()
{
    // ...
}


И сохранял лог, если произошло исключение неизвестного типа:

[LogException]
[Transaction(Required)]
void Save()
{
    // ...
}


Ну и проверку входных параметров делал:

[LogException]
[Transaction(Required)]
void Save([NotNull] object p)
{
    // ...
}


И эту проверку тоже не сохранял в логе:

[LogException]
[ExcludeFromLog(typeof(NullParameterException))]
[Transaction(Required)]
void Save([NotNull] object p)
{
    // ...
}


А вообще для написания Data Access Layer мне практически достаточно состыковать сигнатуры метода класса и сохранённой процедуры. Так в чём проблема:

[DataAccess]
class MyCustomerDataAccess
{
    void InsertCustomer (int ID, string Name);
    void UpdateCustomer (int ID, string Name);
    void GetCustomerByID(int ID);
}


Готово. Ах да, забыл, Name может быть null, но только при изменении:

[DataAccess]
class MyCustomerDataAccess
{
    void InsertCustomer (int ID, string Name);
    void UpdateCustomer (int ID, [Nullable] string Name);
    void GetCustomerByID(int ID);
}


Может и бизнес слой также упростить. Например, даже при наличии имплементации соответсвующих методов добавить в них что-то своё. Ну например вызов метода валидации обрабатываемого класса:

[BusinessLayer]
class MyCustomerManager
{
    [Validate]
    void InsertCustomer(Customer c)
    {
        // ...
    }
        
    [Validate]
    void UpdateCustomer(Customer c)
    {
        // ...
    }

    void GetCustomerByID(int ID)
    {
        // ...
    }
}


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

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

IT>>Ровно столько на сколько у него хватит энтузизизма

WH>Промышленного качаства компилятор это штука ооочень не простая... энтузизизма ооочень много надо.

Видишь ли в чём дело. Первый персональный компьютер был сделан умельцами в гараже. VB писался на коленках двумя студентами в самолёте. Кто знает, кем и где будет написан язык программирования намбер ван начинающегося столетия
Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: CLI/C++
От: alexkro  
Дата: 03.01.04 23:26
Оценка: 9 (2) :))
Здравствуйте, IT, Вы писали:

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


WH>> Хоть бы 3 минуты подумал почему это сделано. См ниже.


IT>При чём тут сделано? Что сделано, то сделано. Ты бы хоть на секунду задумался почему это ИМЕННО ТАК сделано, и хотя бы на две, как можно сделать иначе.


Где-ж ты был то? Еще не поздно вносить свои предложения в ECMA. А если серьезно, ты подумал, как можно сделать иначе — подумай еще, и еще, и код попиши, и опять подумай. За тот год, что managed extensions существуют, уже много чего передумано, перепробованно, накоплен большой опыт, который одному тебе не воспроизвести, как не старайся. Много предложений было, и ты бы о них знал, если хоть немного интересовался предметом. В том числе и то, что ты говоришь уже было сказанно, дезайнеры языка уже рассмотрели эту точку зрения и признали ее неприемлимой.

Удивительно, что ты не видишь недостатков managed extensions. В большинстве случаев твое мнение: давайте оставим все как есть. Это и неприятие handles и gcnew. Действительно, нужно пописать хотя бы какое-то количество кода и на managed extensions и на C++/CLI, чтобы увидеть разницу. Если ты перековал свой mindset на C# и код на C++ давно не пишешь, пользы C++ community от тебя никакой.

И последнее C++/CLI делается, чтобы люди под .NET на C++ писали. From scratch, full time. А не просто, чтобы legacy код переносить; это уже пройденный этап. Поэтому и требования к языку другие.

PS: Я не буду тебе рассказывать, как на удивление удачно C++/CLI bindings вписываются в общую C++ картину. Как C++/CLI уже сейчас позитивно влияет на ISO C++ Standard. А мог бы, но ты пребпочитаешь этого не видеть и не слышать.
Re[13]: CLI/C++
От: IT Россия linq2db.com
Дата: 04.01.04 01:25
Оценка: -1
Здравствуйте, alexkro, Вы писали:

Удалено избыточное цитирование


A>Удивительно, что ты не видишь недостатков managed extensions. В большинстве случаев твое мнение: давайте оставим все как есть. Это и неприятие handles и gcnew. Действительно, нужно пописать хотя бы какое-то количество кода и на managed extensions и на C++/CLI, чтобы увидеть разницу. Если ты перековал свой mindset на C# и код на C++ давно не пишешь, пользы C++ community от тебя никакой.


Не понял, что за гон! Ты меня ни с кем случайно не спутал? Может покажешь где это я уговоривал всех ничего не менять и писать на MC++?
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: CLI/C++
От: alexkro  
Дата: 04.01.04 01:49
Оценка:
Здравствуйте, IT, Вы писали:

Удалено избыточное цитирование



IT>Не понял, что за гон! Ты меня ни с кем случайно не спутал? Может покажешь где это я уговоривал всех ничего не менять и писать на MC++?


Re[15]: CLI/C++
От: IT Россия linq2db.com
Дата: 04.01.04 05:10
Оценка: 29 (3) +3 :)
Здравствуйте, alexkro, Вы писали:

IT>>Не понял, что за гон! Ты меня ни с кем случайно не спутал? Может покажешь где это я уговоривал всех ничего не менять и писать на MC++?


A>


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

A>Где-ж ты был то?


Код писал, .NET изучал, сайт делал. Где мне ещё быть-то.

A>Еще не поздно вносить свои предложения в ECMA.


Может ты мне референс дашь?

A>А если серьезно, ты подумал, как можно сделать иначе — подумай еще, и еще, и код попиши, и опять подумай. За тот год, что managed extensions существуют, уже много чего передумано, перепробованно, накоплен большой опыт, который одному тебе не воспроизвести, как не старайся.


Детский сад, ей богу. Кем перепробовно, тобой, ты что ли копилка большого опыта? Windows Registry тоже большая копилка опыта, только почему-то его изобретатель сейчас за чашкой кофе признаётся друзьям, что это было большой ошибкой. Да и последние разработки MS это подтверждают, в .NET Registry не используется. Тоже будет и с этим опытом. Я знаю как принимаются решения деятелями от MS не по наслышке. Сам сейчас занят разгребанием дерьма, наваленного умниками из соседнего кубика с бэджиками MS. Так что не надо про большой опыт. Если эти гуси вам тоже рапортуют, то хреновый это опыт, копеешный. Пойдите в производство, туда где действительно люди куют софт, а не там где ваши драные архитекторы протирают штаны на митингах, и посмотрите что людям надо и что говорит их опыт.

A>Много предложений было, и ты бы о них знал, если хоть немного интересовался предметом.


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

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


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

A>Удивительно, что ты не видишь недостатков managed extensions.


Что значит не вижу? Из-за этих недостатков я перешёл на C# и перевёл на него всю разработку в департменте.

A>В большинстве случаев твое мнение: давайте оставим все как есть.


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

A>Это и неприятие handles и gcnew.


Опять же, что значит неприятие? Я должен пасть на колени и целовать тапочки архитекторам это придумавшим? Handles & gcnew — это вторая модель памяти в языке. С точки зрения перспектив языка — это самоубийство. Ты пробвал когда нибудь объяснить студенту первого курса что такое адресная арифметика? Пробовал? А десяти студентам пробовал? А сотне? А вот теперь задумайся над тем, что большая часть современных инженеров с трудом представляют что это такое и им это реально нафиг не надо в повседневной работе. Они фактически кодируют бизнес правила, либо рисуют интерфейс. Указатели, ссылки, GC им даром не дались. И ещё больше это не надо их менеджерам, которым нужен рабочий код, их даже не волнует найс он или не найс, если он работает, то этого достаточно. И также им не важно кто это написал, крутой русский программер на C++ за 100k/y или два индуса на VB за $35k/y каждый. Их даже больше устроит второй вариант, т.к. он дешевле и быстрее.

Современная индустрия разработки ПО уже давно перестала быть чем-то сверхестественным. Код пишут малограмотные (по десяти-двадцатилетним меркам) инженеры и успех давно уже зависит не от них, а от правильного и грамотного менеджмента, который выберет более дешёвые, более простые и в результате более эффективные средства. C++/CLI в нынешнем виде в этом ряду не стоит. И боюсь, что обычное рекламное давление MS здесь тоже слобо поможет.

A> Действительно, нужно пописать хотя бы какое-то количество кода и на managed extensions и на C++/CLI, чтобы увидеть разницу.


Вот только не надо пальцев, пожалуйста, устал я уже от них в этом топике.

A>Если ты перековал свой mindset на C# и код на C++ давно не пишешь, пользы C++ community от тебя никакой.


Я его всё ещё кую. Между прочим под надзором архитекторов в том числе и из MS. А что касается моей пользы, так C++ комьюнити, по крайней мере русской, от меня всё равно никуда не деться Если, конечно, MS не придушит C++ своими собственными руками, что у неё пока совсем не плохо получается.

A>И последнее C++/CLI делается, чтобы люди под .NET на C++ писали. From scratch, full time.


Вот в этом я сильно сомневаюсь. То что по сравнению с MC++ шаг сделан огромный спору нет. Шаблоны + дженерики это просто фантастика. Свойства (наконец-то), объявление ref, value и enum типов, всё это не вызывает нареканий. Но handles!!! Ну, боже мой, ну неужели так трудно понять, что сейчас язык конкурирует уже не только со старым необъекто-ориентированным VB, не только с Java, но с новым VB.NET, который ведёт за собой армию VB-девелоперов, и с C#, который, с одной стороны является основным языком тех кто раньше писал на C++, с другой заточен и продвигается как основной язык .NET. При чём у обоих этих языков исользуемая модель памяти практически никак не фигурирует в языковых конструкциях. Ну только unsafe режим в C#, который практически никем не используется и очень грамотно отделён синтаксическими конструкциями и даже опциями компилятора. И ты хочешь сказать что C++ с его указателями, а теперь ещё и хандлерами сможет составить здесь достойную конкуренцию? Особенно from scratch? Не смешите мои тапочки. Я бы как архитектов ни в жизнь не рекомендовал бы моему мэнеджеру C++/CLI как базовый язык разработки. Особенно, если в моём тиме есть китайцы или индусы. Максимум, что я мог бы для тебя сделать, это не запретить его использовать в подходяших местах.

A>А не просто, чтобы legacy код переносить; это уже пройденный этап. Поэтому и требования к языку другие.


Жаль только что не додумали самую малость.

A>PS: Я не буду тебе рассказывать, как на удивление удачно C++/CLI bindings вписываются в общую C++ картину.


Ну почему же? Распиши. Если уж взялся нести просвящение в массы, то не останавливайся. Расскажи нам почему пришлось вводить хандлеры и как всё остальное вписывается в C++. В качестве слушателей перед тобой практически весь продвинутый программистский рунет Если потянешь статью, не проблема, она будет в ближайшем номере RSDN Mag, единственного на сегодняшний день отечественного журнала для девелоперов.

Я не шучу и не прикалываюсь. Вперёд! Если нужна будет помощь, я отложу все дела и буду в твоём полном распоряжении.

A> Как C++/CLI уже сейчас позитивно влияет на ISO C++ Standard. А мог бы, но ты пребпочитаешь этого не видеть и не слышать.


Ну что за манера ведения беседы? Да, я действительно много распинаюсь о недостатках плюсов, кричу об их устарелости и безделии комитета. Но сам подумай, стал бы я это делать если бы мне была безразлична судьба языка, на котором я пишу ещё с Zortech C++ и с первой версии Turbo C++? Уже наверное лет 12 будет. К сожалению, кроме критики существующих попыток реанимировать мой любимый язык программирования я пока ничего сделать не могу А так хотелось бы В частности, хотелось бы посмотреть в глаза тому, кто придумал хандлеры
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: CLI/C++
От: alexkro  
Дата: 04.01.04 09:20
Оценка: -3
Здравствуйте, IT, Вы писали:

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


A>>


IT>Понятно. Другого я и не ожидал. Тем не менее позволю себе прокоментировать твоё гневное сообщение, дабы дать пищу для размышления другим.


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

На остальное отвечать не вижу смысла.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.