5 основных отличий между Java и C++

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

Спасибо 

правильно.

В Java нет указателей в отлиичии от C++
B Java нет глобальных переменных.
.........



Все отличия хороши, выбирай на вкус!  

Добавлено @ 14:57 
Java - это чистый ОО язык, С++ - гибридный. 

"Многонаследование" существует только для интерфейсов 

Вообщем все верно.

Основное отличие Java от С++ состоит в том, что Java это в первую очередь платформа:

• среда выполнения (JRE)
• библиотека стандартных компонентов (framework)
• язык программирования Java

Есть и языковые отличия, в основном касаются работы с указателями. В частности вообще нет поинтерной арифметики, указателей на функции и т.п.
А какова собственно цель вопроса? 

"многонаследование" 

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

Извиняюсь за "многонаследование", конечно "множественное наследование". Это я просто читаю на англ., финском и русском, пытаясь найти инфу, вот в голове и каша  
Цель вопроса - хочу попасть на курсы по программир-ю, попала в 30 чел. отобранных на собеседование, теперь дали задание на дом: 20 вопросов, отберут 16 чел. Хочу очень, нет - просто надо!  
Спасибо всем отозвавшимся, теперь буду формулировать это по фински.  
 

Открываете Google и пишете запрос: "java and c++ differences". На первой же странице куча ссылок.  Это во-первых. А во-вторых, как верно заметил LSD, Java - это платформа, а C++ - это язык (или язык плюс некоторое количество стандартных библиотек, если рассматривать стандартный ANSI C++). Вообще некорректный вопрос, короче. 

Это сообщение отредактировал(а) w1nd - 8.5.2006, 21:53

a)
C++ code - ANSI code.
Java code - Unicode code.

b)
C++, int x;  if( x ) block1; else block2;
Java, boolean con; if( con ) block1; else block2;
 

Первый пункт - неверно, второй - явно далекое от основных отличие. 

В принципе, это следствие из весьма важного отличия Java — типобезопасности, как статической, так и в рантайме. Java позволяет гораздо меньше «тихих» приведений типов, а некорректная интерпретация типа объекта ведет, в отличие от C++, не к неопределенному поведению (читай, непредсказуемым граблям), а к выбросу исключения. 

• C++ - машинный код / Java - интерпретируемый код (необходим интерпретатор - JVM) 
  (Тут как следствие несколько пунктов Платформонезависимость в обмен на зависимость от JVM,  Типы (размер) в С++ не определены точно и зависят от компилятора, а на Java типы на всех платтформах одинаковы. )
