argon bulletin board

Експертно търсене  

Новини:

Регистрирането на нови потребители е временно деактивирано.

Автор Тема: Защо да не пишем на Win32API / MFC !  (Прочетена 13275 пъти)

NeshtoSeSluchi

  • Неактивен Неактивен
  • Публикации: 209
Re: Защо да не пишем на Win32API / MFC !
« Отговор #20 -: 18.08.2007, 23:26:49 »

NeshtoSeSluchi,

Ако C/C++ програмистите не бяха толкова безнадеждно затънали в праисторията ТИ нямаше да се радваш на езици от по-високо ниво, в които да не ти се налага да мислиш за синоними, отделяне на памет и т.н.

Прояви малко уважение към хората, които са допринесли за ТВОЕТО улеснение на живота!


Първо никъде не съм казал че C/C++ трябва да се премахнат или че не са имали и още имат своето приложение. Просто смятам, че отдавна е трябвало да им се направи солиден рефакторинг. Силата на C/C++ е в това, че са на ниско ниво. Да не би да твърдите, че силата им е в това, че типовете имат по 20 имена и че имената са криптирани? И тука идва въпроса защо аз да трябва да дефинирам опаковките на методите? Номера на дългите имена е да не се налага да ги декриптираш. Аз ако ще издирвам така или иначе какво значи криптираното име на функция от която са премахнати всички гласни сигурно ще мога и да си го ползвам.

И ако вие не правите разлика между BEGIN/END и {/} аз правя. Визуално също се възприема по-трудно защото не е симетрично. Това важи и за още доста други неща в Pascal дето са недомислени или са направени по-описателни защото това е език за ОБУЧЕНИЕ. Може да е най-добрия език за обучение и какво от това? Може би знаете защо в C присвояването е с = а сравнението с ==. Аз все пак да кажа. Седнали хората и преброили в средностатистическа програма колко присвоявания има и колко сравнения и естествено стигнали до извода, че присвояването се среща много по-често от сравнението и в следствие на това му дали по-краткия и прост запис. Е в Pascal защо не направиха така. Каква е мотивацията нещата да са на криво. Има много такива малки примери. Да знам, че може да се пише на Pascal. Да знам, че се свиква. И как точно това, че с нещо развалено се свиква го прави по-добро? Знам, че може да научиш всичките криптирани неща като strcmp и какво от това? Да не е хубаво? Или сте на принципа "Защо трябва да ми е лесно като може да ми е трудно". Или другата логика, че сегашните програмисти така и така били назубрили криптираните имена значи и следващите да страдат, няма да им оправим библиотеките.

Еми за това ще умират тези езици. Как е възможно 2 години да се боря със C++ в университета и да седна на Java и с 2 часа стаж да мога да направя повече неща отколкото на C++? После защо се пишело на модерните езици. Защото сядаш и почваш да пишеш, а не четеш първо цялата документация на библиотеките.

P.S. би трябвало да е 32 бита инта. Поне на Visual Studio беше толкова, но имам спомени, че зависи от компилатора, което също е безумна глупост.

