Lisp

Java-та в никакъв случай няма да измести c/c++. Все пак нали някой трябва да й пише виртуалната машина и ОС за виртуалната машина :)

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

Иначе идеята за garbage collector-а е добра, но е капан за калпави програмисти. Нали се сещаш - заделяш, заделяш, заделяш... Ама в един момент свършва :)

А май не се сещам за ресурси, които могат да се загубят и да не са свързани с оперативната памет.

Si Vis Pacem, Para Bellum

> Java-та в никакъв случай няма да измести c/c++.
> Все пак нали някой трябва да й пише виртуалната
> машина и ОС за виртуалната машина :)
На пръв поглед звучи така... Но все пак не бих се обзаложил за след 5 години :-) Освен това нямам пред мен спецификацията на Java байткода, но мисля че няма нужда от отделна ОС. По-скоро представлява интерпретатор на някакъв измислен от тах асемблер, като единия от опкодовете служи за мултиплексиране на системните функции (read/write/open/close/и.т.н). Все пак утре ще проверя как точно стоят нещата и ще пиша какво съм намерил.

> По принцип, колкото и да е сложна една
> програма, разклоненията в нея, които заделят
> ресурси не са чак толкова много (ако е грамотно
> написана). При едни нормални тестове загубите
> могат лесно да се установят.

> Иначе идеята за garbage collector-а е добра, но
> е капан за калпави програмисти. Нали се сещаш -
> заделяш, заделяш, заделяш... Ама в един момент
> свършва :)
Ами garbage collector-а помага при следните случаи:

int function (...) {
    ...
    if ((ptr1 = malloc (size1)) == NULL) {
        return (-1);
    }
    if ((ptr2 = malloc (size2)) == NULL) {
        free (ptr1);
        return (-1);
    }
    if ((ptr3 = malloc (size3)) == NULL) {
        free (ptr2);
        free (ptr1);
        return (-1);
    }
    if ((ptr4 = malloc (size4)) == NULL) {
        free (ptr3);
        free (ptr2);
        free (ptr1);
        return (-1);
    }
    ...
    free (ptr4);
    free (ptr3);
    free (ptr2);
    free (ptr1);
    return (0);
}

Особено ако се смесят заделянето на ресурси от няколко различни вида става доста объркано.

С GC функцията щеше да е нещо от типа на:

int function (...) {
    ...
    if ((ptr1 = malloc (size1)) == NULL) ||
        (ptr2 = malloc (size2)) == NULL) ||
        (ptr3 = malloc (size3)) == NULL) ||
        (ptr4 = malloc (size4)) == NULL)) {
            return (-1);
    }
    ...
    return (0);
}

Ако C имаше GC, щеше да пести време и при писане и при дебъгване. Жалко само че GC не е ефикасен механизъм, или поне аз не знам за начин да се направи ефикасен.

> А май не се сещам за ресурси, които могат да се
> загубят и да не са свързани с оперативната
> памет.
Ами сега се сещам за още един вид ресурси, които свършват - файлови дескриптори. Голям проблем е утечката на файлови дескриптори при сървърни програми. Т.е. правиш connect() или accept() на някой socket но забравяш да направиш след това close(). В повечето OS броя на дескрипторите е ограничен до някоя степен на 2 - 256, 1024, и.т.н.
В интерес на истината не знам някой език за програмиране да прави GC на файлови дескриптори, но би било добре :-)

Дааа. На втория фрагмент скобите не са балансирани, но идеята е ясна...

Честно казано, не разбрах съвсем добре къде е проблема в първия пример.

А иначе - какво са файловите дескриптори?:)

Si Vis Pacem, Para Bellum

:]

В полза на Lisp ще кажа следното. Програмиста изобщо не се занимава с управление на паметта и разни битове. Концентрира се изключително върху алгоритъма и организацията на данните (едно и също:). Поради това, може да се занимава исключително с напредничави задачи от искуствения интелект и математизирани проблеми, без да обръща внимание на конкретна, смислена и ефективна реализация. Критика: когато направи нещо, което си въобразява, че е ценно, не бива да моли byte-writer-ите да му направят продаваема система - иначе е просто един фантазьор и експлоатира добрите програмисти.
Стига да има кой да плаща на такъв програмист, докато той се забавлява, . . . дай боже!

