Здравствуйте, Mamut, Вы писали:
M>Скажем так. Например, есть набор классов, написанный твоим напарником на VB.NET, а проект ты пишешь на C#. И вот тебе надо страшно использовать функциональность того класса, а компилировать его в отдельную сборку, да еще ее потом подключать к проекту да еще.... В общем, морока. А в Whidbey — загнал их все в один проект и пользуй, как тебе надо.
M>Но это все — теория Эххх.... Будет круто, если и partial классы тоже можно будет на разных языках писать *зажмурился в предвкушении*. Правда, не уверен, что такое будет
Это я все прекрасно понял. Что касается VB.NET и C# я думаю они справятся, что же касается Delphi, Pithon,Oberon итд.
Пока помоему они даже в студию не интегрируются (могу ошибаться). Хотя это действительно было бы прекрасно.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>GlebZ,
>> Точно так же и MC++. Он никогда не будет С++ и никогда не станет абсолютно родным для Net языком.
ПК>Ну, касательно MC++ вопросов нет, тем более что он уже deprecated. А вот в отношении C++/CLI, который Microsoft ныне очень бурно развивает, вопросы таки есть: ПК> Что означает "быть родным для Net языком", и почему этого не произойдет для C++/CLI?
Что такое указатель в С++/CLI? ПК> Что означает, что C++/CLI никогда не будет C++?
Что такое указатель в С++/CLI?
Как то не очень удобно ИМХО смотреть на признаки ссылочности для объектов. Если для С++ объекты могут быть как в стеке так и в куче, то для Net это невозможно (или может что и упустил ????) и излишние ^ немного напрягают.
Кстати в том же Delphi для указателей на структуры совсем необязательно разименовывать указатели
P^.ttt будет выглядеть как P.ttt
Просто интересно, чем такая запись для объектов предпочтительна ?????
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Это часто встречающееся заблуждение. .Net позиционируется как принципиально многоязычная платформа. Собственно, пожалуй, в реализации этого ее главное достижение. Не стоит забывать, что возможности .Net шире, чем подмножество, доступное из C#.
Знаешь, для JVM тоже писалось очень много языков. Например. Только где они сейчас. Никому не нужны. То же самое будет и с Net. Останутся например VB и С#, а остальное все отомрет. Кому они нужны, если оформятся определенные стандарты написания программ под платформу. Несколько субъективное мнение, но C++/CLI, MC++, как его не зови тоже должен уйти со сцены. Как никому не нужный инструмент. Уже сейчас не много найдешь объявлений — требуется программист на С++ для Net.
С уважением, Gleb.
PS: Мне достаточно жаль людей которые повелись на байку что C++ код можно легко портировать под Net. Если бы у меня стояла такая задача, я бы портировал под C#. Трудоемкость не сильно бы возрасла, но код бы смотрелся и управлялся значительно лучше.
Здравствуйте, Mamut, Вы писали:
M>Ага. То есть, в проекте C++ могут мирно сосуществовать файлы на, скажем, C++, C# и VB.NET.
Непонятно как это физически будет реализовано. Будет какой то аналог ILMerge? Или просто будет возможность создавать многофайловые сборки?
M> При этом во время дебага можно точки останова ставить в любом файле и отладчик будет там покорно останавливаться. В репортаже это выглядело неимоверно круто, но мужик сказал, что такое будет доступно только из C++ проектов
Это можно и сейчас в любом проекте. Ты видимо что то путаешь.
Serginio1,
> Как то не очень удобно ИМХО смотреть на признаки ссылочности для объектов. Если для С++ объекты могут быть как в стеке так и в куче, то для Net это невозможно (или может что и упустил ????)
void foo(int count)
{
using (HungryForResources resource_waster = new HungryForResources (count))
{
resource_waster.eatAsMuchAsYouNeed();
}
}
Также это работает для базовых классов и данных-членов, автоматизации вызова Dispose() для которых, пожалуй, в C# нет.
> и излишние ^ немного напрягают.
Тут есть еще разные соображения. Например: как сохранить "забоксенное" типизированное значение value-типа в C#? Что-то мне, глядя на неявные ссылки, кажется, что никак. В C++/CLI так:
int i = 10;
int^ i_boxed = i;// Далее можно использовать "забоксенное" значение i без повторного боксинга.
. . .
// Можно даже получить прямую ссылку на целое, лежащее в боксе:int% i_ref = %i_boxed;
В общем, значки *, &, ^, % и т.п. нужны для того, чтобы можно было точнее отразить происходящее, и чтобы можно было точно выражать, о каком именно типе идет речь. В этом случае компилятор сможет защитить программиста от множества ошибок и непреднамеренных преобразований (например, boxing обозначен намного более явно, чем в C#, т.к. int и int^ — различные типы).
Стоит еще вспомнить, что T^, T% и т.п. могут быть аргументами шаблонов. В перспективе предполагается ввести возможность создания смешанных классов: ref class, унаследованный от обычного, и наоборот, члены ref class'ов в обычных классах, и наоборот, и т.п. В общем, если рассмотреть все возможные варианты комбинации "managed" классов с "обычными" типами и различными чертами языка, то должно становиться ясно, что "угадайка" со стороны компилятора, что же именно имел в виду программист в данном случае, работать не будет.
> Кстати в том же Delphi для указателей на структуры совсем необязательно разименовывать указатели > P^.ttt будет выглядеть как P.ttt > Просто интересно, чем такая запись для объектов предпочтительна ?????
Использование -> вместо . для доступа к членам через handles (^) — решение достаточно произвольное. Вариант с точкой рассматривался, но, насколько я понял, авторы C++/CLI решили, что: (1) использование -> для объектов, созданных через gcnew по аналогии с new более последовательно; (2) различие в использовании с доступом через ссылки (%) тоже имеет смысл.
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
GlebZ,
> Несколько субъективное мнение, но C++/CLI, MC++, как его не зови тоже должен уйти со сцены. Как никому не нужный инструмент.
Твои заявления о никому не нужных инструментах находятся в некотором диссонансе с высказываниями представителей Microsoft. Я позволю себе процитировать некоторые из них:
At the PDC, I was asked whether C# thinks they’re in the middle. The answer is absolutely! A few years ago, the usability team at Microsoft developed personas for programmers in each of the languages. The Visual Basic developer was the “opportunistic programmer”, the C# developer was the “pragmatic programmer”, and the C++ developer was kind of guy who knew the whole system.
Yes, managed code is the direction we are going in moving forward for all the places where it makes sense. However extrapolating that to mean C# is simply not true. We are spending a lot of resources to make sure C++ is a primary development language on the .Net platform and are seeing a lot of internal adoption of C++ to write managed code inside of Microsoft. In the RTM version the primary focus of MC++ is to enable you take integrate easily with existing code, but in future releases you will see us focusing much more on making C++ take up the traditional role it serves role as the high end language for system level programming and for expert level programming on the .Net platform.
In VS 2005, C++ is the systems programming language for .NET. If you already know C++, there is no need to use another language, although you're free to use whatever language you like for all or any part of your application. C++ is not the simplest .NET language, just the most powerful one that exposes the most .NET CLR features and that usually generates the best optimized IL.
C++ gives the programmer unprecedented flexibility to write high-performance managed code, and it does it all in a way that is natural to C++ programmers. There are many languages available for .NET-enabled programming; if you care about maximum performance, Visual C++ is the obvious choice.
И т.д., и т.п.
Похоже, ты ведешь речь о чем-то другом... C++/CLI это вовсе не новое название для MC++, это совсем другой, новый, язык, на разработку которого Microsoft в течение последних двух лет потратила достаточно много ресурсов, чтобы вот так просто спихивать его "со сцены". К тому же, как это ни забавно, заметная часть исследований, направленных на улучшение "внутренней механики" .Net исходит как раз от разработчиков VC++ (Phoenix, уточнение Dispose Pattern и т.п.) Так что кто как, а в Microsoft очень даже полагаются на использование C++ для разработок под .Net.
> Уже сейчас не много найдешь объявлений — требуется программист на С++ для Net.
Очень интересно, откуда же взяться объявлениям, если язык еще не выпущен? C++/CLI будет доступен только с выходом Visual Studio 2005 (aka Whidbey).
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
AndrewVK,
> M> Ага. То есть, в проекте C++ могут мирно сосуществовать файлы на, скажем, C++, C# и VB.NET.
> Непонятно как это физически будет реализовано. Будет какой то аналог ILMerge? Или просто будет возможность создавать многофайловые сборки?
В демке говорят, что это "фича" компоновщика C++. Автоматом работает в проектах C++. Остальным доступно через command line, если они готовы к некоторым неудобствам. Сделали для того, чтобы в новых проектах было легко использовать уже существующий код, написанный на других языках.
В общем-то не удивительно, что значительная часть людей от MC++ в программировании под .Net отвернулась, перейдя на C#, а теперь в MS ожидают обратного притока тех, кто может захотеть использовать C++/CLI.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В общем-то не удивительно, что значительная часть людей от MC++ в программировании под .Net отвернулась, перейдя на C#, а теперь в MS ожидают обратного притока тех, кто может захотеть использовать C++/CLI.
Не все так просто. Ситуация намного хитрее. Команда C# по прежнему уверена что это основной язык для .NET. Команда C++/CLI разумеется считает что основной язык будет C++. Вопрос только в том какая из них победит.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>GlebZ,
ПК>Твои заявления о никому не нужных инструментах находятся в некотором диссонансе с высказываниями представителей Microsoft. Я позволю себе процитировать некоторые из них:
[skipped]
Я давно уже работаю на платформе Microsoft, за 12 лет уже успел наслушаться. Как только запахнет маркетингом, надо фильтровать базар. Поэтому на этой основе всегда стараюсь всегда сначала выработать свое мнение(которое не всегда совпадает с мнением Microsoft).
ПК>Похоже, ты ведешь речь о чем-то другом... C++/CLI это вовсе не новое название для MC++, это совсем другой, новый, язык, на разработку которого Microsoft в течение последних двух лет потратила достаточно много ресурсов, чтобы вот так просто спихивать его "со сцены". К тому же, как это ни забавно, заметная часть исследований, направленных на улучшение "внутренней механики" .Net исходит как раз от разработчиков VC++ (Phoenix, уточнение Dispose Pattern и т.п.) Так что кто как, а в Microsoft очень даже полагаются на использование C++ для разработок под .Net.
MC++ должен умереть не оставив следов. Этот ублюдок нежизнеспопобен. Что касается С++/CLI — то это еще один язык с C++ похожим синтаксисом но при этом не являющийся С++. Единственный его плюс — это явное управление боксингом. Что очень неудобно в С#. У всех языков на платформе Net есть ограничение — одноплатформенность. Он должен легко портироваться в MSIL и выполнять его правила и ограничения. Поэтому ты никогда не сможешь получить не value объект в стеке, или также легко реализовать множественное наследование. При этом еще динамическое связывание между сборками — еще одно ограничение. В то же время нельзя запрещать аттрибуты. Простого портирования ни из С++ в С++/CLI, ни в обратную сторону ждать не приходится . Итого получается что C++/CLI еще один язык с C++-подобным синтаксисом. Как и С# и Java.
>> Уже сейчас не много найдешь объявлений — требуется программист на С++ для Net.
ПК>Очень интересно, откуда же взяться объявлениям, если язык еще не выпущен? C++/CLI будет доступен только с выходом Visual Studio 2005 (aka Whidbey).
Да будет та же самая проблема что и с MC++. С++ и С++/CLI — разные языки. Его также приходится изучать как и С#. API Windows, MFC не имеют ничего похожего с Net Framework. А именно работа с разными API и занимает наиболее большое кол-во времени разработки. Эффективность выполнения не может быть выше чем это эффективность компиляции MSIL. В результате — С# с его более простым синтаксисом значительно более подходит для разработки для Net и портирование с С++ на С# практически равнозначно по затратам как и портирование из C++ на С++/CLI. С точки зрения построения бизнес-приложений, вместо С++/CLI использовать С# эффективнее. Говорить о системном применении в среде Net говорить особо не приходится. Наличие управления боксингом — недостаточный плюс (хотя весьма весомый). Возможность использования unmanaged кода — вот достаточно весомый аргумент для построения системных вещей. Но за это слишком большая плата — потеря многоплатформенности.
С уважением, Gleb.
PS: все это было мое имхо.
PSS:ожидать от Phoenix то чего в природе не может быть-не приходится(тоже мое имхо)
Здравствуйте, Павел Кузнецов, Вы писали:
>> Команда C# по прежнему уверена что это основной язык для .NET.
ПК>Похоже, это не совсем так.
Там только про C++ team. А вот это:
Well, for one C++ developers are really multilingual developers. They use the programming language best suited for a task. A C++ programmer also tends to understand the whole system, and doesn’t mind reading MSIL or assembly code. C++ developers also think in much broader contexts – they think about the architecture of the whole program, rather than just single pieces. C++ developers also tend to appreciate lower level components that can be combined to create simpler components. (It’s really very difficult to create components with more utility from higher level components that have less utility). C++ programmers tend to think about performance more often, and understand the dependencies in their programs. C++ programmers try to maximize tools available to get things done more efficiently (be it, sed, awk, profilers, lint tools, perl scripts, etc.) C++ programmers will also build tools to get the job done when a tool is not available.
Ну очень уж пахнет фанатизмом, что, собственно, только подтверждает то что я сказал ранее — каждый кулик хвалит свое болото.
AndrewVK,
>>> Команда C# по прежнему уверена что это основной язык для .NET.
> ПК>Похоже, это не совсем так. > Там только про C++ team.
At the PDC, I was asked whether C# thinks they’re in the middle. The answer is absolutely! A few years ago, the usability team at Microsoft developed personas for programmers in each of the languages. The Visual Basic developer was the “opportunistic programmer”, the C# developer was the “pragmatic programmer”, and the C++ developer was kind of guy who knew the whole system.
Но если ты полагаешь, что команда VC++ тебя дезинформирует, можно зайти на сайт Visual C# (хотя команде C# тоже нельзя верить: многие из них вышли из команды VC++ ).
Visual C# .NET 2003 is the comprehensive tool set for creating XML Web services and Microsoft .NET-connected applications for Windows and the Web using the component-oriented C# development language. View product information, including case studies, news and reviews, and system requirements. Plus, get information on how to obtain this robust development package offering beginning and intermediate developers with C++ or Java experience a modern language and environment for creating next-generation software.
> А вот это: <...> Ну очень уж пахнет фанатизмом
Это компенсация marketing BS, исходящего от пропагандистов C# Шучу.
Конечно, Брэндон несколько пристрастен; с другой стороны, во многом он прав. Даже по поводу использования многих языков. Например, недавно Миша Бергал заметил, что ему в повседневной работе нужно использовать как минимум 6-7 языков: C++, Python, JavaScript, SQL, AppleScript, C#, XSLT. Недавно был еще Perl, но от него удалось избавиться в пользу Python. Я без XSLT в работе пока обхожусь совсем, но у меня еще добавляется ассемблер, с которым, благо, встречаешься редко, и больше в аспекте чтения, чем написания. С C# и AppleScript тоже вижусь достаточно редко. Некоторые ребята еще используют Лисп, чтобы писать расширения к Emacs.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
ПК>Конечно, Брэндон несколько пристрастен; с другой стороны, во многом он прав.
Ага, особенно вот это мне понравилось:
[q]C++ developers also think in much broader contexts – they think about the architecture of the whole program, rather than just single pieces.
Ты уж извини, но после подобных заявлений я отказываюсь воспринимать его слова в качестве слов эксперта. Явный фанатизм.
ПК> Даже по поводу использования многих языков. Например, недавно Миша Бергал заметил, что ему в повседневной работе нужно использовать как минимум 6-7 языков: C++, Python, JavaScript, SQL, AppleScript, C#, XSLT.
Мне тоже не сильно меньше (вот к примеру последний месяц — C#, Java, XSLT, Ant, SQL, XSD, NSIS Script, причем два последних я до этого не использовал всерьез). Начинаем мерять чья пиписка длиннее? Или может все таки заявления о том что используемый язык определяет кругозор идут в лес вместе с заявителями?
ПК>Я без XSLT в работе пока обхожусь совсем,
Зря. На редкость пригождающаяся в самых неожиданных местах технология.
ПК> но у меня еще добавляется ассемблер, с которым, благо, встречаешься редко, и больше в аспекте чтения, чем написания. С C# и AppleScript тоже вижусь достаточно редко. Некоторые ребята еще используют Лисп, чтобы писать расширения к Emacs.
Ну и, вывод то какой? Только С++ программисты настоящие программисты?
Здравствуйте, AndrewVK, Вы писали:
AVK>Не все так просто. Ситуация намного хитрее. Команда C# по прежнему уверена что это основной язык для .NET. Команда C++/CLI разумеется считает что основной язык будет C++. Вопрос только в том какая из них победит.
Ага. В МСДН Маг уже есть пробные заливы C++/CLI под названием "С++ Рулез" (я ну шучу). И рядом такие глубокие статьи по кишкам дотнета с кодом... разумется на Шарпе.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Похоже, это не совсем так. Впрочем, все зависит от трактовки понятия "основной".
Не, ну, ты уже совсем в каком-то виртуальном мире живешь. Ты погляди на то начем все библиотеки к дотнету написаны. Даже в Авалоне (хотя его явно делала команда близкая к системе) основной код на Шарпе. На МС++ (скорее всего как раз CLI) сборки есть, но они все сплошь интеропные. То есть если нужно трахаться с С-ишным АПИ, то народ берет С++, если нет, то забивает на него.
И это не хошо, ни плохо. Это есть.
ЗЫ
Кстати, насколько мне известно С++ Team в МС брошена на разработку оптимизатора для 64-битного дотнета. Забавно будет поглядеть на плоды. Пока что говорят тормозит он не по детски.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
ПК>>Похоже, это не совсем так. AVK>Там только про C++ team. А вот это: AVK>
AVK>Well, for one C++ developers are really multilingual developers. They use the programming language best suited for a task. A C++ programmer also tends to understand the whole system, and doesn’t mind reading MSIL or assembly code. C++ developers also think in much broader contexts – they think about the architecture of the whole program, rather than just single pieces. C++ developers also tend to appreciate lower level components that can be combined to create simpler components. (It’s really very difficult to create components with more utility from higher level components that have less utility). C++ programmers tend to think about performance more often, and understand the dependencies in their programs. C++ programmers try to maximize tools available to get things done more efficiently (be it, sed, awk, profilers, lint tools, perl scripts, etc.) C++ programmers will also build tools to get the job done when a tool is not available.
AVK>Ну очень уж пахнет фанатизмом, что, собственно, только подтверждает то что я сказал ранее — каждый кулик хвалит свое болото.
Ага. По этому определению программисты делятся на ламеров и С++-программистов. Эдак любой приличный программист явяется С++-программистом. Даже если С++ в глаза не видел.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Конечно, Брэндон несколько пристрастен; с другой стороны, во многом он прав. Даже по поводу использования многих языков. Например, недавно Миша Бергал заметил, что ему в повседневной работе нужно использовать как минимум 6-7 языков: C++, Python, JavaScript, SQL, AppleScript, C#, XSLT. Недавно был еще Perl, но от него удалось избавиться в пользу Python. Я без XSLT в работе пока обхожусь совсем, но у меня еще добавляется ассемблер, с которым, благо, встречаешься редко, и больше в аспекте чтения, чем написания. С C# и AppleScript тоже вижусь достаточно редко. Некоторые ребята еще используют Лисп, чтобы писать расширения к Emacs.
Ну, то есть ты согласен с выоводм этого друга что ты не являешся настоящим С++-программистом так как используешь не 7 языков:
И вообще, если человек испоьзует 7 языков, то среди них обязан быть С++?
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
M>>Согласно одному из видеорепортажей на Channel9, проекты С++ будут единственными, поддерживающими исходные файлы на разных .НЕТ-совместимых языках. GZ>А смысл?
Смысл очень простой. С++-ников послели бы на хрен если бы всем пришлось писать все на С++. А так проектв вроде С++-ный, а народ сможет писать его на то на чем будет удобно.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Эххх.... Будет круто, если и partial классы тоже можно будет на разных языках писать *зажмурился в предвкушении*. Правда, не уверен, что такое будет