P.P.S. Защо ми се струва, че не са толкова много тези фирми дето пишат на Delphi и намаляват с всяка изминала година. При това пак повтарям - въпреки, че нямам опит с Delphi съм убеден, че е добър език (все пак половината му концепции са пренесени в C#). Просто смятам, че си отива. Особено след като дори създателя му се занимава с друго... с какво ли.
Активен
Форум на свободата в ПУ: http://smfc.xaxa.eu

Templar

  • Неактивен Неактивен
  • Публикации: 460
  • Warrior of Faith
Re: Защо да не пишем на Win32API / MFC !
« Отговор #21 -: 19.08.2007, 00:07:37 »

Хайде тогава като поработиш с повече компилатори освен VS да разбереш защо. Наистина зависи от компилатора. А това че е глупост си е твое мнение. Все пак при 64-битова архитектура регистъра на процесора е по-голям и за това не виждам нищо лошо да се използва целия, защото поне за мен този процесор е направен за изчизления на наистина големи стойности.

Друг съвет от моя страна е да направиш справка каква е разликата между криптиране и съкращение. Защото strcmp е съкращение на string compare, което не е толкова далеч от ума както и etc., FWW, SWW и пр. в английския език. Тогава дай да се оплакваме, че трябва да "декриптираме" дори съкращения като 10х във форума и чата. А за криптирането ето така ти изглежда криптирано string compare -> $1$uo596$cYQNVZgQvr.iiMF5XQP8G1

За симетрията в Паскал зависи от това как си структурираш кода, както и в който и да е ЕП. Лично на мен също не ми допада := но това са бели кахъри. На Паскал е много добре направена структурираността на езика. Променливите се дефинират в началото, което е доста подредено.
Активен
Гледна точка към света: За миналото->оптимист. За бъдещето->реалист. С клиент над главата->песимист.
<===>
Templar Of Steel
Поздрави от
         The Bash Master Club

NeshtoSeSluchi

  • Неактивен Неактивен
  • Публикации: 209
Re: Защо да не пишем на Win32API / MFC !
« Отговор #22 -: 19.08.2007, 01:09:01 »

Друг съвет от моя страна е да направиш справка каква е разликата между криптиране и съкращение.

А моя съвет е да направиш справка какво е ирония.

Ако можеш да ми обясниш защо трябва да се менят размерите на типовете според архитектурата и как примерно в .NET може да не се менят ще съм ти много благодарен. Аз не съм против да има различни по размер типове и във всеки език ги има и в самия C е предвиден синтаксис за въпросното. Само не разбирам защо трябва да му се мени семантиката като се мени архитектурата. Кода или е предвиден да смята 64 битови числа или не е. Не може така да подменяш значението на кода и това с какви данни ще може да работи програмата. Ако ти трябва 64bit int си го слагаш 64bit дори и на 32 bit машина.

Сравнението на имената на хиляди функции и типове в стандартните библиотеки на C/C++ със стотината съкращения в чата е толкова абсурдно, че не смятам да го коментирам.

Както и да си подреждаш кода BEGIN и END няма да станат симетрични. Не знам колко е удобно да се декларират променливите в началото на блока за програмиста, но от опит знам, че е голямо улеснение за пишещия компилатора, така че почвам да изпитвам съмнения кой е трябвало да бъде улеснен. В крайна сметка ако беше толкова улеснено във всички конвенции за писане на C-style езици щеше да пише да се декларират променливите в началото на блока.

В заключение: Тези истории колко приятно, красиво и лесно било да се пише на C/C++ и прочие умиращи езици ще ги пробутвате на някой първокурсник дето не им е сърбал попарата или никога не е виждал модерен, изпипан език от високо ниво.
Активен
Форум на свободата в ПУ: http://smfc.xaxa.eu

Templar

  • Неактивен Неактивен
  • Публикации: 460
  • Warrior of Faith
Re: Защо да не пишем на Win32API / MFC !
« Отговор #23 -: 19.08.2007, 01:31:49 »

Ами да. Какво има да му коментираш на съкращенията. Поради същата причина поради която на човек му е по лесно да напиша 10х предпочита да напише и по-кратко име на фунция.

Пич, иронията ти е направо смешна в тоя случай особено с това да сравняваш ЕП като С/С++/Паскал с умиращи ЕП. До сега не даде един нормален и адекватен довод защо да не се използват тези езици. В случая си като потребител работещ на Р2 с WinXP, който се оплаква че тъпия Windows бил скапан защото не работи на машината му.

А това за компилаторите... Ами ако по-добре тогава питай MS защо като имат Windows за 32 битови машини си загубиха времето да правят такъв и за 64. Моя отговор на този въпрос е, защото когато искам софтуера ми да ползва пълния регистър на процесора не мисля да си променям кода, а просто да компилирам за съответната архитектура.

Относно това за дефинирането на променливите. Ами незнам на кой му е по-лесно, но при код над 20000 реда много по-ясно е когато глобалните променливи са дефинирани в началото, а локалните в началото на всеки блок. Така хем по-лесно се чете кода, хем е по-ясно.
Активен
Гледна точка към света: За миналото->оптимист. За бъдещето->реалист. С клиент над главата->песимист.
<===>
Templar Of Steel
Поздрави от
         The Bash Master Club

NeshtoSeSluchi

  • Неактивен Неактивен
  • Публикации: 209
Re: Защо да не пишем на Win32API / MFC !
« Отговор #24 -: 19.08.2007, 02:08:39 »

Ами да. Какво има да му коментираш на съкращенията. Поради същата причина поради която на човек му е по лесно да напиша 10х предпочита да напише и по-кратко име на фунция.

Оооо... да. Забравих, че intellisense-a е непознат в тези езици. Не помня кога последно съм писал повече от 3 букви от име на клас/метод. Имам актуална информация за теб. Кода вече не се пише в notepad. Дори доста често не се пише изобщо, а се генерира от tools и IDE.

Пич, иронията ти е направо смешна в тоя случай особено с това да сравняваш ЕП като С/С++/Паскал с умиращи ЕП. До сега не даде един нормален и адекватен довод защо да не се използват тези езици. В случая си като потребител работещ на Р2 с WinXP, който се оплаква че тъпия Windows бил скапан защото не работи на машината му.

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

А това за компилаторите... Ами ако по-добре тогава питай MS защо като имат Windows за 32 битови машини си загубиха времето да правят такъв и за 64. Моя отговор на този въпрос е, защото когато искам софтуера ми да ползва пълния регистър на процесора не мисля да си променям кода, а просто да компилирам за съответната архитектура.

Значи според теб те просто са си прекомпилирали кода на Windows с 64bit компилатор. Браво много си хитър.

Относно това за дефинирането на променливите. Ами незнам на кой му е по-лесно, но при код над 20000 реда много по-ясно е когато глобалните променливи са дефинирани в началото, а локалните в началото на всеки блок. Така хем по-лесно се чете кода, хем е по-ясно.

Как ли никой не се е сетил да го запише в някакви конвенции... Не само това ми си изсмукват от пръстите някакви неща като деклариране на променлива като първи statement на for. Колко неудобно...
« Последна редакция: 20.08.2007, 09:57:49 от NeshtoSeSluchi »
Активен
Форум на свободата в ПУ: http://smfc.xaxa.eu

Светослав Енков

  • Неактивен Неактивен
  • Публикации: 1864
    • Shark's Home Page
Re: Защо да не пишем на Win32API / MFC !
« Отговор #25 -: 19.08.2007, 10:29:49 »

[Еми за това ще умират тези езици. Как е възможно 2 години да се боря със C++ в университета и да седна на Java и с 2 часа стаж да мога да направя повече неща отколкото на C++? После защо се пишело на модерните езици. Защото сядаш и почваш да пишеш, а не четеш първо цялата документация на библиотеките.

Просто сядаш и какво пишеш? Отговори ми, де? Научил си бързо Джава, защото вече си знаел С++, нали? Ако Джава беше толкоз лесна и продуктивна, нямаше постоянно да търсят нови и нови хора, нямаше да има текучество, нямаше да има 1000 версии на библиотеки и среди, нали? Паскал и С++ забавиха развитието си не защото са отживелица, а защото се натрупаха библиотеки, среди и специалисти за тях! Ама повече за ЕП не споря, това е ясно - един харесва блондинки, друг брюнетки, трети негърки. За целта, за която ги харесваме, всички вършат работа, нали?

Цитат
Оооо... да. Забравих, че intellisense-a е непознат в тези езици. Не помня кога последно съм писал повече от 3 букви от име на клас/метод. Имам актуална информация за теб. Кода вече не се пише в notepad. Дори доста често не се пише изобщо, а се генерира от tools и IDE

Ти просто генерално бъркаш IDE с ЕП! Няма какво да коментирам повече.  Очевидно не си пипал Делфи 2007 - неговото IDE и tools са 1:1 с всички съвременни среди, а езика вече е само условно Паскал - има нововъведения в синтаксиса, подобни на Джава и С#. И фирмите, пишещи на Делфи не намаляват, а се разширяват като екипи и доходност. Единственото помпене на Джава идва от западните фирми, за които се прави outsourcing в България. А ако си чел моя преден пост, избора на Джава от тези фирми е продиктуван от по-комерсиални съображения, не от тва дали езичето е по-удобничко или с по-добър синтаксис, а от многоплатформеността, преносимостта и донякъде евтините среди за него.

А генералното ти схващане, че BEGIN END ти пречи да ползваш Паскал/Делфи, или че := било адски по-голямо от =, както и че = и == били сложени за удобство - е просто твое предположение. Проумей, че ние не те караме да пишеш на Делфи или С++ - ти ще си пропишеш и ще го благославяш, ако ти се наложи, а просто искаме да не плюеш така злобно и да не си изсмукващ доводи защо си се отказал от тях - ми отказал си се и толкоз - имало е причини, но те касаят теб в определен, фиксиран момент от твоето развитие и кариера. Помисли малко и не бъди толкова емоционален! Аз някъде да псувам Джава? Знаеш ли колко неща не ми харесват в нея? Писал съм и на Джава и на С++, вкл с MFC. Писал съм и на Асемблер доста неща. Прочети пак за поръчването и плащането на музиката... И защо ли моето CV е така голямо и съм търсен? Аз не знам....

Нека да спрем темата, защото тя беше ЗАЩО НЕ MFC/WIN32API, а не Паскал с/у Джава с/у C++ - м/у другото Майкрософт си бяха сложили в Java VM и Win32 API, но SUN се разписка и го махнаха, уж заради многоплатформеността.

Edit: И защо ли джаварите не спят нощем, а делфиеца (аз) си спинкам сладко и не поствам посред нощ?  :evil:

Edit2: Съвременните програмни системи изобщо не са само код - той е 15-20% максимум, другото е правилна концепция, проучване, проектиране на интерфейса и базата данни, организиране на поддръжка и обновяване, обучение на потребителите и още 1000 неща, касаещи ИЗПОЛЗВАНЕТО на програмата, не програмирането и (защото клиента плаща, за да я използва, не да си гледа и любува на красивия и изчистен код на Java). При това положение, кода е най-маловажната на практика част от системата (исках да кажа избора на език и процеса на кодиране) и затова има все още системи на Делфи, MFC, Visual Basic и така нататък.

Edit3: Да, на Джава по-лесно се стартират проектите, но се завършват еднакво трудно с тези на С++/Делфи. Ентропията е същата и проблемите с клиента и заданието са същите!
« Последна редакция: 19.08.2007, 12:10:46 от Светослав Енков »
Активен

Ирина Марудина

  • Неактивен Неактивен
  • Публикации: 4
    • Irina's Weblog
Re: Защо да не пишем на Win32API / MFC !
« Отговор #26 -: 19.08.2007, 13:07:12 »

Еми за това ще умират тези езици. Как е възможно 2 години да се боря със C++ в университета и да седна на Java и с 2 часа стаж да мога да направя повече неща отколкото на C++? После защо се пишело на модерните езици. Защото сядаш и почваш да пишеш, а не четеш първо цялата документация на библиотеките.

Ще ме извиняваш, но това изказване е все едно да кажеш : "Вече знам как да водя диалог на френски и мисля да напиша роман"... Едно е да можеш да четеш и да пишеш, съвсем друго - да пишеш правилно и красиво на даден език. За първото се иска да научиш синтаксиса и основните конструкции, за второто - да научиш идиомите при писането на този език!

И няколко думи за Java. В JDK 1.5 бе въведена поддръжка на Unicode 4.0 - обаче в Java типът char е фиксиран на 16 бита - не е зависим от платформата както е в C++. Но тези 16 бита вече не са достатъчни за представяне на всеки символ от новата, още по-голяма кодова таблица. За това един символ вече се представя или чрез един, или чрез два char-a! Освен това ако мислиш, че един Java програмист не трябва да мисли за менажирането на паметта, жестоко се лъжеш! Тук може да не се налага да освобождаваш на ръка заделената памет, но е повече от добра практика да нулираш всяка вече ненужна референция само и само тя да бъде затрита и паметта - върната в pool-а за повторна употреба. И Java програмите страдат от memmory leaks - заради лош стил на писане. Друго - поради наличието на автоматично освобождаване на паметта, нямаме деструктори и сме лишени като програмисти да се възползваме от наличието на специална кукичка в обекта, където да закачим кода за освобождаване на ресурси, заето от обекта при създаването му. От тук идва и необходимостта всеки, който ползва обект, заделящ ресурси, да се грижи за тяхното освобождаване в своя код, вместо това да става автоматично както е при наличие на деструктор.

Според мен най-големия плюс на Java са предоставяните с нея библиотеки, които са пълни много полезни помощни класове и са доста по-богати от STL-а на С++. Но Boost библиотеката на C++ като гледам изравнява позициите и в това отношение.

Т.е. на какъвто и език да пишеш, ако искаш да си добър, ще трябва да инвестираш време в четене и учене!
Активен

NeshtoSeSluchi

  • Неактивен Неактивен
  • Публикации: 209
Re: Защо да не пишем на Win32API / MFC !
« Отговор #27 -: 19.08.2007, 14:49:32 »

[Еми за това ще умират тези езици. Как е възможно 2 години да се боря със C++ в университета и да седна на Java и с 2 часа стаж да мога да направя повече неща отколкото на C++? После защо се пишело на модерните езици. Защото сядаш и почваш да пишеш, а не четеш първо цялата документация на библиотеките.

Просто сядаш и какво пишеш? Отговори ми, де? Научил си бързо Джава, защото вече си знаел С++, нали? Ако Джава беше толкоз лесна и продуктивна, нямаше постоянно да търсят нови и нови хора, нямаше да има текучество, нямаше да има 1000 версии на библиотеки и среди, нали? Паскал и С++ забавиха развитието си не защото са отживелица, а защото се натрупаха библиотеки, среди и специалисти за тях! Ама повече за ЕП не споря, това е ясно - един харесва блондинки, друг брюнетки, трети негърки. За целта, за която ги харесваме, всички вършат работа, нали?

Сядам и написвам повече отколкото на C++. Не твърдя, че съм знаел или знам нито Java нито C++. Да C-style синтаксиса, който съм научил от C++ не съм го учил отново за Java, но все пак остава факта, че след два часа можех да напиша много повече на Java. Говорим за GUI, string manipulation и всякакви такива упражнения. Дори мрежи. Аз за разлика от автора на темата защитавам да се започне обучението със C++ защото в Java/.NET има много неща които са скрити от програмиста (За добро), но е силно препоръчително да не кажа задължително да знаеш какво става зад завесите, а би било много трудно да се разбере какво става без C/C++ основи.

Нещо не разбрах логиката за Pascal. Използва се все по-малко, защото има много библиотеки и специалисти? Да не би всичкия възможен софтуер на Pascal да е написан?

Ти просто генерално бъркаш IDE с ЕП! Няма какво да коментирам повече.  Очевидно не си пипал Делфи 2007 - неговото IDE и tools са 1:1 с всички съвременни среди, а езика вече е само условно Паскал - има нововъведения в синтаксиса, подобни на Джава и С#. И фирмите, пишещи на Делфи не намаляват, а се разширяват като екипи и доходност. Единственото помпене на Джава идва от западните фирми, за които се прави outsourcing в България. А ако си чел моя преден пост, избора на Джава от тези фирми е продиктуван от по-комерсиални съображения, не от тва дали езичето е по-удобничко или с по-добър синтаксис, а от многоплатформеността, преносимостта и донякъде евтините среди за него.

Съвсем не. Но си абсолютно прав, че го използвах в този смисъл, а и не можеш да отречеш, че функционалността на IDE-то зависи до голяма степен от платформата и ЕП. Например свободния синтаксис на C не позволява на IDE-то и компилатора да разпознаят конкретно много грешки и често се случва да ги покажат например 30 реда по-надолу. Също много полезно нещо за IDE-тата което е една от основните причини в Java и .NET да има такъв брутален intellisense е рефлективността.

Относно пишещите Delphi - те намаляват като процент. Дори в България, а по света още повече. Разбира се на всички ни е ясно, че за всички има хляб и глада за програмисти в българия е доста сериозен, но това, че има свободни места за Delphi програмисти не значи, че езика става по-силен. И накрая както сам каза Delphi е заминало доста далеч от Pascal. Ако забележиш никъде не съм казал, че Delphi е лош език (аз и за C/C++ не съм го казвал, но там мощно оплюх библиотеките).

А генералното ти схващане, че BEGIN END ти пречи да ползваш Паскал/Делфи, или че := било адски по-голямо от =, както и че = и == били сложени за удобство - е просто твое предположение. Проумей, че ние не те караме да пишеш на Делфи или С++ - ти ще си пропишеш и ще го благославяш, ако ти се наложи, а просто искаме да не плюеш така злобно и да не си изсмукващ доводи защо си се отказал от тях - ми отказал си се и толкоз - имало е причини, но те касаят теб в определен, фиксиран момент от твоето развитие и кариера. Помисли малко и не бъди толкова емоционален! Аз някъде да псувам Джава? Знаеш ли колко неща не ми харесват в нея? Писал съм и на Джава и на С++, вкл с MFC. Писал съм и на Асемблер доста неща. Прочети пак за поръчването и плащането на музиката... И защо ли моето CV е така голямо и съм търсен? Аз не знам....

Не съм казал, че се умира от писане на BEGIN/END. Казах че е по-неудобно от {/} и продължавам да го твърдя. Вие тука не ме убеждавате, че е по-неудобно, а просто, че не било чак толкова зле. Хубаво не е толкова зле. Питахте ме какво имам против Pascal синтаксиса и си казах. Може да са много малки и нищожни забележки, но на мен ми стигат да прескоча този език докато още има C-style езици.

Edit: И защо ли джаварите не спят нощем, а делфиеца (аз) си спинкам сладко и не поствам посред нощ?  :evil:

Защото не играеш StarCraft в 3 през нощта? И не ме обиждай на Javar, аз съм от тъмната страна:)

Edit2: Съвременните програмни системи изобщо не са само код - той е 15-20% максимум, другото е правилна концепция, проучване, проектиране на интерфейса и базата данни, организиране на поддръжка и обновяване, обучение на потребителите и още 1000 неща, касаещи ИЗПОЛЗВАНЕТО на програмата, не програмирането и (защото клиента плаща, за да я използва, не да си гледа и любува на красивия и изчистен код на Java). При това положение, кода е най-маловажната на практика част от системата (исках да кажа избора на език и процеса на кодиране) и затова има все още системи на Делфи, MFC, Visual Basic и така нататък.

И понеже е малка част от всичкото можем да си позволим да не е най-удобното? Айде опитай да ми дадеш един аргумент за използване на Delphi вместо .NET, различен от "С това имаме опит", "Проекта е legacy на Delphi" или "За Delphi има <постави мега специфичен компонент тук>" (последното не важи защото наистина трябва да е мега специфичен и в крайна сметка и .NET си има мега специфични компоненти)

Edit3: Да, на Джава по-лесно се стартират проектите, но се завършват еднакво трудно с тези на С++/Делфи. Ентропията е същата и проблемите с клиента и заданието са същите!

Тука трябва да се намеси Тасков, дето заплашва хората с код на C++.


Еми за това ще умират тези езици. Как е възможно 2 години да се боря със C++ в университета и да седна на Java и с 2 часа стаж да мога да направя повече неща отколкото на C++? После защо се пишело на модерните езици. Защото сядаш и почваш да пишеш, а не четеш първо цялата документация на библиотеките.

Ще ме извиняваш, но това изказване е все едно да кажеш : "Вече знам как да водя диалог на френски и мисля да напиша роман"... Едно е да можеш да четеш и да пишеш, съвсем друго - да пишеш правилно и красиво на даден език. За първото се иска да научиш синтаксиса и основните конструкции, за второто - да научиш идиомите при писането на този език!

Да съм казал, че съм станал великия Java програмист. Казах, че въпреки повечето страдание със C++ не мога и диалог да водя дори.

И няколко думи за Java. В JDK 1.5 бе въведена поддръжка на Unicode 4.0 - обаче в Java типът char е фиксиран на 16 бита - не е зависим от платформата както е в C++. Но тези 16 бита вече не са достатъчни за представяне на всеки символ от новата, още по-голяма кодова таблица. За това един символ вече се представя или чрез един, или чрез два char-a! Освен това ако мислиш, че един Java програмист не трябва да мисли за менажирането на паметта, жестоко се лъжеш! Тук може да не се налага да освобождаваш на ръка заделената памет, но е повече от добра практика да нулираш всяка вече ненужна референция само и само тя да бъде затрита и паметта - върната в pool-а за повторна употреба. И Java програмите страдат от memmory leaks - заради лош стил на писане. Друго - поради наличието на автоматично освобождаване на паметта, нямаме деструктори и сме лишени като програмисти да се възползваме от наличието на специална кукичка в обекта, където да закачим кода за освобождаване на ресурси, заето от обекта при създаването му. От тук идва и необходимостта всеки, който ползва обект, заделящ ресурси, да се грижи за тяхното освобождаване в своя код, вместо това да става автоматично както е при наличие на деструктор.

Някъде горе съм написал, че не съм първи курс, но явно си го пропуснала. Това с null-ването на променливите са легенди като онези според които за:

String a = "a";
String c = "c";
String e = "e";

String x = a + "b" + c + "d" + e + "f";

трябвало задължително да се замени последния ред със StringBuilder иначе щял да свърши светът. Да представи си знам, че може да leak-ваш памет през unmanaged ресурси. Само дето да напишеш лоша програма на Java е към 100 пъти по-трудно отколкото да напишеш лоша програма на C++. Колкото до деструктурите... В Java няма ли finalizers? Знам, че не е същото, но доста прилича и практически върши същата работа. В C# има, ако в Java няма - лошо, но пък си струва мъката заради другите предимства пред C/C++.

Според мен най-големия плюс на Java са предоставяните с нея библиотеки, които са пълни много полезни помощни класове и са доста по-богати от STL-а на С++. Но Boost библиотеката на C++ като гледам изравнява позициите и в това отношение.

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

Т.е. на какъвто и език да пишеш, ако искаш да си добър, ще трябва да инвестираш време в четене и учене!

Ау добре, че ни каза. Тука всички си мислехме, че от днес за утре се става добър програмист.
« Последна редакция: 19.08.2007, 15:52:20 от NeshtoSeSluchi »
Активен
Форум на свободата в ПУ: http://smfc.xaxa.eu

Светослав Енков

  • Неактивен Неактивен
  • Публикации: 1864
    • Shark's Home Page
Re: Защо да не пишем на Win32API / MFC !
« Отговор #28 -: 19.08.2007, 15:21:02 »

Източник: Cay Horstmann’s Home Page, единият от авторите на Core Java. (http://horstmann.com/) (копирано от блога на Ирина Марудина)

The March of Progress

1980: C
    printf("%10.2f", x);

1988: C++
    cout < < setw(10) << setprecision(2) << showpoint << x;

1996: Java
    java.text.NumberFormat formatter = java.text.NumberFormat.getNumberInstance();
    formatter.setMinimumFractionDigits(2); formatter.setMaximumFractionDigits(2);
    String s = formatter.format(x); for (int i = s.length(); i < 10; i++) System.out.print(' ');
    System.out.print(s);

2004: Java
    System.out.printf("%10.2f", x);


Цитат
Само дето да напишеш лоша програма на Java е към 100 пъти по-трудно отколкото да напишеш лоша програма на C++.
Това ме утрепа! Еднакво лесно си е да напишеш бъгава програма! Незнанието не прощава еднакво...
« Последна редакция: 19.08.2007, 15:43:29 от Светослав Енков »
Активен

NeshtoSeSluchi

  • Неактивен Неактивен
  • Публикации: 209
Re: Защо да не пишем на Win32API / MFC !
« Отговор #29 -: 19.08.2007, 16:28:35 »

Абсолютно не мога да се съглася, че е еднакво лесно. Все едно да твърдиш, че вероятността да допуснеш грешка като пишеш код и като ползваш Wizard който да го генерира е една и съща. Да не говорим за такива неща като асемблер.
Активен
Форум на свободата в ПУ: http://smfc.xaxa.eu

Светослав Енков

  • Неактивен Неактивен
  • Публикации: 1864
    • Shark's Home Page
Re: Защо да не пишем на Win32API / MFC !
« Отговор #30 -: 19.08.2007, 16:35:15 »

За жалост можеш да се съгласиш, говорехме за писане на код на Джава и код на С++, т.е. ръчно писане, на дълъг и сложен код.

И в С++ има Wizards. Изобщо никой не визира това. Ти просто не падаш по гръб и това е, ама за съжаление не си коте!

Я уточни кое Java IDE визираш с тия супер мощни wizards и визуални методи за програмиране, че ми стана интересно как сравняваш сорт ябълки със сорт банани? Говорехме за ЕП (Език за програмиране) и допускане на грешка при писане на код, не за генератори на код, нали? И тези грешки са 90% семантични в логиката на алгоритъма, не в синтаксиса! Или в Java няма цикли, няма объркване, всичко е песен? И кода, за който говоря, е цяло приложение - с интерфейса, с базата данни, с хелпа, всичко!

Е, аз се занимавам с програмиране само от 1982 и имам още мноооого да се уча и съм само някакъв мижав главен асистент по Информатика, макар и да съм сменил 10 позиции във фирми, където съм работил в големи екипи по големи проекти - на Асемблер, Паскал за ДОС, ASP, Делфи, С++, С, Perl... Ама както се оказва, съм изпуснал нещо, а?

Какво нещо е асемблера? Писал ли си на Асемблер нещо сериозно, щото аз съм писал хиляди редове ОС за Правец-82 на Асемблер. И работеше. Просто си правиш нужния подход, организираш си нещата, проектираш си ги и става също толкоз надежден код, колкото би бил на Джава. Писачът на код определя ентропията и нивото на грешките, не ЕП.
« Последна редакция: 19.08.2007, 17:00:23 от Светослав Енков »
Активен

Ирина Марудина

  • Неактивен Неактивен
  • Публикации: 4
    • Irina's Weblog
Re: Защо да не пишем на Win32API / MFC !
« Отговор #31 -: 19.08.2007, 17:08:31 »

Някъде горе съм написал, че не съм първи курс, но явно си го пропуснала. Това с null-ването на променливите са легенди като онези според които за:

String a = "a";
String c = "c";
String e = "e";

String x = a + "b" + c + "d" + e + "f";

трябвало задължително да се замени последния ред със StringBuilder иначе щял да свърши светът.
Погледни Java Language Specification, 15.18.1.2 Optimization of String Concatenation:
Цитат
To increase the performance of repeated string concatenation, a Java compiler may use the StringBuffer class or a similar technique to reduce the number of intermediate String objects that are created by evaluation of an expression.
Ключовата думичка е "may". Mожеш ли да разчиташ, че тази оптимизация я има в твоя компилатор, или е редно да провериш генерирания байт код преди да смяташ, че този товар ти е свален от плещите? Не помня в коя версия на Sun-ския го въведоха, но съм сигурна, че тази оптимизация е въведена не толкова отдавна. Ето ти една връзка : "Tiger - string concatenation". Ще съм много щастлива ако ми докажеш, че конкатенирането с оператор + в цикъл не създава нов StringBuffer на всяка итерация! Пример - имам цикъл, в който правя { str += "a"; str += b; }. След това дизасемблирам генерирания байткод и се оказва, че за всяка итерация се създават по два нови StringBuffer обекта - по един за всеки ред с конкатениране! (Ползвам JDK1.6.0_02)

Колкото до деструктурите... В Java няма ли finalizers? Знам, че не е същото но доста прилича и практически върши същата работа. В C# има, ако в Java няма - лошо, но пък си струва мъката заради другите предимства пред C/C++.
Върши същата работа? :) Първо, според Java Language Specification няма такова нещо като ред на викане на finalize() метод. Второ, никой не ти гарантира след колко време ще се викне - finalize() е част от Memory management системата, вика се ако има нужда от памет.

Т.е. може и изобщо да не се стигне до него преди приключване изпълнението на програмата. Не случайно съществува метод System.runFinalization(), в чиято API документация на  пише :
Цитат
Calling this method suggests that the Java Virtual Machine expend effort toward running the finalize methods of objects that have been found to be discarded but whose finalize  methods have not yet been run.

Ключовата дума е "suggest" - няма гаранция, че дори и да извикаш този метод,
finalizer-ите ще се извикат! Още ли твърдиш, че finalizer-ите вършат същата работа?

Активен

Templar

  • Неактивен Неактивен
  • Публикации: 460
  • Warrior of Faith
Re: Защо да не пишем на Win32API / MFC !
« Отговор #32 -: 19.08.2007, 17:08:56 »

Пич, ти правиш ли разлика между IDE и ЕП? Хайде обясни ми как така IDE-то зависи от ЕП-то на което е писано. Например Светослав Енков преди време ми беше показвал едно IDE правено на Делфи, което беше пък за програмиране на С/С++. Също така в Еклипса има плъгин, който ти позволява да програмираш на С/С++/РНР, а да те светна пък Еклипса е писан на Джава. Трябва да ми кажеш каква литература четеш, че да не се набутвам да си я взимам, след като в нея се твърди:
Цитат
Но си абсолютно прав, че го използвах в този смисъл, а и не можеш да отречеш, че функционалността на IDE-то зависи до голяма степен от платформата и ЕП.
Направо пренаписа цялата информатика с това :-D :-D :-D

Цитат
Например свободния синтаксис на C не позволява на IDE-то и компилатора да разпознаят конкретно много грешки и често се случва да ги покажат например 30 реда по-надолу.
А за това просто нямам коментар. Как така компилатора не познава много грешки заради синтаксиса. А и това, че вече не си първи курс говори много лошо за теб какво си научил до сега. А това за 30-те реда изобщо не го схванах. Значи и IDE-тата които ползвам за С/С++ ми показват в реално време къде имам синтактична грешка и то дори и със супер завидна точност спрямо твоето изказване. Освен това никой не те кара да ползваш ноутпад, за да програмираш.

Изобщо що не вземеш да запишеш при доц. Димов едни методи на транслация и да научиш как стоят нещата с компилаторите, вместо да си приказваш приказки на изуст. Тогава проекта ми беше за транслатор на Паскал, който после модифицирах и вършеше същата работа за С без значение от структурираността на кода. Изобщо методите за транслация при С, Джава, С#, Паскал са едни и същи. Разликата е единствено изходния код, на компилатора.

Цитат
Говорим за GUI, string manipulation и всякакви такива упражнения.
Че това се учи за 2 часа и на С. Не виждам какво постижение с и направил. А за GUI и аз много лесно ги правя с wizard-a. И ако ти се пишеш програмист с това, че си направил автоматично генериран код с няколко щракания на мишката, то за мен това дори не е програмиране. Изобщо ползвал си едно IDE и вече си мислиш, че знаеш всичко но не е така.

Цитат
Само дето да напишеш лоша програма на Java е към 100 пъти по-трудно отколкото да напишеш лоша програма на C++.
Хайде уточни се да напишеш или wizard-а да ти напише, понеже има голяма разлика. Аз лично не мисля, че съм писал шаблона, който въпросния wizard генерира, че да кажа, че аз съм го писал. И тогава можеш ли да ми кажеш какъв опит имаш като програмист. По скоро имаш опит като потребител на това IDE. Освен това възможните грешки в Джава и С++ са едни и същи ако не визираме memory leak-a. Но пък както казва Ирина Марудина
Цитат
Освен това ако мислиш, че един Java програмист не трябва да мисли за менажирането на паметта, жестоко се лъжеш! Тук може да не се налага да освобождаваш на ръка заделената памет, но е повече от добра практика да нулираш всяка вече ненужна референция само и само тя да бъде затрита и паметта - върната в pool-а за повторна употреба. И Java програмите страдат от memmory leaks - заради лош стил на писане.
Активен
Гледна точка към света: За миналото->оптимист. За бъдещето->реалист. С клиент над главата->песимист.
<===>
Templar Of Steel
Поздрави от
         The Bash Master Club

NeshtoSeSluchi

  • Неактивен Неактивен
  • Публикации: 209
Re: Защо да не пишем на Win32API / MFC !
« Отговор #33 -: 19.08.2007, 17:18:15 »

Всъщност визирах Visual Studio, но много от нещата в тези Wizard-и са възможни заради структурата на езика. Както вече уточних аз съм от .NET отбора. Например в C# има атрибути и reflection, които правят възможно наличието на толкова брутални Wizard-и.

Добре ще дам пример с код.

В Java не може да напишеш

int i;

if(i > 0)
...

В Java е много по-трудно да направиш memory leak.

В Java няма недефинирани неща.
Класическия пример от C за недефинираност е:
f() + g();
където не е сигурно кое ще се изпълни първо (това, че почти всеки компилатор ги кара под ред е съвсем отделна тема има и други примери където има разлики между различните компилатори)

В Java операциите със низове са много по-лесни и удобни(заради типа String който си е unicode).

В Java масивите имат размерност (истинска) и си имат .leght(), което прави пазенето от overflow много по-лесно.

В Java не можеш да напишеш:

if(5)
...

В Java няма множествено наследяване, което може да доведе до непредвидено поведение, hide/override на методи и прочие.

И така докато съм натрупал инерция да продължа със C#

В C# няма fall through в switch

switch(x)
{
 case 1: Neshto();
 case 2: DrugoNeshto();
}

няма да се компилира на C# защото няма break след всеки statement. Колко време в дебъгване е отишло на C/C++ програми за да разбера, че съм забравил break в switch...

В C# е забранено да се вика static метод от instance на класа.

В C# методите които се override се маркират изрично и override-вания и override-ващия, за да няма неразбрали и "override-нах без да искам".

Всичко това са неща, които пазят програмиста от грешки. Ти да не би да твърдиш, че ще напишеш програма X еднакво лесно на асемблер и на Delphi? И не говоря за набирането на кода...

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

... бла бла бла...

#define N 30;

... бла бла бла ... (30 реда код)

int someArray[N];

... бла бла бла ...

compile -> грешка на реда с декларацията на масива.
"missing ] before ;"
а сега де
Пуля се гледам точно пред ; има ] на посочения ред. След 15 мин преглътнах срама попитах и ми обясниха къде ми е грешката. Е как да се сетя, че грешката ми е 30 реда по-нагоре от посоченото и как да разбера, че за друга ] ставало въпрос. Много говоряща грешка няма що. Много могъщ компилатор. Много удобно за писане и оправяне на грешки. Убеден съм, че на C# или Java не може да се даде толкова фрапиращ пример. Всъщност съм виждал такива грешки дето едва ли не ми пишат как да си оправя ЛОГИЧЕСКА грешка в програмата.
Активен
Форум на свободата в ПУ: http://smfc.xaxa.eu