В полза на C/C++ ще кажа следното. Хората програмиращи на тези езици, са най-вече супер техничари. Обикновенно ги експлоатират до дупка, и те толкова са се забъркали в byte-овете си, че не не се усещат какво става на около. Някои псевдо- от тях по принцип са си забъркани и само си въобразяват че програмират, а илюзията продължава, докато шефа разбере ситуацията (практиката, обаче, показва че шефа е забъркан, понеже винаги печели). Не че не им липсва гордост - напротив. Без тях нищо не може да стане. Не са признати, понеже не ги разбират. Иначе, заплатите не са лоши, и това е всичко за сега. Още повече, в C/C++ е истината.
Критика: едно време телевизионните техници бяха много уважавани, но в днешно време като ни се развали телевизора, просто го изхвърляме, и си купуваме нов.

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

Мутрите (и мекеретата) винаги печелят :] ([#!$%^@&*] off!!!)

Брей, сигурен ли си, че ще си изхвърлиш Сони-то за 2500 лв.? Ако е така - в коя държава живееш?

Si Vis Pacem, Para Bellum

Ne si programiral za Win16, zatova. Tam vsichki handle-i na obekti (prozorci, chetki, molivi, tva-onova) byaha 16-bitov int (t.e. 15-bitovo chislo). Dori i da imash mnogo RAM, svyrshat li vyzmojnite st-ti za handle-i (a 32767 nikak ne e mnogo!!! Stava duma ne samo za 1 proces, a za cyalata s-ma, kato razlichnite vidove obekti spodelyaha edno mn-vo ot handle-i!!!), umirash.
Da se pohvalya: vednyj napisah edna programa pod Win32 (i ne na maytap :-), koyato syzdavashe nyakolko hilyadi kvadratcheta (a be fish za Evrofutbol), vsyako s po 3 prozorcheta i po edno vreme kvo da vidya... Moyata programa + C++Builder-a hapvaha 97% ot resursite!!! Pamet imashe, ama samo malko po-slojen fish shteshe da sduha dori Win95. Za Win3x da ne govorim.

По принцип почти цялото управление на win се извършва посредством тези handles. В повечето случаи те са си чисти указатели (ама никой не знае за това:) Понякога са и дескриптори и индекси и кво ли не още, но със сигурност при създаване на win обекти задължително се заделя памет.
Иначе графичната машина на Win16 имаше една отвартителна гадна особеност - дори управлението на ресурсите да е било перфектно и всички създадени GDI обекти да са били Delete-нати, пак се губеше памет :(((( При работа с тежки графични приложения се налагаше редовен рестарт на win за да се възстановят загубите.
Във връзка с това имам един силен спомен от преди 2-3 години :)
През 98-ма, работейки за по-предишната си фирма, правех библиотека за векторна графика, ориентирана към създаване на документи. На практика единствените обекти с които си имах работа бяха масиви от прави (с всичките им атрибути, като някои бяха затворени полигони) и текстове (пак с всичките им атрибути). Технологията беше такава: рисуваш си нещо с CorelDraw (или какъвто и да е софтуер, стига да има експорт към .wmf). Следва експорт към metafile и обработката му с помощта на първия модул от библиотеката. После визуализацията в рамките на приложната програма, която има нужда от документи, ставаше посредством втория модул.
Та значи всички ние работехме с win9x, библиотечката беше създадена и успешно доведена до отлично работещо състояние под win9x. Всичко вървеше добре, докато един ден не дотича пребледнелият ми шеф, който заяви, че работата с документи под win3.1 води до "скапване на уиндоуса". Спешно беше организирано инсталиране на win3.1 и проверка на шефските твърдения. Какво да ти кажа - след няколко пречертавания на един сравнително прост документ GDI ресурсите бяха напълно погълнати :( Като го видях - дългата ми коса зае вертикално положение :) Наложи се да правя трети модул, който да извършва оптимизация и филтриране на matafile-a.

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

Si Vis Pacem, Para Bellum

Redaktirano ot MиГ-31 na 28.12.00 17:14.

Tova e dosta nevyrshesht-rabota garbage collector. To i pametta se osvobojdava pri zavyrshvane na procesa. Mi ako procesyt tryabva da raboti postoyanno? Edin primer da se "nakefish": Linux kernel 2.2.10 imashe memory leak. A kernelyt ne e dori proces :-) Izyajdashe 64 Mb za po-malko ot denonoshtie, i to na ne mnogo natovarena mashina. 2.2.11 go pusnaha sled 4 dni, ako ne byrkam, tykmo se byah zasilil da vryshtam 2.2.9 (tova za da ne zlobeesh mnogo :-)