Что Выбрать C# или С++/CLR ?

← →
big_djo © (2014-03-05 08:09) [0]

Последнее время очень интенсивно изучал C++, щас собираюсь освоить .NET, возник вопрос, что изучать сначала C# или С++/CLR ? Есть ли существенная разница?

← →
antonn © (2014-03-05 09:14) [1]

а для чего?

← →
clickmaker © (2014-03-05 09:52) [2]

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

← →
Inovet © (2014-03-05 10:07) [3]

> [2] clickmaker © (05.03.14 09:52)

Си Шарп для Net православнее же чем извращённый Си++?

← →
clickmaker © (2014-03-05 10:10) [4]

> [3] Inovet © (05.03.14 10:07)

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

← →
clickmaker © (2014-03-05 10:16) [5]

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

← →
Dimka Maslov © (2014-03-05 11:02) [6]

писать на managed C++ практически невозможно. Поэтому для .net надо всё-таки заниматься С#. Но главное - не надо потом писать про это книгу!

← →
Novicer (2014-03-05 11:08) [7]

Интересно чего нельзя написать на Дельфи что можно на Сях? :)

← →
clickmaker © (2014-03-05 11:10) [8]

> чего нельзя написать на Дельфи что можно на Сях

Объективно нет такого

← →
Inovet © (2014-03-05 11:28) [9]

> [5] clickmaker © (05.03.14 10:16)

Ну я под извращённым имел ввиду Управляемый Си++. Сам-то не пробовал, так и не знаю, так только по описаниям.

← →
clickmaker © (2014-03-05 11:31) [10]

> [9] Inovet © (05.03.14 11:28)

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

← →
Dimka Maslov © (2014-03-05 12:00) [11]

> Сам-то не пробовал,

Я пробовал. Хуже может быть только java.

← →
DVM © (2014-03-05 18:05) [12]

> щас собираюсь освоить .NET, возник вопрос, что изучать сначала
> C# или С++/CLR ?

C#, а c++ сам по себе, не managed который.

← →
ТНЕ картман (2014-03-05 18:50) [13]

> Я пробовал. Хуже может быть только java.

хм, по моим впечатлениям, java проще delphi в разы.

← →
Юрий Зотов © (2014-03-05 19:13) [14]

> ТНЕ картман (05.03.14 18:50) [13]

> по моим впечатлениям, java проще delphi в разы.

Думаю, по сложности они примерно одинаковы (только в Delphi возможностей побольше). А вот то, что в Джаве писанины больше и сырец замусорен кучей скобок - это факт.

← →
Компромисс1 © (2014-03-05 19:28) [15]

А вот то, что в Джаве писанины больше и сырец замусорен кучей скобок - это факт.

Ну да,

if(condition){
doSomething();
doSomethingElse();
}

намного мусорнее, чем

if condition then
begin
doSomething;
doSomethingElse;
end;

← →
big_djo © (2014-03-05 21:56) [16]

Поисследовал некоторые базовые вещи в C++/CLR и C# :) Решил написать тут это, чтобы немножко систематизировать то , как я это понял) Думаю сделать лабораторную работу для студентов) Вы поправьте если , что) я новичек в .NET.

Оказалось есть так называемые отслеживаемые дескрипторы (tracking handle) некоторые аналоги указателей в «родном» с++.

Есть тип класса значения, такие данные помещаются в стек, а есть ссылочные классы , такие данные помещаются в динамическую память CLR.

Например тип int ассоциирован с типом Int32 среды CLR. Это класс типа значения. А любой массив или String это ссылочный тип класса. Любой ссылочный тип класса описывается отслеживаемым дескриптором. Адрес в дескрипторе меняется с течением времени так как сборщик мусора может переносить объекты при фрагментации памяти.

Пример создания данных в динамической памяти с использованием дескриптора:

int^ p(2); // выделяем область в динам. памяти и инициализируемем её значением 2 на которое указывает p

Console::WriteLine(*p);// выводим разыменованное значение дескриптора на экран

Что интересно, оказалось можно не разыменовывать!, видимо CLR и так догадается

