Защо Java

123 отговора 6565 прегледа
в отговор на lngon #81

Не е същото

Това знаеш че ще се викне някой ден, но нямаш гаранция кога и в какъв ред ( ако са повече обекти зависещи един от друг ). Има ситуации в които това никак не е без значение.

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_
Отговор
в отговор на Colombino #82

Re: Не е същото

Определено не е същото.

Отговор
в отговор на Paдo #83

Re: Това е несериозно

Нали в новия Ц# вкарват анонимни делегати, много подобни на closures в Джаваскрипт. Та тва, което аз разбрах (в Джаваскрипт синтаксис) сигурно ще е:


function transactedOperation(action)
{
try
{
transaction.start();
action();
transaction.commit();
}
catch(error)
{
transaction.rollBack();
}
}


Примерна употреба:


transactedOperation(function()
{
...
});


Бе нещо като ruby аналога:


File.open("myfile") do |file|
#do something with file
end


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

Отговор
в отговор на Дeшeв #84

Re: Това е несериозно

Аха, яко.

Отговор
в отговор на Colombino #85

Сериозно?

Е, пак стана флейм.

> "Но C/C++ програмистите рядко алокират в унес като жабарите. Ако на един добър C++ програмист му се налага да алокира множество малки обекти ще го направи с по-големи блокове и placement new, или с по-сложен RecordManager. "

Ами от доста време работя на едно място, където се пише САМО на C++, (големи проекти - по към 200000 - 250000 реда C++) и познай какво?

1. Въпреки, че честно казано кода се влачи като ... задник, никой не е намерил време, желание, смелост, etc. да напише и едно единствено placement new. Даже си мисля че ако някой го направи ще го обвинят че се прави на интересен и само затормозява работата etc. Девиза е - не искаме нищо прекалено странно, нищо прекалено добро и нищо прекалено лошо :)

2. Единствения път когато имам спомен да се е работило по управлението на паметта беше когато ми възложиха "задачка": Find the memory damage.

3. Това че не си виждал повторно използване на деалокирана памет най-вероятно означава че просто проектите по които си работил не са натрупали критична маса хакове в тях :) Веднъж това стане ли, после чакай само проблеми.


Незнам за какво са деструкторите. Наличието им предполага, че в един момент трябва да кажеш - ами вече свърших с този обект и повече няма да ми трябва. Т.е. това не предполага ли ръчно управление на паметта? Или пък някакъв стек за локалните променливи и като се излезе от scope се викат деструктори?
По този начин не се ли връзва езика с управлението на паметта? Т.е. все едно казваш: Този език е направен само за ръчно упревление на паметта - квито и техники за автоматично управление да се измислят този език няма да ги ползва. И всичко това само за да можеш да "забравиш" да викнеш (например) .close() на локалния обект. Тарикатско!
И във връзка с това се сетих за един много неприятен случай:
написва някой една функция която има за параметър указател към обект.


void BadFunction( Object *pObj ); //uses the object pointed to by pObj in some mumbo-jumbo


Някой друг иска да ползва тази функция:


{
Object my("local");
BadFunction( &my );
}


След като написва това Някой II се сеща, че не му е ясно какво точно прави BadFunction()! Дали тази функция просто взима някакви данни от обекта за да си свърши сметката или запомня указател към тези данни? (И след малко някой се опитва да използва този указател? (щото ако е така ще падне дебъгване))
Представи си че BadFunction реализира комуникация по мрежа - изпраща данни за Обекта по мрежата. Тогава ако този който е писал функцията е имал мозък сигурно можеш да се надяваш че той е копирал всичко което му трябва и my може спокойно да бъде унищожен. На практика обаче:
BadFunction е била написана за конкретен случай (такива най ги мразя :) ) и тогава (за ефективност) не са написали копиране (защото строго погледнато не е било необходимо). Сега някой друг се опитва да използва вече написан код и бива изненадан неприятно - за да изпозва кода, първо трябва да го прочете, а после трябва и да го пренапише :)
Това е проблема с неясните интерфейси. И е наистина шибан проблем. Особено в големи, писани набързо проекти, без ясна ръководна идея ... айде да спирам с критиките че току-виж съм се оказал на улицата :)

What evil shall I do today?
Отговор
в отговор на Dark_Dirk #86

за без пари

> "Java също така е и безплатна. Това също е едно от обясненията защо се предпочита Java-та."

Това може да е в минус стане ли въпрос за големи компании. Те обичат да се перчат с пари :)

По-скоро е въпрос на мода. И на "здрав разум" (доколкото може де!): Началника си мисли: понеже Java е токлова стандартен и толкова разпространен мога лесно да си наемам хора, да си ги уволнявам, да не им плащам, да съм абсолютен гъз...Супер!

What evil shall I do today?
Отговор
в отговор на G.Kreisel #87

Re: Сериозно?

За да нямаш проблеми с пропуснат .close() - сложи си един аssert в деструктура (да те предупреди). А може и да си викаш .close() (ако вече не е викнат) - те деструкторите са за това... (тя заеманата памет се чисти от delete а не от деструктура)