Светослав Енков

  • Неактивен Неактивен
  • Публикации: 1864
    • Shark's Home Page
Re: Защо да не пишем на Win32API / MFC !
« Отговор #34 -: 19.08.2007, 17:30:17 »

Еднакво лесно - кое визираш? Говорехме за еднакво безгрешно или еднакво грешно!

Този пример ти е за VC 6.0 IDE. В по-новите С++ IDE ще ти даде по-ясна грешка, а и ти даде изкуствен единичен пример, каквито има и на Джава, сигурен съм - Ирина ще ти намери.

Има още много срам да преглъщаш. Ама не бой се - така се става мъж, особено като махнаха казармата сега!

Пак ти казвам, че аз визирах реално правене на програми, не търсене на дефекти в ЕП и в конкретни IDE.

Активен

Ирина Марудина

  • Неактивен Неактивен
  • Публикации: 4
    • Irina's Weblog
Re: Защо да не пишем на Win32API / MFC !
« Отговор #35 -: 19.08.2007, 17:42:58 »

Погледни тази лекция от конференцията JavaOne 2007 : Java Puzzlers Episode VI: The Phantom-Reference Menace/Attack of the Clone/Revenge of the Shift - Joshua Bloch, Google, Inc.; William Pugh, Univ. of Maryland

