C++ - brza pitanja iz objektno orij. programiranja

C++ je superset C-a, tj. jezik koji je nastao kao hibrid objektne i proceduralne teorije. Kompatibilan je s C-om, jer je u vrijeme nastanka to smatralo nužnim.

Prastar je i relativno težak početnicima. Pruža jako bitno znanje (po mom mišljenju), ali istovremeno ostavlja opasnost učenja loših praksi i koncepata, te je izrazito podložan bugovima (najviše s memorijom), jer je izrazito blag prema lošem programiranju da bi dopustio hackove i pružio moć na razini one koju očekuju C programeri.

Tko zna dobro programirati u C++u, u 99% slučajeva svaki drugi jezik neće naći problematičnim.

C# je moderan, čisti objektni jezik, sintaksom sličan C++u i jako, jako sličan Javi. Trenutno je (IMHO) najnapredniji široko rašireni programski jezik s podrškom za hrpu modernih patterna, koncepata i s ugrađenom hrpom rješenja koja drastično ubrzavaju razvoj, poput integriranog upitnog sustava (LINQ)(preko ekspresijskih stabala), lambda izraza, dinamičkih opcija, ugrađene podrške za paralelno računarstvo, parsiranje objektnih struktura, XML-a, i sl. i visokom integracijom u .NET framework.

Nauči C++ i nemaš zime.

C# je specifičniji od C++a i uvodi neke dodatne stvari koje ti u startu ne trebaju.

Kako je već netko napomenuo postoji i managed c++ kao c++/CLI programiranje u skolpu Net-a .
U njemu postoji odmah drug and drop ,naravno VS obvezatan,tako možeš sebi vizualno raditi kao i sa C#-om.
Recimo ispis C++/CLI u konzoli poznati Hello World izgleda :

Console::WriteLine("Hello World");

return 0;

AFAIK VCL nema dependecyje (posto su vecina komponenti u biti wrapperi WinApi funkcija) - bas u tome je prednost pred nekim drugim frameworkovima - recimo pred Visual Basicovim koji treba imati runtimeove i ActiveX kontrole. Po cemu je MFC mocan - ne bih znao. Onaj iz VS2005 karakterizira vrlo malen broj komponenti (a i ne znam bas nude li se besplatne kontrole na netu - za Delphi/C++ ima ih zaista velika kolicina), losa prilagodljivost (malen broj svojstava), malen broj evenata, nepotrebno komplicirano koristenje (toliko da se covjek pita zasto Visual C++ u nazivu nosi "Visual", a i MFC nije bas napravljen u duhu OOP-a). Da, MFC je bolje nego da rucno ides koristit WinApi, ali u odnosu na VCL je jadan. Ne znam - mozda tebi rijec "mocan" znaci nesto drugo od onoga sto znaci meni. S ostalim se slazem.

OOP se moze jako dobro nauciti i usavrsiti u razvoju VCL komponenti u Delphiju (nisam pokusao razvijati komponente u C++Builderu - valjda je na istu foru), jer te VCL prisiljava da koristis mnoge koncepte OOP-a. Pa bi ti eto to mozda moglo biti interesantno.

A sad - na primjeru cega drugoga bi mogao vjezbati OOP (nasljednjivanje, apstrakciju, enkapsulaciju, polimorfizam...), a da je zasnovano na necem konkretnom (umjesto da imas klasu zivotinja, pa derivirane klase macka i pas, koje ce se razlicito glasati kad pozoves virtualnu metodu glasajse()) - ne znam, ne pada mi trenutno nista na pamet. Nadam se da ce se naci netko s dobrim prijedlogom. Ja sam OOP uvjezbao na razvoju komponenti u Delphiju i na razvoju vlastitog GUI frameworka za Turbo Pascal, koji je imitirao izgled Windowsa i funkcioniranje VCL-a.

U ovom podebljanom lezi kljucna stvar - u paketima komponenti - pa neces to valjda pokusati podvaliti pod "dependency hell"?