За да нямаш проблеми както описаните от теб с BadFunction(...) - мисли преди да наименуваш фунциите и техните параметри. И да не забравиш да напишеш някой по-смислен коментар от "//uses the object pointed to by pObj in some mumbo-jumbo"... Подобни проблеми може да имаш независимо от езика за програмиране който ползваш!

Отговор
в отговор на G.Kreisel #88

Re: Сериозно?

Признавам, че съм пристрастен. C++ е опасен език и на него по-лесно могат да се правят бели. Но това всъщност не е проблем на C++, а на C. Повечето хора просто не пишат на C++, защото не го знаят достатъчно добре, или просто защото ги мързи. Масово се пише на "C с обекти". Ей от там иде целия проблем. Друга честа причина да се пише така е недостатъчната компетентност на голяма част от екипа, нает на възможно най-ниски цени.

Деструкторите са за извършване на обратното действие на конструкторите. Всеки път, когато трябва да се извършат чифт действия ползвай клас и никога няма да видиш нито memory damage, нито нещо подобно.

А твоя пример с BadFuncton не виждам кво му пречи да е абсолютно 1:1 на жаба ( без знака за адрес, щото там всичко е пойнтер ). Лошо може да се пише на всеки език.

Аз само твърдя, че ако човек знае C++ и спазва някои елементарни принципи на работа, няма да допуска грешките за които Жаба парадира че липсата й при нея е предимство.

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_
Отговор
в отговор на G.Kreisel #89

Re: Сериозно?

Е то хората са измислили конвенция за * и &, ама кой да чете, като може през просото.

Сигнатура!
Отговор
в отговор на Questor #90

Кажи и на нас тая конвенция, де

Аз по принцип гледам ако нещо е изход да го предавам по адрес, било то и вход. Освен това имам навика да слагам const модификатори навред, дорде някой не докаже че не е const. Иначе доста конвенции съм чувал, ама тая съм я пропуснал.

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_
Отговор
в отговор на Kaндидaт Джaбap #91

Re: Защо Java

аз си пиша десктоп приложение и само миналата седмица милион и четиристотин хиляди души са си го инсталирали. Така че не е само ентърпрайз.

Отговор
в отговор на purist #92

Re: Защо Java

Мдам, доста добре се справяте, гледам 7-мо място в доунлоад.ком, което е доста добре:

[линк]

Явно сте много добри щом толкова малко хора успявате да направите такова нещо за десктоп на Джава. Тука спор няма. Спорът може да е дали заради Джавата се справяте толкова добре, или въпреки нея.

--
Sometimes the sole purpose of your life is to serve as a warning to others.
Отговор
в отговор на Гypy #93

Тва да не е някаква тайна?

На 7-ма позиция виждам Lime. А Google нищо не намира из Българското пространство по въпроса. Кажете нещо повече, че ми е интересно.

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_
Отговор
в отговор на Colombino #94

Re: Кажи и на нас тая конвенция, де

Май нещо такова беше

'конкретен тип':
X x или const X &x (X &x ако е out)

интерфейс
I *interface (+ възможните const варианти)

вграден масив (holly shit)
A *array, size_t size (+ възможните const варианти)

т.е. указател се използва само при интерфейсите (единственият адекватен случай) и вградените масиви (evil в С++)

Отговор
в отговор на Гypy #95

Re: Защо Java

Без хапсолютно никакви лични нападки към пурист - аз го дръпнах и се опитах да го ползвам, но много бързо го изтрих. Сега съм с е-магарето, което е много по-удобно. Не го казвам, за да се заяждам, просто се чудя на какво се дължи успеха на една доста неудобна програма

---
Priatelite.net
Uslugite.net
Отговор
в отговор на Paдo #96

Re: Кажи и на нас тая конвенция, де

Кво е "вграден масив"?

Отговор
в отговор на voyager #97

Re: Защо Java

Ето я поредната бройка в статистиката за седмицата...

Отговор
в отговор на Дeшeв #98

Re: Това е несериозно

Подобно нещо правим и в жабата с интерфейси и анонимни класове (нещо като беден роднина ).

Но все пак комбинацията от деструктори и шаблони в C++ е незаменима в сравнение с try-finally в Java.

В последно време си играя с ламбда функциите в С++. Не знам за какво мога да ги ползвам още (особено пишейки главно на жаба), но са доста интересни.

Не знам доколко С# подобрява нещата, не го познавам, дано да е стъпка напред в сравнение с жабата.

Отговор
в отговор на Pekoнcтpykтop #99

Re: Кажи и на нас тая конвенция, де

Нормалните С масиви. Има се предвид, че в С++ има различни и по-адекватни колекции, но те са част от библиотеката, не са built-in в езика.

Отговор
в отговор на Paдo #100

Re: Кажи и на нас тая конвенция, де

Ясно. Това "вградени масиви" не звучи нормално, предлагам ти да не го използваш повече.

Отговор