Всеки от показаните случаи демонстрира неподозирани резултати, за които компилаторът не те предупреждава. Аз лично много се забавлявах с тези закачки ;)
Активен

NeshtoSeSluchi

  • Неактивен Неактивен
  • Публикации: 209
Re: Защо да не пишем на Win32API / MFC !
« Отговор #36 -: 19.08.2007, 17:58:32 »

Ключовата думичка е "may". Mожеш ли да разчиташ, че тази оптимизация я има в твоя компилатор, или е редно да провериш генерирания байт код преди да смяташ, че този товар ти е свален от плещите? Не помня в коя версия на Sun-ския го въведоха, но съм сигурна, че тази оптимизация е въведена не толкова отдавна. Ето ти една връзка : "Tiger - string concatenation". Ще съм много щастлива ако ми докажеш, че конкатенирането с оператор + в цикъл не създава нов StringBuffer на всяка итерация! Пример - имам цикъл, в който правя { str += "a"; str += b; }. След това дизасемблирам генерирания байткод и се оказва, че за всяка итерация се създават по два нови StringBuffer обекта - по един за всеки ред с конкатениране! (Ползвам JDK1.6.0_02)

Изобщо не споря за смисъла от StringBuilder/StringBuffer. Очевидно е, че в цикъл има смисъл. Също не споря, че едно време това наистина е било вярно, но тогава не съм знаел какво е това Java още. Ти вероятно също. Убеден съм, че от доста години compilers ще сложат SB вместо за +. И сега най-интересното. Понеже авторите на книги преписват без да разбират същата препоръка я дават масово и за C#. Интересното в случая е, че докато в Java писането на SB само ще зацапа кода и ще стане по-трудно четим, в C# въпросната "оптимизация" си е чисто и просто ВРЕДНА и ще забави програмата. (Това се дължи на overloads за string.Concat с параметър масив от string който ползва unmanaged код за да създаде точно 1 път string с нужната дължина)