Console::WriteLine(p);// то же , что и Console::WriteLine(*p)

А если не инициализировать

int^ p=nullptr;

*p=3; // то не скомпилится, выделенной области нет

и надо явно динамически выделить

int^ p=nullptr;
p=gcnew int (3);

То же относится и к массивам и всем ссылочным классам.

То есть вывод: чтобы создать данные с использованием дескриптора, требуется: Либо сразу инициализируем отслеживаемый дескриптор значением (-ями), либо инициализируем позже, но с обязательным вызовом gcnew.

Для массивов CLR это выглядит так:

array <int>^ a ={1,2,3,4,5};

или

array <int>^ a = gcnew array<int> (5){1,2,3,4,5};

или без инициализации

array <int>^ a = gcnew array<int> (5); // автоматически все элементы нули

аналогично для строковых массивов:

array <String^>^ b = gcnew array<String^> (3){"Россия","Украина","Белоруссия" };

или без инициализации

array <String^>^ b = gcnew array<String^> (3);//пустые строки

Что интересно в C# массив больше похож на родной Сиплюсплюсовый :))
int [] b= new int[5]{1,2,3,4,5}; чем на С++/Сиэлэрный :)

Еще в С++ есть внутренний указатель, он работает как обычный указатель «родного с++», и поддерживает арифметику адресов к которой все привыкли.

interior_ptr<int> p=nullptr;
p=&(a[0]);
for (int i=0; i<a->Length; i++)
Console::WriteLine( *(p++) );

Пробовал скомпилить это в c# , но там нет interior_ptr это фишка именно C++/ CLR.

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

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

← →
картман © (2014-03-05 23:18) [17]

> я новичек в .NET.

и в русском

> Юрий Зотов © (05.03.14 19:13) [14]
>
> > ТНЕ картман (05.03.14 18:50) [13]
>
> > по моим впечатлениям, java проще delphi в разы.
>
> Думаю, по сложности они примерно одинаковы (только в Delphi
> возможностей побольше). А вот то, что в Джаве писанины больше
> и сырец замусорен кучей скобок - это факт.

так вот в чем секрет популярности джавы!.. и эта - я правда так думаю.

← →
Юрий Зотов © (2014-03-05 23:26) [18]

> Компромисс1 © (05.03.14 19:28) [15]

В таком маленьком фрагменте разница, конечно, невелика. Но когда код насчитывает десятки (если не сотни) тысяч строк, картина становится совсем другой.

В Delphi три и более закрывающих скобки подряд - редкость, а в Java - обычное дело. Даже в Вашем микропримере ненужных, по сути, скобок больше, чем строк. Значит, в большом проекте этих лишних скобок тоже будут десятки (если не сотни) тысяч. Не думаю, что это улучшает читабельность.

В пятницу, если не забуду, сделаю поиск по всему Java-проекту 4-х закрывающих скобок подряд. И такой же поиск по сырцам Delphi. Результат доложу.
:o)

← →
ухты (2014-03-05 23:32) [19]

> Думаю сделать лабораторную работу для студентов) Вы поправьте
> если , что) я новичек в .NET.
все правильно
я сейчас буду вырезать аппендицит, только я пока даже не знаю что это, если что поправьте..

← →
big_djo © (2014-03-05 23:37) [20]

-->и в русском
вроде не форум филологов)

-->Но если изучать с нуля и не хочется илишнего выноса мозга, я бы начал
-->именно с шарпа.

с виду кажется , что C++/CLR более информативен, чем шарп

← →
big_djo © (2014-03-05 23:37) [21]

Удалено модератором

← →
Компромисс1 © (2014-03-05 23:56) [22]

Юрий Зотов © (05.03.14 23:26) [18]

Странно, у меня противоположные ощущения? несмотря на то, что я с Delphi на яву переходил, а не наоборот.
Скобки гораздо лучше (читабельнее, быстрее набираются, меньше шанс ошибиться), чем begin end. Обязательные скобки при вызове метода - тоже плюс, а не минус, потому как сразу ясно, что это вызов метода.

