|
На теория не би трябвало да има разлика между теорията и практиката, но на практика не е точно така
Тия неща дето ги казваш могат да се прочетат във всеки жабешки учебник и повечето са абсолютно грешни, или са откровена рекламна лъжа. За сметка на това някои аспекти са пропуснати ( премълчани ). Аз съм работил и на двата езика и имам някои наблюдения. Ето и моя анализ на казаното:
В отговор на:
Основното предимство на Java е, че е платформа, контролираща изпълнението на програмата.
ОК, това е добре - така си независим от OS ( поне на теория. На практика не е съвсем така, но това е друга тема ).
В отговор на:
Не се занимаваш директно с управлението на паметта
На теория това е много хубаво, ако е направено добре и работи. Но не е, а липсата на каквито и да е механизми за 'ръчен' контрол на паметта прави нещата трагични.
Какво се получава на практика? Получава се, че хората пишат Object Pools и правят всякакви еквилибристики за Object Reusing за да задържат консумацията на памет в разумни граници. Т.е. не се занимават директно, а индиректно с управлението на паметта, което е значително по-трудно.
В отговор на:
и освен това всяка команда се проверява за коректност (примерно индексиране на масив).
Предобрили са го. Ако имаш random access и искаш достъп до произволен елемент е приемливо. Ама като имам нещо от рода на
for( i = 0; i < arr.size(); ++i ) // не помня как се пишеше това на Жаба
( i не се бара в цикъла ) проверката си е живо разточителство.
C++ също има такъв механизъм за проверка в контейнерите си, чрез достъп до елементите не по индекс а с container.at(index)
В отговор на:
Като по-съвременен език от C++, Java няма нужда от препроцесор
И тук работата като при паметта - теорията и практиката съществено се разминават. Ако извикването на функции с празно тяло нямаше никакъв ефект - добре. Но нещата не са направени както трябва и в момента няма добър начин да е направи trace( .. ) функция. Извикването на функция, заедно с целия текст влиза в изходния код, макар функцията да е празна. Не помагат и модификатори static final. Затова вмесо
trace("bla bla")
хората пишат
if( traceEnabled ) trace("bla bla");
Тъпо!
В отговор на:
стандартните библиотеки, които ти дават почти всичко
Дават, но са лошо документирани и са на светлинни години от MSDN. Затова често се налага да се прави reverse engineering.
В отговор на:
от мениджърска гледна точка изглежда, че с Java е много по-лесно да се напише работещ код, без класическите програмистки грешки като изтичане на памет, препълване на буфери, използване на различни декларации или параметри на интерфейси и т.н., които изяждат много време за дебъгване.
Абе не знам мениджърите какво разбират от тия неща дето ги изброи. Според мен това което те най-харесват в Жабата е лесното портване на различни OS.
Що се отнася до 'класическите' грешки - от години не съм допускал нито една от тях. Те не са трудни за избягване с добра практика.
В отговор на:
Основният проблем при Java е, че контролирания код е тежък - изисква много процесорна мощ и памет. Поради това, макар че теоретично не трябва да има голяма разлика в скорстта между приложение, писано на Java и такова, писано на C++, хората забелязват без особени усилия в повечето случаи тромавия Java код.
Основният проблем е, че жабата действа на програмиста отпускащо и той не се замисля за ресурса. С лекота се правят нови обекти, копират се данни ненужно и т.н. Кой жабар сте видели да ползва StringBuf вместо да си събира стринговете с '+'? А ресурсите за контрол отдавна не се смятат за големи.
Някои недостатъци на езика:
- Няма еквивалент на const * предаването на аргументи на функция. Това прави трудно проследяването на даден аргумент дали се модифицира.
- Няма const модификатори на функции. Това затруднява проследяването дали се модифицират членове на класа.
- Няма templates ( всъщност напоследък май са сложили, но това е твърде ново за да влияе ). Това налага чест typecast и ненужни RTTI проверки.
- Няма слаби, или профилирани кастове. А езикът налага прекалено често ползване на typecast. Това е потенциален извор на грешки и ненужни RTTI проверки.
- Няма беззнаково разширение на целочислените типове ( но пък има беззнаково шифтване на дясно, което е добре ). C++ програмистите често остават неприятно изненадани, че ако в буфера има байт със стойност FF като го разширят не става 255, а -1. Затова се налага да се пише нещо от рода на
i = b&0xFF;
System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_
|
Като по учебник [re: Masklin]