Колкото до finalizers да не забравяме, че все пак цялата концепция за GC се върти около факта, че няма нужда да се освобождава памет преди да е свършила. Така, че реално finalizer-а е варианта на деструктор за managed език. Ресурсите ще се освободят когато потрябват, а какво ти пука дали това ще е на края на програмата? Както казах не мисля, че finalizer е същото като деструктор, но продължавам да твърдя, че ги заместват успешно.
Също така пак ще повторя, че нямам идея как работят finelizers в Java, но имам идея как работят в C#.
Ето така:
http://msdn2.microsoft.com/en-us/library/b1yfkh5e(VS.80).aspx
тука виждаме, че може да Dispose-ваме unmanaged ресурси когато си решим (има и удобен синтаксис с using за да не се обърка нещо във flow controla и да има някой случай в които забравим да викнем Dispose) отделен въпрос е, че managed ресурсите ще си останат да чакат GC, но не вярвам някой да твърди, че GC е лошо нещо.


На templar по случайност му отговорих докато отговарях на Енков. Така, че няма да се повтарям. Само да уточня, че тея неща дето се учат на C за 2 часа аз 2 години не можах да ги науча. За сметка на това на Java наистина ги научих за 2 часа. Освен това иди да прочетеш какво е reflection и мисля, че дори ти ще проумееш каква е връзката с IDE-тата. Никъде не съм твърдял, че има значение на какъв език е написано IDE-то само, че функциите му зависят от структурата на езика. Освен това както уточних още преди да го напишеш наистина използвах грешно ЕП и ти си ме цитирал с точно това признание, че съм сбъркал, тоест смятам показал съм, че знам каква е разликата, а ако мислиш, че IDE-то няма общо с платформата и езика явно си доста назад с това какво могат IDE-тата на езиците поддържащи reflection и не си виждал как в C# са сложени известен брой синтактични структури които са там само за да може IDE-то и компилатора да правят още магии.