Prakticki sve komponente leze na WinApiju ili su u cijelosti kod u Delphiju (ili C++Builderu). Cak i one komponente koje jedini doticaj s WinApijem imaju utoliko da se mogu prikazivati na formi i primati evente, dakle koje su efektivno cisti Delphijev kod, jedino sto od T(Win)Controla (ili nekih deriviranih klasa) nasljedjuju osnovne stvari da bi mogle funkcionirati kao kontrole u GUI-ju. To nisu nekakve eksterne komponente spremljene u DLL-ove. To su komponente napisane u Delphiju i ne zahtijevaju nikakve dodatne DLL-ove - koriste iskljucivo DLL-ove koji su sastavni dio Windowsa.

Druga je stvar ta sto ti Delphi i C++Builder omogucavaju da biblioteke (pakete) komponenti ne linkas u .exe datoteku kako bi u konacnici imao manju .exe datoteku (ili da postignes efekt slican koristenju DLL-ova - da mozes updateat samo .BPL datoteku koju ti koristi vise programa - no to je namijenjeno prvenstveno tvojim korisnickim paketima, s tvojim komponentama), nego da imas odvojene .BPL datoteke nativnih Delphi+WinApi komponenti. To nisu klasicni Windowsovi DLL-ovi, to nije nesto sto mozes ugurati pod "dependency hell" - to su dinamicke biblioteke s kompajliranim Delphijevim kodom. I taj kod, dakle komponente iz .BPL-ova ne zahtijevaju nikakve dodatne DLL-ove - samo WinApi.

To sto ti nisi ukljucio linkanje tih datoteka u .exe datoteku (ili si iskljucio - ne znam kako je podeseno po Defaultu - u Delphiju, barem u starijim verzijama, po defaultu je podeseno staticko linkanje) - to je tvoja stvar (da ne kazem "greska") i to ne znaci da VCL ima neke dependencyje - te datoteke jesu VCL. Nesto vise o paketima imas ovdje: http://delphi.about.com/od/objectpascalide/a/bpl_vs_dll.htm

PS Ovo vezano u rebuildanje nisam bas shvatio - trazi rebuild (paketa?) kod najmanjeg mijenjanja - cega? Gotovo da i nisam radio u C++Builderu - u Delphiju mi NIKAD nije radio rebuild tih paketa, osim ako nije bila rijec o mojim paketima s mojim komponentama, a cak mislim da sam i tada rebuild morao rucno raditi. Tako da - mozda te sjecanje vara, mozda si imao ukljucenu opciju da rebuilda bas sve (ako uopce ima takve opcije) - a toga si se vrlo vjerojatno mogao osloboditi tako da maknes izvorni kod VCL-a iz putanje pa ne bi imao sto rebuildati.

Koristio je... bar nekakvih 90% komponenti od delfija se moglo koristit i na BC++

Ali potrebni su BPL-ovi, što dođe na isto.

Ti zapravo nisi skužio što ja govorim i pitaš jel' znam da su BPL datoteke VCL? - LOL?

Ne znam zašto tebi nije jasan princip dinamički linkanih biblioteka. Uopće nas ne interesira što je BPL interno - to je crna kutija - Borlandova biblioteka s komponentama koje se po defaultu u C++ Builderu linkaju dinamički, dakle nisu sastavni dio tvoje aplikacije (iako mogu biti ako ti ne smeta ogroman exe).

Ako uzmeš C++ Builder i kreiraš najosnovniji Form-bazirani program s dvije T komponente, TEdit i TButton (dio StdCtrls), trebaš staviti nekoliko BPL-ova.

Nebitno je što BPL nije sadržajem identičan klasičnom DLL-u, on jest DLL - dinamički linkana biblioteka. (DLL je po funkcionalnosti).

Kada distribuiraš aplikaciju, (to ćeš vidjeti kada probaš raditi ozbiljne aplikacije) i zatrebaš nadogradnju (update), puno je lakše downloadati novi exe ili neki drugi komad od 20kb, nego novi 927678380MB exe kao što si navikao s Delphi aplikacijama. Da, možda možeš napraviti binarni patcher, ali to je strašno puno posla bez potrebe.

To je svrha DLL-ova i BPL-ova čak i za VCL komponente, a ne samo "moje korisničke komponente".

Zašto? - Zato što kod novosti ne moram distribuirati stvari koje ionako neću mijenjati, a ako upotrijebim neku noviju VCL komponentu, trebam zamijeniti samo njen BPL, odnosno BPL u kojem se ta komponenta nalazi. Kod instalacije novih aplikacija, ako su BPL-ovi globalno dostupni, nije nužno da su pristuni i u instalacijskom/distribucijskom paketu nove aplikacije.

