|
|
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
Подскажите чем отличаются эти языки? Что гибче и эффективнее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 12:07 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
McLighterПодскажите чем отличаются эти языки? Что гибче и эффективнее? оба гнутся хорошо... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 18:42 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
C# -- это язык, предназначенный для программирования под .NET, представляет собой очищенный язык С++, приправленный чертами из Java, VB, Delphi. С++ -- древний универсальный язык, реализованный почти на всем на чем можно и подо все что можно. По гибкости превосходит все на свете))))))))))) ________________________________________________________ Глюк - это высокоорганизованная система не поддающихся определению частиц ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 19:06 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
LelikkC# -- это язык, предназначенный для программирования под .NET, представляет собой очищенный язык С++, приправленный чертами из Java, VB, Delphi. С++ -- древний универсальный язык, реализованный почти на всем на чем можно и подо все что можно. По гибкости превосходит все на свете))))))))))) согласен, с++ гнется лучше :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 00:06 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
кроме всего прочего в c# ссылки замаскировали. в c++ по тексту видно, ссылка или переменная, а c# надо запоминать скучный список где, что. не надо деструкторы вызывать. вместо этого надо узнать, диспозайбле ли обьект и вызывать метод диспозайб. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 02:23 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
Немного добавить хочу. Т.к. C# стандартизован только для работы в NET, то у него нет такого понятия как работа с неуправляемой кучей. Все объекты располагаются в управляемой куче. Типы по значению могут распологаться и в стеке. Использование неинициализированных переменных переведено из разряда варинингов в разряд ошибок компиляции( хотя опять же есть nullable types ). Неявные преобразования типов к boolean запрещены. Явные происходят только через операции сравнения. В Шарпе все перекрытия или неперекрытия методов при наследовании происходят ЯВНО. В Шарпе есть partial types, когда определения и реализацию класса можно дополнять, в разных модулях. Дженерики Шарпа реализованы лучше чем в Яве, но полностью уступают С++, и вобчем-то работают как макросы. Дженерикам Шарпа может передаваться ТОЛЬКО название типа БЕЗ всяких модификаторов. Дженерики инстанцируются ПОЛНОСТЬЮ - это как явное полное инстанцирование шаблона. Для типов значений, если они служат аргументом дженерика, происходит подстановка и полное инстанцирование. Для типов по ссылке компилятор лишь подставляет в код преобразование типов от супербазового класса. Преобразования эти можно "ограничить" перечислением в констрейнте дженерика совместимых типов. В Шарпе можно перекрывать меньший объем операторов (в основном арифметические). Причем перекрытие, например, оператора + вызывает неявное перекрытие компилятором оператора +=. Это затрудняет разработку смешанной арифметики. Как было замечено в Шарпе используется для защиты типа только Dispose Pattern. Т.е. понятия жизнь объекта и "жизнь" занимаемой им памяти разделены. Это не ВСЕГДА плохо но и не ВСЕГДА хорошо. ну и конечно Шарп пашет только под NET. Это не назовешь гибкостью. Выпуск MSVC 2005 показал, что с++ может тоже самое в NET и даже большее. Он может использовать как управляемую кучу так и неуправляемую. Он может использовать принцип RAII+явный вызов деструктора, а может и работать как Шарп. Причем код финалайзеров генерится компилятором по умолчанию, и построение леса using или try finally не нужно. Ты можешь размещать умправляемый объекты в неуправляемой куче, и наоборот, ты можешь неуправляемые объекты кидать в управляемую кучу. Ты можешь в реализации управляемых объектов использовать неуправляемые, так же как и наоборот. STL также "заточена" под работу не только с неуправляемыми объектами, но и с управляемыми. Ну и конечно полноценное метапрограммирование. И все это "опционально" ты можешь для решения одной и той же задачи использовать разные подходы или умело их сочетать. Шарп в этом плане более узколоб - только один подоход. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 09:15 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
dwl Выпуск MSVC 2005 показал, что с++ может тоже самое в NET и даже большее. Он может использовать как управляемую кучу так и неуправляемую. Он может использовать принцип RAII+явный вызов деструктора, а может и работать как Шарп. Причем код финалайзеров генерится компилятором по умолчанию, и построение леса using или try finally не нужно. Ты можешь размещать умправляемый объекты в неуправляемой куче, и наоборот, ты можешь неуправляемые объекты кидать в управляемую кучу. Ты можешь в реализации управляемых объектов использовать неуправляемые, так же как и наоборот. STL также "заточена" под работу не только с неуправляемыми объектами, но и с управляемыми. Ну и конечно полноценное метапрограммирование. И все это "опционально" ты можешь для решения одной и той же задачи использовать разные подходы или умело их сочетать. Шарп в этом плане более узколоб - только один подоход. Нет сомнений, что на С++ даже под .NET можна намутить гораздо больше, чем на всем остальном вместе взятом. Но надежности программам это не прибавит:)) C# разработан, чтобы там, где нет смысла гнаться за скоростью и гибкостью, иметь зато надежный и предсказуемый код, избавленный от множества нюансов написания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 11:37 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
C# не является "очищенным С++". Он является улучшенным и сделанным по-человечески языком Java. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 11:42 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
MasterZivC# не является "очищенным С++". Он является улучшенным и сделанным по-человечески языком Java. Ну это вопрос спорный: от кого пошел)))))) В С# есть много вещей, которых нет в Jave, для Java MS придумала специальную версию -- J# ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 11:48 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
LelikkНо надежности программам это не прибавит:)) кто вам такое сказал? и откуда ваще такое ложное данное следует? Повторюсь все что можно делать в Шарпе также можно делать и в С++/CLI, даже больше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 12:26 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
вот вам для простоты аналогия действий взятая из MSDN Allocate reference type Код: plaintext 1. 2. Allocate value type Код: plaintext 1. 2. Reference type, stack semantics Код: plaintext 1. 2. Calling Dispose method Код: plaintext 1. 2. 3. 4. 5. здесь еще следует добавить следующее - автоматическое формирование цепочки финализаторов в C++/CLI. В С++ как раз проще и безопасней получится. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. Implementing Dispose method Код: plaintext 1. 2. Implementing Finalize method Код: plaintext 1. 2. Boxing Код: plaintext 1. 2. Unboxing Код: plaintext 1. 2. 3. 4. 5. Reference type definition Код: plaintext 1. 2. 3. 4. Value type definition Код: plaintext 1. 2. 3. 4. Using properties Код: plaintext 1. 2. 3. 4. 5. Property definition Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. так что повторюсь, что в C++/CLI можно сделать все то же что и в C# и даже с большей безопасностью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 12:39 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
dwl Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Лол. Надо же как паршиво сделали J#. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 19:10 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
>> ReferenceType^ h = gcnew ReferenceType; // C++ Нет, это не C++! Такой C++ нам не нужен!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 19:20 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
dwl LelikkНо надежности программам это не прибавит:)) кто вам такое сказал? и откуда ваще такое ложное данное следует? Повторюсь все что можно делать в Шарпе также можно делать и в С++/CLI, даже больше. А кто сказал, что нельзя? Только идея C# -- создание мощного языка, свободного от некоторых сложностей и недостатков C++, приспособленного для работы в управляемой среде .NET C++ для .NET является не лучшим примером использования самого C++, так как к нему приставлены некоторые костыли для работы с типами .NET и язык в результате получился изуродованным. Мое мнение: C# -- для .NET, С++ -- для всего остального (конечно это касается не столько перенесения старого кода, сколько новых проектов) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2005, 22:34 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
LelikkC++ для .NET является не лучшим примером использования самого C++, так как к нему приставлены некоторые костыли для работы с типами .NET и язык в результате получился изуродованным. Это обмен мнениями. У меня,например, противоположное мнение. "Костыли" я костылями не считаю - это типы добавленные для совместимости с CLI. А при разработке в C++/CLI ты можешь использовать как управляемые так и неуправляемые классы. Даже STL сделали адаптированной для новых типов и ты можешь использовать ее для управляемых классов. Если ты видишь в чем-то "нехорошесть" этого, то лично мне хотелось бы увидеть конкретные примеры кода C++/CLI, которые тебе не нравятся и почему. Среду NET можно воспринимать как еще одну архитектуру для которой надо генерить код. C++/CLI просто научился это делать нормально. Так что под NET можно использовать не только Шарп. Если у тебя есть достаточно кол-во кода С++, который ты хочешь использовать в проектах NET, тогда думаю вряд ли будет удобней переписывать все на C#. Так что выбор инструмента сильно зависит от контекста задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 09:30 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
www.fun4me.narod.ruНет, это не C++! Такой C++ нам не нужен!!! 8-) ИМХО это гораздо красимше __gc class и прочих подобных префиксов. Глядя на все эти __boxed, __checked, __property у меня лично наоброт возникало желание программить на Шарпе. После того как я поюзал C++/CLI у меня несколько поменялось мнение. Есть вещи которые мне не нравятся в C++/CLI, например, добавлено понятие интерфейса. Это асбтрактный класс, все методы которого по умолчанию виртуальны, а все члены автоматом располагаются в public. Это сильно отличается от правил описания и поведения классов в С++. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 09:39 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
LelikkМое мнение: C# -- для .NET, С++ -- для всего остального (конечно это касается не столько перенесения старого кода, сколько новых проектов) Я не сказал, что предлагая переписывать все старые проекты на C#, я лишь высказал мнение, что для написание новых проектов под .NET возможно имеет смысл использовать C#, как язык, более приспособленный для работы в управляемой среде. Мне ненравятся не конкретные куски кода на С++, минус C++.NET, как раз в том, что он позволяет мешать управляемую кучу с неуправляемой, сводя в результате на нет весь смысл существования Framework. .NET как раз была создана, чтобы например НЕ ПОЗВОЛЯТЬ программисту вольничать с выделением памяти и забывать ее освобождать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 11:57 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
Lelikkминус C++.NET, как раз в том, что он позволяет мешать управляемую кучу с неуправляемой, сводя в результате на нет весь смысл существования Framework. .NET как раз была создана, чтобы например НЕ ПОЗВОЛЯТЬ программисту вольничать с выделением памяти и забывать ее освобождать. тут ты прав. и я согласен с тем, что чтобы использовать Шарп нужен меньший уровень подготовки(опыта), нежели чем в С++/CLI. Хотя писать НЕбезопасные куски кода в Шарпе тоже можно, а написать код, который неверно использует GC, нагружая проц, можно на любом NET языке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 13:29 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
--dwl --Повторюсь все что можно делать в Шарпе также можно делать и в С++/CLI, даже больше. --напиши мне код, где имя переменной генерится на основании времени компиляции файла -- ассемблерные вставки --напиши теплейт вида Код: plaintext 1. 2. 3. 4. 5. 6. 7. продолжать можно до бесконечности ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2005, 18:03 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
Lepsik--dwl --Повторюсь все что можно делать в Шарпе также можно делать и в С++/CLI, даже больше. --напиши мне код, где имя переменной генерится на основании времени компиляции файла -- ассемблерные вставки --напиши теплейт вида Код: plaintext 1. 2. 3. 4. 5. 6. 7. продолжать можно до бесконечности А смысл? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2005, 18:09 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
Lepsik--dwl --Повторюсь все что можно делать в Шарпе также можно делать и в С++/CLI, даже больше. --напиши мне код, где имя переменной генерится на основании времени компиляции файла Сомнительная полезность -- ассемблерные вставки Язык C# не создавался под какую-то целевую процессорную платформу, а следовательно использование ассемблера нецелесообразно. Хотя кросс-платформенный ILAsm все-таки есть. -- напиши теплейт вида #define BIN__N(x) (x) | x>>3 | x>>6 | x>>9 #define BIN__B(x) (x) & 0xf | (x)>>12 & 0xf0 #define BIN8(v) (BIN__B(BIN__N(0x##v))) #define BIN16(x1,x2) ((BIN8(x1)<<8)+BIN8(x2)) #define BIN24(x1,x2,x3) ((BIN8(x1)<<16)+(BIN8(x2)<<8)+BIN8(x3)) #define BIN32(x1,x2,x3,x4) ((BIN8(x1)<<24)+(BIN8(x2)<<16)+(BIN8(x3)<<8)+BIN8(x4)) #define BIN64(x1,x2,x3,x4,x5,x6,x7,x8) ((__int64(BIN32(x1,x2,x3,x4)) << 32) + __int64(BIN32(x5,x6,x7,x8))) Серверы приложений, для которых создавался C# оперируют количеством библиотек (сборок) порядка (100-1000). И использование статических фрагментов кода, которые ты называешь темплейты нецелесообразно по многим причинам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2005, 19:18 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
mayton --напиши мне код, где имя переменной генерится на основании времени компиляции файла Сомнительная полезность а мне приходится пользоваться. Из-за чего я С# считаю сомнительно полезным. LL ассемблерные вставки --Язык C# не создавался под какую-то целевую процессорную платформу, а следовательно использование ассемблера нецелесообразно. чего не взять все нецелесообразно. Как раз множество вещей который программистам класса а-ля бейсик (прошу не обижаться) и делают С++ мощным языком. Если уж задался вопрос : --Повторюсь все что можно делать в Шарпе также можно делать и в С++/CLI, даже больше. то юлить - это принцип скорее демагога чем рационального человека. -- напиши теплейт вида #define BIN__N(x) (x) | x>>3 | x>>6 | x>>9 #define BIN__B(x) (x) & 0xf | (x)>>12 & 0xf0 #define BIN8(v) (BIN__B(BIN__N(0x##v))) #define BIN16(x1,x2) ((BIN8(x1)<<8)+BIN8(x2)) #define BIN24(x1,x2,x3) ((BIN8(x1)<<16)+(BIN8(x2)<<8)+BIN8(x3)) #define BIN32(x1,x2,x3,x4) ((BIN8(x1)<<24)+(BIN8(x2)<<16)+(BIN8(x3)<<8)+BIN8(x4)) #define BIN64(x1,x2,x3,x4,x5,x6,x7,x8) ((__int64(BIN32(x1,x2,x3,x4)) << 32) + __int64(BIN32(x5,x6,x7,x8))) Серверы приложений, для которых создавался C# оперируют количеством библиотек (сборок) порядка (100-1000). И использование статических фрагментов кода, которые ты называешь темплейты нецелесообразно по многим причинам. опять нецелесообразно. это вообще-то не темплейты. Это дефайны - совершено другой класс манипулирования кодом. ни того ни друго в C# нет. М вообще этот младенец, которому отрубли руки и ноги и поставили протезы. И всех уверяют что с протезами ни руки ни ноги теперь болеть не могут. ходить теперь тяжело, но увеличением мощности процессора (добавление пары тройки новых программистов) данныя проблема устраняется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2005, 23:51 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
А для меня как для практика, ИМХО, важнее SDK. Java SDK на много круче, понятнее, разнообразнее и пр. чем C# SDK, Естественно если я буду писать что то многоплатформенное то это будет Java, (Хотя и это не факт, с такими продуктами как Qt (Trolltech.com) можно теперь это делать и на C++), а C# это этолько Винда, и все. Вообщем, мое субьективное мнение - в эстетическом плане мне Java нравится больше чем C#. Ну а С++ мешать в кучу даже не стоит, это как "жО с пальцем сравнивать"(с) народ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 10:19 |
|
||
|
С++ и С#
|
|||
|---|---|---|---|
|
#18+
Lepsik --напиши мне код, где имя переменной генерится на основании времени компиляции файла -- ассемблерные вставки --напиши теплейт вида не вижу никаких трудностей в этом в C++/CLI. Если у вас нет описания стандарта ECMA от августа 2004 года, тогда советую скачать. Я вобчем-то поэтому и предпочитаю использовать C++/CLI, а не Шарп, потому что есть некоторые наработанные приемы и привычки. Но мне также не составит труда и писать на Шарпе. Поэтому я не навязываю свое видение никому, т.к. имею опыт разработки и там и там. Кстати, меня иногда добивает "ПРИНЦИПИАЛЬНОСТЬ" некоторых разработчиков компонент NET, которые в визарде не предсматривают разделителей C++. Поэтому InitalizeComponents приходится для таких компонент править ручками. Дело в том, что ИМХО сейчас время "специализированных" языков. Просто потому, что кое-кто слишком часто придумывает всякого рода революции. Пяток лет назад некоторые были уверены в гениальность COM охали и ахали, кругом технология эта продвигалась и рекламировалась. Прошло пять лет и теперь пишут что COM есть очень ии очень плохо и неудобно и ваще вчерашний день. "Сейчас в Париже носят так...". Вобчем опять всплыл очередной "фатальный недостаток". Видимо там народу за революцию выдают премию. Кароче, никто не гарантирует, что через 5-6 лет не грянет что-то новое. А у NET окажется "один фатальный недостаток". Ну а раз так часто меняется окружение, в которой дожна работать прога, то и ужесточаются требования к времени изучения этого окружения и инструментов для него. Поэтому в таком случае экономически выгодно выпустить узкоспециализированный инструмент, который проще изучить. Который можно преподнести, как панацею от всех проблем. Некоторые разработчики NET так относятся например к GC. Типа "бесконечная" память, не надо думать о обработке "утечек памяти". Но из них мало кто задумывается о том, как это работает и какую цену приходится платить. Не зная анатомии проблемы, они прибегают в какое-то публичное место и кричат, что старые инструменты (С++ или что-то еще) есть "какез" по определению, потому что там нет GC (или стандартной библиотеки компонент). Они, например, даже не представляют насколько GC меняет понятие времени жизни объекта. И вносит некие коррективы в "типобезопасность". "кик-старт" вещь конечно веселая, если не сказать экстримальная. Но если кухарка написала прогу на VB.NET - это не значит, что она программист. Как не значит то, что если я умею готовить яишницу, то я кулинар. Изучение С++ безусловно обогатит и расширит понимание о программировании, того кто изучает. Поэтому ИМХО даже если ты пишешь проги на Шарпе, то стоит взглянуть и на С++. Но я несчитаю, что "богачества" С++, дают право как-то обесценивать те или иные языки. Просто всему свое время и место. Есть кое-какие фишки в Шарпе, которых нет в C++(например partial). Об обратном я уже говорил. На NET можно писать хоть на VB, хоть на C#, хоть на C++. Право выбора за разработчиком. Спорить о безусловном критерии или абсолютно удобном языке - это вводить и себя и окружающих в заблуждение. Это как философия, которая не имеет ничего общего с правдой жизни. ИМХО. Если человек открывший тему действительно хочет сравнить языки, то оптимальней будет скачать стандарт 2.7 для C# и стандарт C++/CLI (т.к. сравнение будет для NET). Почитать эти стандарты и сделать выводы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 12:00 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=32886160&tid=2033728]: |
0ms |
get settings: |
11ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
81ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
| others: | 238ms |
| total: | 423ms |

| 0 / 0 |