Активен
Форум на свободата в ПУ: http://smfc.xaxa.eu

NeshtoSeSluchi

  • Неактивен Неактивен
  • Публикации: 209
Re: Защо да не пишем на Win32API / MFC !
« Отговор #37 -: 19.08.2007, 18:17:49 »

Еднакво лесно - кое визираш? Говорехме за еднакво безгрешно или еднакво грешно!

Този пример ти е за VC 6.0 IDE. В по-новите С++ IDE ще ти даде по-ясна грешка, а и ти даде изкуствен единичен пример, каквито има и на Джава, сигурен съм - Ирина ще ти намери.

Има още много срам да преглъщаш. Ама не бой се - така се става мъж, особено като махнаха казармата сега!

Пак ти казвам, че аз визирах реално правене на програми, не търсене на дефекти в ЕП и в конкретни IDE.



Примера е с VS 2005. Пък и си мислех, че си говорим точно за дефектите в ЕП

Колкото за така наречените непредвидими неща в Java:

1. Половината примери бяха с написани класове и методи които не са част от езика.
2. Дори да има неща които те изненадват например как работи % те изненадват само хора които не познават езика. Работата е там, че в Java(и в C#) всичко е ПРЕДВИДИМО (не говорим за racing при нишките разбира се).  Винаги се знае под какъв ред ще се изпълнят expressions, винаги се знае какъв ще е резултата от изпълнението.

А кажете какво ще изпише:

int asdf = 1;
cout << asdf++ + asdf++;

Да подскажа не можете да кажете, но аз мога да кажа какво ще изпише

int asdf = 1;
Console.WriteLine(asdf++ + asdf++);

Дори най-елементарното

int i;
count<<i;

Ето това е неопределеност не някакви си там гатанки със съвсем логично обяснение.

P.S. Ходил съм в казармата :)
« Последна редакция: 19.08.2007, 18:53:28 от NeshtoSeSluchi »
Активен
Форум на свободата в ПУ: http://smfc.xaxa.eu