myInt := count + 12; // count - это чтo: переменная или функция?
Может, дело в том, что я с лиспом познакомился раньше, чем с явой, но меня скобки не раздражают. Возможно, потому что я не пишу код типа такого:
MyClass obj = (MyClass) ((Map)getMyObj()).get("key");

← →
Компромисс1 © (2014-03-06 00:00) [23]

Я вот сейчас бегло прошелся по текущему проекту и не смог найти скоплений ({){, так что мне было бы интереснее увидеть не статистику скобок, а пример кода, который Вы считаете плохим или, по крайней мере, менее красивым, чем в Delphi.

← →
big_djo © (2014-03-06 00:14) [24]

Вот кстати http://msdn.microsoft.com/ru-ru/library/ms235212.aspx:

Таким образом, при написании на C#
object o = 1024; // C# implicit boxing
происходит гораздо больше различных процессов, чем может показаться из-за внешней простоты кода. Язык C# скрывает не только сложность выполняемых операций, но и абстрактность самого процесса упаковки. Из-за угрозы введения пользователя в заблуждение относительно эффективности, управляемые расширения для C++, в свою очередь, открыто демонстрировали эту сложность, постоянно запрашивая явные инструкции.

В новом синтаксисе поддержка типов упакованных значений стала гораздо более элегантной и лучше интегрируется в систему типов, сохраняя при этом широкие возможности. Например, ниже приводится перевод указанной ранее небольшой программы:
int main()
{
double result = 3.14159;
double^ br = result;
result = 2.7;
*br = 2.17;
Object^ o = br;
Console::WriteLine( "result :: {0}", result.ToString() );
Console::WriteLine( "result :: {0}", result );
Console::WriteLine( "result :: {0}", br );
}

← →
big_djo © (2014-03-06 00:17) [25]

http://msdn.microsoft.com/ru-ru/library/ms235212.aspx

← →
Юрий Зотов © (2014-03-06 00:49) [26]

> Компромисс1 © (05.03.14 23:56) [22]

Я же про круглые, а не про фигурные скобки говорил. С фигурными в джаве как раз все в порядке, вопросов нет. Правда они менее заметны, чем begin-end (то есть, как раз менее, а не более читабельны), ну да это дело привычки. Только не говорите, что они быстрее набираются, потому что begin-end я набиваю одним аккордом, через клавиатурный макрос. Так что и насчет "меньше шанс ошибиться" - нисколько не меньше.

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

Те же самые скобки при вызове метода можно писать и в Delphi. Если нравится - пишите, не запрещено. Лично мне не нравится, я и не пишу. Поскольку и без них всегда знаю, что такое count, а если даже и забыл, то Ctrl+клик - и через секунду я знаю все. И сделать раз в месяц этот самый Ctrl+клик мне гораздо проще, чем повсюду пустые скобки лепить и код ими засорять.

Насчет поиска ({){ - я не понял, что Вы искали. На первый взгляд, такой конструкции быть не может, так что нет ничего удивительного, что она не нашлась. Поищите лучше ))) или ))))

> пример кода, который Вы считаете плохим или, по крайней мере, менее
> красивым, чем в Delphi.

В пятницу. Если не забуду. А пока, например, вот навскидку:

Java: ((SomeClass) someObject).someMethod(); // 6 скобок
Delphi: TSomeClass(SomeObject).SomeMethod; // 2 скобки

Или, например, преобразование строки в дату и обратно при условии, что нужен формат DD.mm.YYYY. Сколько кода надо написать в Java, чтобы заменить им дельфишную DateToStr? Все эти календари и форматтеры... И потом - с какой стати этот код (по сути, простая утилита) обязан быть именно методом какого-то класса, пусть и статическим? На фига мне здесь нужен класс? И при вызове я везде обязан писать имя этого класса - тоже совершенно ненужное стучание по клавишам.

← →
Компромисс1 © (2014-03-06 01:20) [27]

Я же приводил пример, я так не пишу
Java: ((SomeClass) someObject).someMethod(); // 6 скобок
Я завожу локальную переменную в этом случае.