Međutim, problem nastaje što nisu. VCL se ne instalira, kao Windows DLL, u globalnom pathu po defaultu (System32 npr.) i svaka aplikacija BPL-ove može imati lokalno, a ni razvijatelj VCL aplikacije ne može se osloniti na to da ih korisnik posjeduje. To u konačnici rezultira prevelikim distribucijskim paketima i nezgodnijim procesom nadograđivanja aplikacija.

.NET s druge strane, sam po sebi je zahtjev i unificiran je - imaš ga ili nemaš, a sve standardne komponente dostupne su u GAC-u. Nadogradnje vršiš isključivo na svojoj, manjoj aplikaciji i svojim manjim asemblajima i ne moraš brinuti za nadogradnju ili postojanje .NET komponenti.

Sve aplikacije napisane u .NET-u koriste identičan .NET te verzije koja im treba, i kao kod IIS-a npr. moguće je birati verziju CLR-a za pokretanje.

VCL nudi DLL hell - ne, ne prebrisuju se verzije u System32 novijim ili drugačijim, ali ima ništa manje napornu verziju svog DLL hella, dakle muke oko verzija, (ne)postojanja, distribucije, nadogradnji, dijeljenja i sl. što .NET drastično smanjuje i zbog toga je preporučljiviji za razvoj modernih aplikacija za Windowse.

Bitni algoritmi koji traže ekstremne brzine i ne rade dobro na C#-u (koji je također nativno kompajliran, pa je to rijedak slučaj) ionako se mogu napisati u C++u i koristiti kao DLL.

Nadam se da ti je sada jasno što je dinamički linkana biblioteka i zašto DLL ne znači isključivo "windows native DLL", već svaku dinamički linkanu biblioteku te da "DLL hell" može označavati unficirano probleme s dinamički linkanim bibliotekama; - probleme koje .NET nema skoro nikada (legacy 1.0 i 1.1 aplikacije mogu imati poneki problem, ali stare su 10 godina pa je nebitno).

Riječ dependency, koju sam upotrijebio u rečenici "VCL aplikacije imaju dependencye", znači upravo to - ovisnost aplikacije napisane korištenjem VCL-a o eksternim komponentama (dakle, izvan samog EXE-a aplikacije).

Taj dependency je nezgodniji od onog u .NET-u, iz gore navedenih razloga iako manje nezgodan od DLL-a hella koji se stvori s onim windows DLL-ovima i prebrisivanjem neodgovarajućim verzijama, jer su svi u istom System32 folderu.

Trebam pomoć oko snalaženja u MS VS-u...Od samih početaka radim u Dev C++-u i tek sam sad skinuo MS VS.Imam problema s kompajliranjem i pokretanjem Običnog koda "Hello World"...

Evo sad sve radi =D.Hvala na linku.

I napokon da više pitam jer stalno iznova zaboravljam....

Da koristim cin i cout ili scanf i printf (vidim da mi u MS VS-u javlja nešto u sigurnosti vezano uz njih)?

A ne, ne, ne... Neces sad to meni natovariti - bezobrazan si. Ovaj "nesporazum" je nastao iskljucivo zbog tvog pogresnog (zavaravajuceg?) izrazavanja (pises jedno, a navodno mislis na nesto drugo), a ne zato sto bih ja bio cjepidlaka. Ja zapocnem pricu o frameworkovima, ti mi kontriras i sad odjednom ko fol nije vise rijec o frameworkovima (bez da si to icim dao do znanja), nego o aplikacijama koje koriste te frameworkove, ili zapravo o nacinu kompajliranja/linkanja frameworkova u .exe datoteku (ako si uopce bio svjestan da se MFC moze linkati i dinamicki prije nego sam to napisao; dinamicki linkan MFC + ActiveX kontrole su skoro pa ista stvar kao koristenje .BPL-ova). Ja ti ne mogu citati misli.

Nemoj se sad izvlaciti na moj racun. Ponovno si procitaj te prve dvije poruke i zapitaj se po kojoj logici bi ja ili netko drugi iz toga trebali misliti da ti ne govoris o frameworkovima VCL i MFC, nego o VCL i MFC aplikacijama:

Dodaj:

#include <string>

velika šteta! tko će svim noobovima (poput mene) rješavati c++ probleme? eh...