TeeRexX

  • Неактивен Неактивен
  • Публикации: 739
  • изпратете ми анонимно пари в плик :)
    • www.myspace.com/teerexx
Re: Защо да не пишем на Win32API / MFC !
« Отговор #38 -: 19.08.2007, 19:04:50 »

Изобщо що не вземеш да запишеш при доц. Димов едни методи на транслация и да научиш как стоят нещата с компилаторите, вместо да си приказваш приказки на изуст. Тогава проекта ми беше за транслатор на Паскал, който после модифицирах и вършеше същата работа за С без значение от структурираността на кода. Изобщо методите за транслация при С, Джава, С#, Паскал са едни и същи. Разликата е единствено изходния код, на компилатора.
В интерес на истината ми се иска да кажа, че проекта на NeshtoSeSluchi по Методи на транслация беше един от най-добрите в нашия курс. Освен това доколкото знам той писа след това компилатор и за друг език.
Активен

Светослав Енков

  • Неактивен Неактивен
  • Публикации: 1864
    • Shark's Home Page
Re: Защо да не пишем на Win32API / MFC !
« Отговор #39 -: 19.08.2007, 19:05:10 »

@NeshtoSeSluchi   - Щом си ходил в казармата - добре! Няма да се тревожа за теб, знаеш какво е да те командват - ми подобно е в голям екип с тъп главен програмист или тийм лидър. За какво спорим тогава?

Ако и пиеш бира с мезе (може и без мезе) - давай да се видим някой път на форумна сбирка!  :beer:

За примерите - всички са измислени, разбира се че никой свестен програмист няма да напише asdf++ + asdf++ в израз  :-P то си е самоубийство, колкото и да ти е ясно според синтаксиса и дефиницията на езика, просто си е нечетливо и неразбираемо, в израз да ползваш var++ или ++var при наличие на други променливи в израза.

На Асемблер е много весело да се програмира SSE/MMX. Опитай да видиш какво е! Не го приемай като заяждане, просто ще се изкефиш...
« Последна редакция: 19.08.2007, 19:07:53 от Светослав Енков »
Активен