• С++ "- Возможно всё, чтего только пожелает программист!" перегрузка операторов, наследование итд. / Java - Возможно только то, что разработчики Явы посчитали логически безопасным. (Этот пункт тоже можно развить на несколько: Перегрузка операторов, множественное наследование итд.)
• С++ - не полностью Обьектно-ориентированный (возможна смесь с Си, #define и прочие извращения) / Java - полностью обьектно-ориентированный. 
• С++ - Программист полностью сам котроллирует состояние программы, валидность указателей итд./  Java - этим забавляется сборщик мусора и среда Runtime
• C++ - множество библиотек различной степени свежести и помятости  / Java - стандартные библиотеки, распространяемые с JVM, в которых шанс выстрелить себе в ногу сведена практически до нуля

Остальные отличия, как например синтаксис, ява-специфичные степени инкапсуляции ("protected"), особенности поиска библиотек компилятором итд.  присутствуют также, но ИМХО отходят далеко на второй план
      

Не совсем так. Просто в C++ нет булевского типа.  

Это сообщение отредактировал(а) w1nd - 9.5.2006, 01:33

Это вы мне говорите?  А с Си не путаете? В C++ есть булевский тип (bool), другой вопрос, что вследствие type promotions к нему приводятся почти все элементарные типы…

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

Добавлено @ 01:36 

В C++ присутствует. 

Я поправился (см. выше)
Упс, путаю. Хорошо, в условиях не нужен булевский тип. Все равно не пойму, причем здесь типобезопасность, которой нет.   

Это сообщение отредактировал(а) w1nd - 9.5.2006, 05:37

Ни C++ ни Java не являются  полностью объектными языками. Полностью объектный язык, это язык, у которого все является объектами, т.е. нет примитивных типов вообще. Кроме того, еще можно смело спорить какой из двух языков предоставляет большие возможности объектно ориентированного программирования.  Попробуйте на Java  самостоятельно написать класс java.lang.String  это не возможно у String перегружена оперция "+". хе хе. а на С++ вы напишете такое запросто. С++ ые templates это конечно предмет вечной зависти... так что не всё так просто.

Остальные перечисленные пункты тоже верны не доконца и спорны .  

Это сообщение отредактировал(а) ALKS - 9.5.2006, 08:44

Куча ссылок это хорошо, но там же еще и отличий куча.
 Вопрос стоит какие из них действительно принципиальные, а какие - просто детали.
Мне надо выбрать всего 5.   
Пока зто в списке: 
C++ - машинный код / Java - интерпретируемый код 
 Java- ОО язык, а С++ - гибридный
 Java не позволяет множ. наследования
 Java:  нет указателей
 Java: автоматический сборщик мусора
 Java- типобезопасность
 Java - стандартные библиотеки, 
Java -отсутствие глобальных переменных

   

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

Java не докoнца OO язык. и что самое не приятно Java это язык со злым "неравеством типов"

Java не позволяет множественное наследование ДЛЯ КЛАССОВ. а в принцепе - позволяет . это довольно существенное замечание.

В Java есть указатели.  В java нету синтаксиса для прямой работы с ними. нет арифметики указателей. но указатели сами по себе есть. В метод передаётся ссылка на объект, а не сам объект. вот почитайте милую статью: http://www.javable.com/columns/robinson/letters/01/

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

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

стандартные библиотеки? а это что: http://en.wikipedia.org/wiki/ISO/IEC_14882 ? Стандартная библиотека C++  стандартна в прямом смысле ибо есть соответсвующий стандарт ISO! Java может пускать слюни 

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

Тьфу блин! "package protected" конечно имелся ввиду 


В Java есть они 


По крайней мере в Java - приложении присутствует как минимум один обьект. В с++ коде может не быть ни одного 

На Java можно прогить и не пользуясь прим. типами. Впрочем как и на С++. Здесь разницы большой нет между ними.


Дык напиши пару тройку своих, тоже поспорим 


Лучше не надо этот пункт брать. В Си++ типобезопастность тоже на высоте.


И это лучше не брать. В Java есть модификатор static.


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

sergej.z

 генерикс + автобоксинг это НЕ темплейты. далеко НЕ. хотя формально механизм темплейтов в С++ это уже не объекто ориентированое програмирование это абстрактное программирование - следующий шаг.

есть в Java объект всегда. ок. но это не далает Java полноcтью OO языком. Да, я придераюсь к этому слову: полноcтью. В отношении Java его употреблять нельзя. и не только в простых типах дело. есть и ещё нюансы. И нельзя говорить что С++ менее OO чем Java это не правда. он как раз "более". Единственное что можно сказать: на С++ можно писать полностью НЕ объектный код, а на Java - нет. 

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

Это сообщение отредактировал(а) ALKS - 9.5.2006, 10:38

Если быть точным, в Java все передается по значению. Да, в случае передачи объекта, параметр метода - это ссылка, но сама ссылка то передается по значению.
То есть, выполнив этот код, вы получите NullPointerException:


А все потому что, ссылка, передаваемая как аргумент в someMethod, передана по значению, и если изменять ее значение внутри метода, ссылка на "верхнем" уровне не изменится. Как она была null, так и останется. Другое дело, если изменить объект, на который указывает эта ссылка.
Таким образом, формально в Java ВСЕ передается по значению.   

Это сообщение отредактировал(а) JUncle - 9.5.2006, 11:43

JUncle, не надо утрировать  Естесственно в компьютерном мире всё так или иначе передаётся по значению (Спускаясь до машинных инструкций). Таким образом дойдём до того, Что различий между любыми языками не существует, так как всё в конце концов превращается в 0 (включая 1, которая - инвертированный 0). Так можно что угодно упростить 

Ссылка (или указатель) это абстрактная величина. Обьект передаётся именно по ссылке (которая в свою очередь ессно по значению).  

Часть перечисленных отличий относится к Java как к языку, а часть как к среде выполнения. К тому же есть пара неточностей: в Java указатели есть, но они защищенные, т.е. нельзя присвоить значение неверного типа, не разрешены арифметические операции с ним. И стандартные библиотеки есть и в С++.

Добавлено @ 12:03 
И еще, товарищи давайте не будем увлекаться религиозными войнами на тему Java vs C++. Для этого есть специальный раздел. 

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

и вообще дискусия интерсна. вот. 

Вообще, как основное отличие надо добавить кроссплатформенность. 

А-а-а-а!!! Это что за зверь?   

Программа написанная на Java может быть без переделок, запущена на любой платформе где есть JVM.

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

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

Вот это про кроссплатформенность?

"The output of a Java compiler is not executable code. Rather it is bytecode. Using bytecode to represent programs is the easiest way to create truly portable programs." 

Это объяснение, как она реализована. 

ууу  ну уж нет. не все так просто. вэб приложение на J2EE вы на мобильнике не запустите. кроме того криво написанное Java приложение не заработает где попало. тут LSD прав. типичный пример - не использование System.getProperty("file.separator") при формировании имен файлов. есть и иные нюансы. кроме того Java приложение вы сможете запустить только на платформе для которой существует JVM и тут встают вопросы о совместимости конкретной JVM со спецификацией и её версией. Но в общем случае обеспечить переносимость приложения на Java на порядок проще, чем приложение на С++.

С другой стороны, не ошибусь если скажу что плактичиски любая платформа имеет компилятор С, но далеко не любая - JVM... 

В таком случае можно ли сказать, что кроссплатформенность это следствие пункта:
C++ - машинный код / Java - интерпретируемый код 
 

Кроссплатформенность Java, (уж какая есть   ), обеспечивается благодаря первоначальной компиляции программы  в байт код и Интерпретации / JIT компиляции при выполнении.
  

Это сообщение отредактировал(а) MoonCat - 9.5.2006, 13:53

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

спасибо, понятно! 

to Sergej.z


И это лучше не брать. В Java есть модификатор static.

запуталась! А как же вот это:
" All the code in a Java program is encapsulated within one or more classes. Therefore, Java does not have global variables or global functions."

http://www.csupomona.edu/~dlbell/cppexplanationsfa99/23.html
 

Добавлено @ 14:25 
[QUOTE=sergej.z,9.5.2006,  10:19]


"Perhaps the single biggest difference between Java and C++ is that Java does not support pointers. Pointers are inherently insecure and troublesome. Since pointers do not exist in Java, neither does the -> operator. Some other C++ features are not found in Java."
и это оттуда же! Вполне однозначно написано:"Java не поддерживает указатели"
Вот поди разберись! 

 "->" это операция из С++. как она правильно называеться? блин, совсем С забыл 
да ничего подобного в Java нету. но это операции с указателями а не сами указатели. т.е. указатели то в Java есть и они неявно испозуються. но вот явного синтаксиса для работы с ними, как в C/C++ - нету. но это всё - большие тонкости... 

raiskaa, это же просто люди писали. Всё зависит от абстрактной позиции, которую занимаешь. 
Естественно программист не найдёт в Ява указателей при программинге. Но всё же они там есть, просто скрыты от нас. Поэтому сказать "Ява не поддерживает указатели" - слишком мало. Не хватает ", но ..."   



Нет, но есть статические члены/мемберы класса.



Вот у нас и аналог глобальной переменной и глобальной функции.

  

Еще раз спасибо, теперь проясняется    

Ну - J2EE это не pure java. Это просто набор спецификаций.


Это не совсем то - т.к. в общем понимании кроссплатформенность присуща программе, когда ее бинарник не нужно  формировать заново для новой платформы (как в случае с С \ С++).


Следуя хорошему тону, static поля вообще то должны быть финальными (final), и аналогом в С будут уже скорее макросы, а не глобальные переменные (которые, как правило, есть знак плохой архитектуры).   

Это сообщение отредактировал(а) sergej.z - 9.5.2006, 17:56

Вообще-то Ява не запрещает их делать не final. Для этого есть хорошие причины, например private static абсолютно не противоречит "хорошему" тону (взять хотя бы тот же синглтон из Вашей подписи  ). 
Кстати насчёт "хорошего" тона или "плохой" архитектуры    - это на 99% процентов зависит от поставленной задачи и её условий, но так как мы обсуждаем отличия от С++, это к делу не относится.
  

Если бы Java запрещала что-то, то об этом не было бы и речи  
А в случае private полей, действительно, разговор другой, но и о глобальных переменных тогда тоже речи не идет. 

А насчет отношения Java и C++ к ООП -
С++ не может быть "более-ООП" языком, т.к. на нем все-таки можно написать действующую не-ООП программу.
С другой стороны, на Java можно тоже написать программу, с точки здравого смысла абсолютно не ООП. Однако формально она все-таки будет ООП программой (если не принимать во внимание примитивы).
Кстати, читал, что назвать Java ООП языком не позволяет, кроме примитивов и еще один факт. Объекты должны общаться посредством сообщений, а методы Java это несколько другое. 


Ну что ж, кроме цифры 99, вообще согласен  Хорошо, не будем об этом. 

Это сообщение отредактировал(а) JUncle - 9.5.2006, 18:06

Согласен J2EE - плохой пример. я не сталкивался с J2ME вообще, к сожалению. Но разве J2SE программа написанная, для простоты, в рамках любых классов из трех основных пакетов - lang, io и util пойдет без всяких ограничений в рамках J2ME?


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

Да, я это забыл отметить, действительно, есть некоторые ограничения. В т.ч и обратные - т.е. в случае J2ME программы на J2SE JVM,


Ну может быть... Однако один из самых широких классов - GUI программы - в случае с С++ кросплатформенными никак назвать нельзя.

И если допустить, что С++ программы кроссплатформенны, получается, что Java программы более кроссплатформенны, т.к. для их переноса на другую платформу в общем случае требуется меньше затрат* -  мб ввести такую величину как коэффициент кроссплатформенности?   

* - при условии что на платформе етсь JVM
Однако в случаее с С++ для платформы так же должен существовать компилятор. Так что тут они в равных условиях. 

Это сообщение отредактировал(а) JUncle - 9.5.2006, 18:21

С++ безусловно "более-ООП" язык, так как на нем в отличие от Java можно не извращаясь создать полностью ООП-программу.


Это не так, не следует воспринимать буквально слова о сообщениях.
 

Хм.. Только это к языку и философии программинга мало относится. Можно проект на асме написать, который без проблем скомпилится на любой платформе. Но Асм назвать кроссплатформенным думаю ни у кого язык не повернётся 

А на Яве кроссплатформенный именно бинарник, а не "проект". Что само по себе, кроме этого удобстава несёт ещё и удобства контроля и управления проектом (который не надо пичкать if else #ifdef _WIN32 итд.) Один исходник, один бинарник. Это в рамках большого проекта экономит тысячи долларов (говорю для того чтобы немного расшевелить вышеприведённое определение). Каждый, кто несколько лет занимался разработкой кроссплатформенных проектов на Си и Си++ меня поймут       

А можно подробнее?



За что купил, за то и продал.  

Полностью ОО - программа без извращений  

Не вижу ничего, что указывало бы на объектно-ориентированность. Конструкция языка "класс" имеет к ОО весьма опосредованное отношение.

Добавлено @ 18:48 
Я вообще не понимаю разговоров о "некроссплатформенности" Java. Один из аргументов - разница в наборе классов RT; другой - разные JVM, на которых один и тот же код может выполняться по-разному; третий - не везде есть JVM. Все эти утверждения несостоятельны: байт-код исполняется одинаково везде. Если в в JVM для утюга отсутствуют классы для работы с дисплеем или в какой-то реализации JVM попросту наделано ошибок, то это никак не относится к вопросу о кроссплатформенности. Если для платформы X нет JVM - никто не мешает её написать. 

В таком случае напишите пожалуйста полностью ООПрограмму на С++ (Ну или "более" ООПрограмму) 


Добавлю, что кроссплатформенность заканчивается там, где заканчиваются платтформы, на которые разработчику следует ориентироваться. А нормальные JVM есть для линя, винды, соляриса. Это наверняка покрывает бОльшую часть необходимых.
   

Java - кодеры, дайте пожалуйста точное определение кроссплатформенности, чтобы знать с какой точки начать обсуждение. 

Для java: перенос с платформы на платформу без изменений. 

Перенос чего? Кода? Бинарника? Проекта? 

Не честно
Это множественное наследование… в Java оно реализуется(частично) через implements… а вообще по Эккелю Java более чистокровный ОО язык.
И еще, на Java можно реализовать аспектно-орентированный подход в программировании, в C++ это сделать трудней… 

Разумеется, конечного программного продукта. Бинарника, то бишь.

Добавлено @ 20:20 

Почему не честно? А реализовывать один и тот же метод на страницу текста в пяти-десяти-сотне классов вместо одного это честно и удобно? Или то, что класс, обладающий координатами к координатам откастить нельзя - это апогей ООП?

Чистокровный? Ну уж ерунды-то не говорите. Да и кто такой Эккель? Это что за авторитет такой? 

Да, в C++ это делать несколько трудней, но ничто не мешает. 

[QUOTE=sergej.z,9.5.2006,  18:23]
Про ASM это ты ляпнул!  стоимость портирования ASM приложения на другую процессорную архитектуру равна как минимум стоимости разработки проекта с нуля  напиши прогу на асме и пропартируй на x86, Motorolla, Z80 и мой любый мэинфрейм DEC  - убедишся сам. В истории софта, самая-самая "много на ASM" система была Novell Netware 2.x. Они говрили что она написана на ASM на 30% (невероятно много!!! ). история помнит что установка этой OS, была настолько сложным делом что возникли 100-ни контор в этом помогающие... а дело в том что там было необходимо фактически компилировать OS под каждый конкретный сервер... 

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

Для меня "более" объектен тот язык который предоставляет мне больше эээ... ОО-возможностей. С++ есть множесетвенное наследование классов, перегрузка операций, шаблоны. да можно спорить о том хороший ли скажем стиль - активно применять множественное наследование в глубоких иерархиях и т.д и т.п. но эта возможность в С++ есть, а в java - нет. Есть масса примеров когда грамотное применение множественного наследования действительно порождает изящество и помогает избежать маштабного дублировнаия кода. множественное наследование интерфейсов и внутринние классы зглаживают, но не заменяют.

перегрузка операций это что-то отсутсвие чегов Java  меня злит постоянно.... я искренне не понимаю почему её не возможно реализовать хотябы на уровне компилятора. ээххх каждый раз  когда я работаю с JDBC вспоминаеться объектно орриентированная С++ библиотека для работы с сервером SQLBase... они перегрузили только 2 операции а 10-ки строк кода тупых сэтов и гетов просто ушли... 

На мой взгляд самое принципиальное различие - java требует чтобы программист обрабатывал ошибки.
То есть если вы к примеру из программы открываете файл, java на стадии компиляции будет проверять налилче обработчика IOException. Если ее нет - класс просто не скомпилируется. 


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

И наконец третье важное отличие явы - конструкция finally {} после try, которая гарантированно выполняется независимо от того, были exceptions или нет.  Этот finally очень облегчает работу с ресурсами и уменьшает количество ошибок.

  

Это сообщение отредактировал(а) Бонифаций - 9.5.2006, 21:48

Что вы говорите? А как же быть с тем, что когда исключения появились в C++, Java была только в проекте?

Ничто не мешает реализовать GC в программе на C++. GC - это мимо кассы однозначно.   

Это сообщение отредактировал(а) w1nd - 9.5.2006, 21:48

Хм… ну в таком случаи нужно сравнивать С++ с С# там тоже убрали множественное наследование в чистом виде… C# это ж не отход от принципов ООП а, как предполагается, их развитие… 

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

Если время дорого, имеет смысл подумать о применении фреймворков. И почему геты и сеты тупые? Это же часть технологии JavaBeans, играющей не последнюю роль в вышеупомянутых фреймворках (сериализация объектов в РБД и пр...)  

Это сообщение отредактировал(а) JUncle - 9.5.2006, 21:52

... и его будут испрользовать только те части программы на С, которые о нем знают . А все остальные сишные бибки - так и будут работать с памятью по старому. И в чем тут радость? проходили - знаем, пробовали boehm GC 

Нет уж позвольте. В Java работа с иключениями приниципиально ничем не отличается от того, что есть в C++. Компилятор C++ точно так же будет требовать кода обработки. 

В С++ есть контролируемые исключения, простите?! 

ANSI-шные - все. А как вам работа с системными библиотеками из Java? Они ведь тоже не знают про GC и не могут его использовать.

Добавлено @ 22:02 

Так вот вы о чем  Да, нет различий. Но будет ли компилироваться такой код - вопрос настройки компилятора.  Единственное отличие (и оно проистекает изтого, что в Java бинарник - это не машинный код) - это информация о исключениях в сигнатурах методов. 

Это сообщение отредактировал(а) w1nd - 9.5.2006, 22:07

Какого именно? javac или сишного? 

Сишного. 

Ох!

Вот вам простой пример:


Компилируется без проблем


Выдает
Ax.java:6: unreachable statement
   System.out.println ("мы тут");
   ^
Ax.java:5: unreported exception java.lang.Exception; must be caught or declared to be thrown
   throw new Exception("Эй!");
   ^
2 errors

 Чувствуете разницу? 

Это сообщение отредактировал(а) Бонифаций - 9.5.2006, 22:11

слово "Компьютер" - может быть идентификатором в JAVA.
в С/C++ не может быть.[традиционно  ] 
  

Это сообщение отредактировал(а) jxr - 9.5.2006, 22:14

А зачем, как вы думаете, сишный метод может быть дополнен конструкцией throw(...)? Кроме того, любой может также написать компилятор java, который не будет ругаться на необработанные исключения.    

Это сообщение отредактировал(а) w1nd - 9.5.2006, 22:22

давайте реально,
-  какой процент Ваших C/C++ проектов используют Garbage Collecting для памяти?
- какой процент C/C++ проектов  ваших друзей или других вам известных программистов используют Garbage Collecting?

то что в яве это сделали - это большой шаг вперед относительно C++

Добавлено @ 22:27 


вы это серьезно?    

Один. Написан восемь лет назад в целях закрепления знаний  

Речь не об этом. GC - это специфицированная фича JVM, а не особенность языка. И считать это различием, на мой взгляд, не стоит. А то так мы доберемся до стравнения IDE для Java и C++. Также, думаю, не стоит принципиальным различием считать поведение компиляторов, разные названия одних и тех же языковых конструкций и прочая, и прочая.  


А как же? Байт код известен, тулзами вроде "компиляторов компиляторов" хоть пруд пруди.

 

Это сообщение отредактировал(а) w1nd - 9.5.2006, 22:34