Koji kompajler se koristio prije pojave Visual Studia? Je li postojao neki njegov predak ili se koristio Borland ili pak nesto trece?
Potpis
...
Sta je postojalo prije Visual Studia?
Zaključano
Zakačeno
To je kao pitanje sta je bilo pre Srba. Nista naravno. :]
Elem, za koji jezik? A i Visual Studio i nije kompajler vec IDE (Integrated Development Enviroment) koji koristi odgovarajuce kompajlere, zavisno od jezika.
Elem, za koji jezik? A i Visual Studio i nije kompajler vec IDE (Integrated Development Enviroment) koji koristi odgovarajuce kompajlere, zavisno od jezika.
Hehe oprostite, mislio sam na IDE naravno 
Jezik je C++.
ps. ta nece c#
Jezik je C++.
ps. ta nece c#
Potpis
...
C++ ide-ova imas ko pleve, samo MS ih je imao gomilu.
Pogledaj clanak na wikipediji: Visual C++ u delu "History", samo od njih ima 12 edicija visual C++-a
Pogledaj clanak na wikipediji: Visual C++ u delu "History", samo od njih ima 12 edicija visual C++-a
Potpis
Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić
Ja sam pre VC-a (tj. VC++ 5.0) koristio komandnu liniju u kombinaciji sa TSE editorom, makefile i DJGPP ili Watcom C++.
Hehe stari dobri Watcom C (DOS4GW anyone? :-)
Pre VC++ 1.5 C++ i nije bas bio tako popularan, tada su vladali Turbo C i Watcom C i Microsoft C/C++ :)
Pre VC++ 1.5 C++ i nije bas bio tako popularan, tada su vladali Turbo C i Watcom C i Microsoft C/C++ :)
Potpis
DigiCortex (ex. SpikeFun) - Cortical Neural Network Simulator:
http://www.digicortex.net/node/1 Videos: http://www.digicortex.net/node/17 Gallery: http://www.digicortex.net/node/25
PowerMonkey - Redyce CPU Power Waste and gain performance! - https://github.com/psyq321/PowerMonkey
http://www.digicortex.net/node/1 Videos: http://www.digicortex.net/node/17 Gallery: http://www.digicortex.net/node/25
PowerMonkey - Redyce CPU Power Waste and gain performance! - https://github.com/psyq321/PowerMonkey
TurboC! WOW. sada on sluzi kao treca varijanta za C++ (VS, Devcpp, pa on).
A sto se tice forme IDE-a, jeste li i prije imali ove zgodne alate poput brzog kreiranja projekata (onih osnovnih dijelova), design view, toolbox sa gotovim kontrolama i slicno?
A sto se tice forme IDE-a, jeste li i prije imali ove zgodne alate poput brzog kreiranja projekata (onih osnovnih dijelova), design view, toolbox sa gotovim kontrolama i slicno?
Potpis
...
E da DOS4GW... :)
Za protected mod sam koristio PMODE (DOS4GW je imao 16MB limit za nekomercijalnu upotrebu).
Zaboravio sam da navedem debugger, zove se printf i još uvek je najpouzdaniji debugger. :) U to vreme je bilo moguće zakačiti hercules grafičku zajedno sa VGA pa je drugi monitor služio za printf. :)
Za protected mod sam koristio PMODE (DOS4GW je imao 16MB limit za nekomercijalnu upotrebu).
Zaboravio sam da navedem debugger, zove se printf i još uvek je najpouzdaniji debugger. :) U to vreme je bilo moguće zakačiti hercules grafičku zajedno sa VGA pa je drugi monitor služio za printf. :)
Ivane, zaboravio si Borland C++ 3.1, 4.5, 5.02 na OWL-u :)
A sto se tice forme IDE-a, jeste li i prije imali ove zgodne alate poput brzog kreiranja projekata (onih osnovnih dijelova), design view, toolbox sa gotovim kontrolama i slicno?
Wizardi su postojali odavno kod maltene svih IDE-a, ali je Borland C++ Builder je dugo vremena bio jedini *pravi* vizuelni alat (two way tool) za razvoj C++ koda.
Citat:
A sto se tice forme IDE-a, jeste li i prije imali ove zgodne alate poput brzog kreiranja projekata (onih osnovnih dijelova), design view, toolbox sa gotovim kontrolama i slicno?
Wizardi su postojali odavno kod maltene svih IDE-a, ali je Borland C++ Builder je dugo vremena bio jedini *pravi* vizuelni alat (two way tool) za razvoj C++ koda.
Tacno,
Ja sam poceo programiranje sa Borland C++ -om 3.1 :)
To je tada bio najjaci vizuelni alat - a OWL je bila vrlo razvijena biblioteka.
Medjutim, onda je Microsoft pokupovao sve sto valja od ljudi iz Borlanda i napravio u svemu superiorniji IDE a i kompajler. Jos se secam kada je VC++ 2.0 utirao Borland C++ 4.5 u brzini izvrsavanja kompajliranog koda...
Ja sam poceo programiranje sa Borland C++ -om 3.1 :)
To je tada bio najjaci vizuelni alat - a OWL je bila vrlo razvijena biblioteka.
Medjutim, onda je Microsoft pokupovao sve sto valja od ljudi iz Borlanda i napravio u svemu superiorniji IDE a i kompajler. Jos se secam kada je VC++ 2.0 utirao Borland C++ 4.5 u brzini izvrsavanja kompajliranog koda...
Potpis
DigiCortex (ex. SpikeFun) - Cortical Neural Network Simulator:
http://www.digicortex.net/node/1 Videos: http://www.digicortex.net/node/17 Gallery: http://www.digicortex.net/node/25
PowerMonkey - Redyce CPU Power Waste and gain performance! - https://github.com/psyq321/PowerMonkey
http://www.digicortex.net/node/1 Videos: http://www.digicortex.net/node/17 Gallery: http://www.digicortex.net/node/25
PowerMonkey - Redyce CPU Power Waste and gain performance! - https://github.com/psyq321/PowerMonkey
To što si opisao, upravo je sahranilo jedan C++ projekat u kome sam učestvovao :)
Krenulo se sa Borland C++ 3.1 na OWL-u, jer su svi pokazatelji bili na strani te kombinacije. Microsoft C++ rešenje u tom trenutku je (u najmanju ruku) bilo neozbiljno. Negde na pola projekta (već je bila verzija 4.5 kod Borlanda) shvatilo se koliko je M$ moćan da preokrene situaciju u svoju korist, ali za započeti projekat je bilo prekasno da se vrši portovanje na MFC. Onda se nastavilo sa Borlandovim komapjlerom 5.02, sve dok Projekat konačno nije više imao kud. Noviji Borland kompajler 5.5 nije ni mogao da prevede kod koji je prolazio u 5.02 :) Slepa ulica.
U međuvremenu Microsoft Visual Studio na C++/MFC-u je postao industrijski standard i tu je 'zauvek' stavljena tačka. Inače, taj M$ IDE je ipak bio siromašan u odnosu na Delphi/Borland C++ Builder varijantu koji su imali ono što danas viđaš u .NET koncepciji (staviš dugme na formu, podešavaš osobine i pridužuješ kod događaja)
Konačno Anders Hejlsberg, idejni tvorac Delphija i Object pascala i celog tog projekta 'odlazi' kod M$-a i postaje glavni arhitekta .NET i C# projekta. To je drugi veliki udarac za Borland iz koga se nikad nisu izvukli.
Krenulo se sa Borland C++ 3.1 na OWL-u, jer su svi pokazatelji bili na strani te kombinacije. Microsoft C++ rešenje u tom trenutku je (u najmanju ruku) bilo neozbiljno. Negde na pola projekta (već je bila verzija 4.5 kod Borlanda) shvatilo se koliko je M$ moćan da preokrene situaciju u svoju korist, ali za započeti projekat je bilo prekasno da se vrši portovanje na MFC. Onda se nastavilo sa Borlandovim komapjlerom 5.02, sve dok Projekat konačno nije više imao kud. Noviji Borland kompajler 5.5 nije ni mogao da prevede kod koji je prolazio u 5.02 :) Slepa ulica.
U međuvremenu Microsoft Visual Studio na C++/MFC-u je postao industrijski standard i tu je 'zauvek' stavljena tačka. Inače, taj M$ IDE je ipak bio siromašan u odnosu na Delphi/Borland C++ Builder varijantu koji su imali ono što danas viđaš u .NET koncepciji (staviš dugme na formu, podešavaš osobine i pridužuješ kod događaja)
Konačno Anders Hejlsberg, idejni tvorac Delphija i Object pascala i celog tog projekta 'odlazi' kod M$-a i postaje glavni arhitekta .NET i C# projekta. To je drugi veliki udarac za Borland iz koga se nikad nisu izvukli.
@virtualVoid
I još nešto. Ono što je danas uobičajeno - da imaš i komapjler i IDE od iste firme, nekada nije bilo pod obavezno! Recimo ja sam koristio Visual SlickEdit dugo vremena, jer mu ni jedan editor nije bio do kolena. Samo podesiš kompajler, linker i neke detalje, i imaš IDE za svoj kompajler. Imaš dosta Video Demoa na tom sajtu pa pogledaj.
Eto, recimo to je postojalo :)
I još nešto. Ono što je danas uobičajeno - da imaš i komapjler i IDE od iste firme, nekada nije bilo pod obavezno! Recimo ja sam koristio Visual SlickEdit dugo vremena, jer mu ni jedan editor nije bio do kolena. Samo podesiš kompajler, linker i neke detalje, i imaš IDE za svoj kompajler. Imaš dosta Video Demoa na tom sajtu pa pogledaj.
Eto, recimo to je postojalo :)
Citat:
X Files: Inače, taj M$ IDE je ipak bio siromašan u odnosu na Delphi/Borland C++ Builder varijantu koji su imali ono što danas viđaš u .NET koncepciji (staviš dugme na formu, podešavaš osobine i pridužuješ kod događaja)
Nije to bas .net koncepcija, to je postojalo u vb-u... hm.. ja znam za 5icu, ali verovatno od trojke (ako ne i od samog pocetka) sto je mnogo pre .net-a
^
Mislio sam na C++ resenja, ali u toj recenici nisam naznacio :)
EDIT: a ono što mislim da je bilo novina je nešto što zovu Two-Way-Tools method.
Mislio sam na C++ resenja, ali u toj recenici nisam naznacio :)
EDIT: a ono što mislim da je bilo novina je nešto što zovu Two-Way-Tools method.
prije si imao programe tipa qbasic i pascal za dos ili si ih pokretao direktno, tamo 70'.
u njima si mogao napraviti također aplikaciju sa menu-om i možda su postojale funkcije za elemente, tipa gumb, dialog, itd...
početkom 70' se pojavio c kompajler i negdje 83' se pojavio win 1.0.
te se na win 1.0 moglo raditi vizualne programe.
s time da si morao sve ručno pisati u kodu.
za svaku formu, za svaki gumb.
recimo na ovaj način možeš raditi u čistom wxpythonu.
tako ako radiš u borland c++, možeš bez problema naparviti aplikaciju sa gui-em samo pišući code.
sad koliko je ovo pametno raditi ne znam.
također koliko sam vidio neki i dan danas vole ovako raditi, pogotovo kod java aplikacija.
a moje pitanje bi bilo zašto sve pisati ručno kad postoji vizualni dio za izradu gui-a, Eclipse sa VE, netbeans?
te za c++ postoji VS, QT itd...
a opet neki rade ručno.
u njima si mogao napraviti također aplikaciju sa menu-om i možda su postojale funkcije za elemente, tipa gumb, dialog, itd...
početkom 70' se pojavio c kompajler i negdje 83' se pojavio win 1.0.
te se na win 1.0 moglo raditi vizualne programe.
s time da si morao sve ručno pisati u kodu.
za svaku formu, za svaki gumb.
recimo na ovaj način možeš raditi u čistom wxpythonu.
tako ako radiš u borland c++, možeš bez problema naparviti aplikaciju sa gui-em samo pišući code.
sad koliko je ovo pametno raditi ne znam.
također koliko sam vidio neki i dan danas vole ovako raditi, pogotovo kod java aplikacija.
a moje pitanje bi bilo zašto sve pisati ručno kad postoji vizualni dio za izradu gui-a, Eclipse sa VE, netbeans?
te za c++ postoji VS, QT itd...
a opet neki rade ručno.
Citat:
a moje pitanje bi bilo zašto sve pisati ručno kad postoji vizualni dio za izradu gui-a, Eclipse sa VE, netbeans?
Raditi "ručno" je mnogo bolje ako planiraš da održavaš kod. Izgled i funkcija forme je na jednom mestu (npr. kada radiš diff, ne moraš da porediš više fajlova). Neki dizajner alati driže formu u binarnom obliku pa nije moguće porediti verzije, ili svaki put snime formu iz početka, pa diff uvek prijavi veliki broj izmena iako se radi o par jednostavnih izmena, itd.
Pa ne bih se bas slozio sa time. Odreci se RAD produktivnosti zarad diff alatke mi se cini poprilicno arhaicno, GUI kod za kompleksnu formu moze da naraste na par hiljada linija koda uz efektivan payload (konkretnu logiku) forme od par stotina linija. U tom scenariju nesto mora da strada, ili ce razvoj te forme biti preskup ili ce se seci UI funkcionalnost forme.
Uostalom, bar sto se tice .NETa, ni diff nije problem, forme se serijalizuju u kodu po identinom redosledu i dva snimanja bez promene generisu identican kod dok ce bilo koja pojedinacna promena biti grupisana u okviru inicijalizaije svog objekta i bice vrlo lako izvuci promene kroz diff.
Uostalom, bar sto se tice .NETa, ni diff nije problem, forme se serijalizuju u kodu po identinom redosledu i dva snimanja bez promene generisu identican kod dok ce bilo koja pojedinacna promena biti grupisana u okviru inicijalizaije svog objekta i bice vrlo lako izvuci promene kroz diff.
Potpis
Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić
Citat:
bkaradzic: Raditi "ručno" je mnogo bolje ako planiraš da održavaš kod. Izgled i funkcija forme je na jednom mestu (npr. kada radiš diff, ne moraš da porediš više fajlova). Neki dizajner alati driže formu u binarnom obliku pa nije moguće porediti verzije, ili svaki put snime formu iz početka, pa diff uvek prijavi veliki broj izmena iako se radi o par jednostavnih izmena, itd.
pa zar onda izrada projekta ne traje duže?
ako traje duže, onda je i skuplje?
KVALITET ce uvek kostati (i vremena i novca)
Potpis
Žena u krevetu i vino na stolu nikako ne smeju da čekaju. Jer, vino se greje a žena hladi.
-vinolog
-vinolog
Citat:
mmix: Pa ne bih se bas slozio sa time. Odreci se RAD produktivnosti zarad diff alatke mi se cini poprilicno arhaicno, GUI kod za kompleksnu formu moze da naraste na par hiljada linija koda uz efektivan payload (konkretnu logiku) forme od par stotina linija. U tom scenariju nesto mora da strada, ili ce razvoj te forme biti preskup ili ce se seci UI funkcionalnost forme.
U mom slučaju je obrnuto, obično GUI forma je veoma jednostavna, dok je logika komplikovana. Ovo što ti kažeš mi zvuči više kao popunjavanje obrazaca u kojima se kod koristi samo da popuni redundantna polja. Mada ako već to radiš onda možeš da napraviš widget za data-driven obrazac koji bi to automatski uradio za tebe. Data-driven obrazac koji se najčešće koristi je property sheet. U ovom slučaju inicijalni development tog widgeta je komplikovan i ne zahteva nikakav designer alat, 100% je kod, dok dodavanje novih obrazaca u program je trivijalno i zahteva npr. konverziju PDF u XML ili pravljenje specijalnog XML-a. Takođe ako se ne radi o obrascu i forma je toliko komplikovana da zahteva hiljade linija koda, onda verovatno i korisnik forme će biti veoma zbunjen kada je koristi.
Citat:
MarkoBalkan: pa zar onda izrada projekta ne traje duže?
ako traje duže, onda je i skuplje?
ako traje duže, onda je i skuplje?
Pitanje je da li će tvoj projekat imati v2.0, v3.0, itd. ili ćeš ga posle v1.0 baciti i početi da pišeš iz početka. Najskuplje je da uvek razvijaš projekat iz početka, a to se dešava kada je cena održavanja visoka.