Никто не мешает написать свой DateToStr в Java.
Я уже не помню DateToStr в Delphi, но вроде бы не поддерживает всего того (Calendar, Locale), что поддерживает Java.
Имя класса при вызове static можно не писать, есть import static.
Принадлежность метода классу позволяет его выгружать при выгрузке класса.

← →
Юрий Зотов © (2014-03-06 09:29) [28]

> Компромисс1 © (06.03.14 01:20) [27]
> Я завожу локальную переменную в этом случае.

SomeClass var = (SomeClass) someObject; var.someMethod();

Стало на 2 скобки меньше. А писанины стало еще больше.

Ладно, мне надо убегать. До пятницы.

← →
картман © (2014-03-06 09:34) [29]

> Юрий Зотов © (06.03.14 00:49) [26]

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

import static ...

← →
big_djo © (2014-03-06 14:09) [30]

как оказалось можно 2 языка учить одновременно и c# и clr, пишу маленькие программки на c++/clr и сразу же переписываю их на шарпе.

← →
jack128_ (2014-03-06 15:06) [31]

> В Delphi три и более закрывающих скобки подряд - редкость,
> а в Java - обычное дело. Даже в Вашем микропримере ненужных,
> по сути, скобок больше, чем строк.

Это каких ? скобок при вызове методов? Это наследие Сей - и там эти скобки нужны.

← →
Romkin © (2014-03-06 18:18) [32]

> Это каких ? скобок при вызове методов? Это наследие Сей
> - и там эти скобки нужны.

То есть ты хочешь сказать, что в java взяли скобки из другого языка, не задумываясь, нужны они или нет?

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

← →
jack128_ (2014-03-06 18:49) [34]

>>То есть ты хочешь сказать, что в java взяли скобки из другого языка, не задумываясь, нужны они или нет?
В в смысле не задумываясь? Задумываясь прежде всего о похожести на с/плюсы.

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

Это называется consistency. Если при наличии параметров у функции обязательны скобки, то и без параметров скобки должны быть. При чтении не надо вникать в контекст и анализировать имя (глагол или существительное). Аналогично мне больше нравится, что условие всегда в скобках (if/while/do-while/switch), структурнее программа, читается на автомате.
На паскале приходится искать then:
if myConditionField AND (myFunctionWhichReturnsInteger <> 12) AND someExtraConditionFieldForThem then

На яве
if(myConditionField && myFunctionWhichReturnsInteger() != 12 && someExtraConditionFieldForThem) {

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

Эт везде так.
http://www.x.org/releases/X11R7.0/patches/xorg-server-1.0.1-geteuid.diff

Да и вообще по сути: http://habrahabr.ru/post/214557/

> возник вопрос, что изучать сначала C# или С++/CLR ?

> CLR (The Common Language Runtime) это не язык, а Runtime

> Да и вообще по сути: http://habrahabr.ru/post/214557/

Странно, в яве было бы предупреждение "недостижимый код". Неужели в C не так?
Я как-то пытался убедить людей всегда использовать фигурные скобки, отвечали: "Зачем? Так быстрее и понятно тоже" :(

> CLR (The Common Language Runtime) это не язык, а Runtime
а название (C++/CLR) это язык C++ для среды CLR

классная статья про c++/cli коротко и по делу http://habrahabr.ru/post/47732/

Кто -нить смешивал .NET-овый код и родной сишный?

← →
jack128_ (2014-03-06 22:53) [42]

> Странно, в яве было бы предупреждение "недостижимый код".
> Неужели в C не так?

в яве бы тот код вообще не скомпилировался.

> Неужели в C не так?

предупреждения никто никогда не читает.

> big_djo © (06.03.14 21:46) [39]
> > CLR (The Common Language Runtime) это не язык, а Runtime
> а название (C++/CLR) это язык C++ для среды CLR

Может все же C++/CLI ?

http://www.ecma-international.org/publications/standards/Ecma-372.htm

-->Может все же C++/CLI ?
CLR это просто реализация этого стандарта от MicroSoft

наверно и так C++/CLI и так C++/CLR можно

а здесь спецификации самой среды http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-335.pdf

Что Выбрать C# или С++/CLR ? Найти похожие ветки