Ultimate++ 2007.1: Integrált C++ fejlesztőkörnyezet szabadon

Programozás

Megjelent az Ultimate++ legfrissebb stabil változata. Azoknak a programozóknak ajánlható, akik szeretnének nagyon rövid idő alatt jól karbantartható alkalmazásokat fejleszteni Linux, BSD, Windows platformra és alkalmazásaikat natív sebességgel és memóriahasználattal futtatnák.

Újdonságok:

  • Új "Chameleon" megjelenítő architektúrának köszönhetően natív megjelenés minden platformon (Linux-on GTK+)
  • Egyéni témák (skin-ek) készítésének lehetősége az alkalmazásokhoz
  • nyomtatás, PDF-export, OpenGL, tálca-ikonok X11 platformokon is
  • ARM és PowerPC CPU támogatás
  • Kezdeti OSX és PocketPC támogatás
  • Rengeteg egyéb kisebb-nagyobb fejlesztés

Linkek:

Ultimate++ honlap: http://www.ultimatepp.org/
Néhány példaprogram képekkel: http://www.ultimatepp.org/www$uppweb2$examples$en-us.html
Letöltés: http://www.ultimatepp.org/www$uppweb2$download$en-us.html

( _Borisz_ | 2007. 04. 12., cs – 08:36 )

A beépített helloworld példaprogramjából egy 12,5 megás exe-t csinált, normális ez?

( tr3w v | 2007. 04. 12., cs – 11:03 )

"Új "Chameleon" megjelenítő architektúrának köszönhetően natív megjelenés minden platformon (Linux-on GTK+)"

Kicsit pontosítok. Az egyetlen natív GUI-s cross platform lib amit ismerek a wxWidgets (linuxon wxGTK, winen wxMSW-n keresztül). Az tehát tényleg GTK+-os hívásokat használ az egységes felület alatt.

A Chameleon pont hogy "a platform independent painting (skinning) mechanism".
Tehát pont hogy csak natív "look and feel".

Nem kötöszködésből, csak ez magyarul nem teljesen egyértelmű.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

( tr3w v | 2007. 04. 12., cs – 11:19 )

Doksira ráfeküdhetnének, mert per pillanat kritikán aluli...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

( uid_558 | 2007. 04. 12., cs – 19:37 )

Hat en annyira nem vagyok lelkes az UPP-tol. Egy project tervezett vege utan sok honappal jottem a mostani cegemghez januarban, ahol a fejlesztore volt bizva a project elejen milyen fejlesztorendszerrel akarja csinalni. UPP-t valasztott. A project meg most is fut. A hozzaadott keretrendszer (mondjuk ami Visual studiokban az MFC) valami hihetetlen sz@r minosegu kod. 2 hetembe kerult mire csak ezt kipofoztam annyira hogy gcc es MSVC7.1 forditoval is error es warning nelkul forduljon.
Valami windozos gdb-t hasznal debuggernek ami a "projectek" 80%-ban elhasal ha breakpointot teszek valahova. Ergo hibakeresesre marad a logolas meg debugger helyett a guvadder (guvadod a kodot hatha megtalalod a hibat)
Nem ismer olyan projecttipust hogy statikus library, az osszes alkatreszt hozza kell adnod a "package"-hez. Meretesebb projecteknel ez eleg sok problemat okoz. Egyreszt atlathatatlanna teszi a dolgokat, masreszt az osszes object osszes fuggvenye benne lesz az elkeszult futtathato allomanyban akar hasznalod akar nem.
Es meg...
Az egesz "package nest", "package", "assembly" rendszer teljesseggel agyhalal. Hogy csomagokat adhassak a projectemhez, a csomag szulokonyvtaranak benne kell lennie a "assembly"-ben, ami a keretrendszer beallitasahoz tartozik. Tegyuk fel hogy van egy pittyputty nevu projectem a default "MyProjects" konyvtaram alatt. Ha ehez hasznalni akarom az uppsrc "Core" csomagjat, mint a "MyApps"-nak mind az "UPPSRC-nek benne kell lennie egy assembly package netsjeben. Ez konkretan azt jelenti hogy pl egy adott projectet csak egy adott utvonalra kicsekkolva tudom forditani, vagy minden egyes checkouthoz kulon assembly-t kell letrehozzak.
Elofordul olyan hogy egy adott project ket-harom kulonbozo branch-en kellene dolgozni egyszerre, na ez az amit iszonyuan megnehezit az UPP.
Summa summarum, nalam kevesen utaljak jobban a picipuhat mint ceget, es azt amit az IT iparaggal tesz, de professzionalis fejlesztesre alkalmas fejlesztorendszert meg csak toluk lattam, bar se az eclipse-t se az anjutat nem kellett meg ugy igazan hasznaljam, azok akar meg hasznalhatok is lehetnek, viszont az anjuta az linux-only, multiplatformos vagy windozos fejlesztesre nem az igazi.

Uff, en beszeltem.

Nyilván, csak csodálkozok. Eddíg reménykedtem benne, hogy egy gnu debugger azért eléri a használható minőséget. Úgy látszik, nem...
Ez azért is érdekes, mert egy szintén gnu-s gcc-vel van használva (mivel mingw-vel jön az ultimate++) és az ember feltételezi, hogy 2 gnu-s szoftver gond nélkül használható egymással.

Alapvetoen windows platformon nem megy a debug, ahogy neztem linuxon egy nagysagrenddel jobban mukodik. Konkretan jon drWatson es kozli hogy gdb elszallt a francba. Es erdekes modon ha nem upp alol probalkozunk, command line-bol elinditva ugyan oda beteve a breakpointot sokszor nem szall el.

Csak ghat ugye azert a comamnd-line gdb nem igazan felel meg a professzionalis szoftverfejlesztes igenyeinek, kb 10x lassab barmit elerni benne mint egy GUI-s debuggerben.

Ja es az egyik projectet atkuzdottem VS2k5-be. Az upp class libraryjanak legmelyen ugy szall el access violationnal (NULL pointer access) kilepesnel mint a huzat.

Mert kb masfel evvel azelott mielott a ceghez jottem egy "kollega" ugy dontott hogy az a project aminek minimum fel eve keszen kellene lennie ebben fog keszulni. Es nem kis melo atrakni az egeszet msvs ala, eddig ket komponenst sikrult athekkelnem, es azok is elszallosabbak mint upp-ben, pedig lenyegi dologhoz nem lett nyulva, csak kozmetika hogy leforduljon, kozos komponensek libraryba, meg ilyen jellegu infrastrukturalis valtoztatasok.
Tipikus non-designed, non-documented, poorly implemented cucc amugy...

Milyen Upp verziót használsz?
Amúgy nálam a kód warning-ok nélkül fordul és nagyon megbízható. Windows-on a gcc-s (mingw) változatot szerintem nem érdemes használni, MSVS fordító kb 2-szer olyan gyors és a PDB debugger tökéletes még többszálú programokon is.
Nekem kifelyezetten tetszik a package-ek rendszere, mert akár a teljes libraryn tudok debug-olni, bár leginkább ilyenkor is az derül ki, hogy én szúrtam el valamit.
Release módban amúgy statikus lib file-okat fordít az egyes package-ekből és azokat linkeli. Szerintem jó így.
Ha több branch-en kell egyszerre dolgozni, szerintem jobb a branch-eket külön könyvtárban tartani, külön assembly-kben.

a class library az elozo stable (605?) verzio altal telepitett. Lehet hogy az ujban javitottak dolgokat, de fogja fene osszemerge-elni azt fel tonna modositast amit egyreszt en tettem bele, masreszt akollega tapasztalatlansaga okan hekkelt bele nem oda valo dolgokat. Sok idom lesz megnezem az uj libet hogy fordul gcc-vel (-wall) vagy msvc8-cal, mindenesetre a 605 pillanatok alatt teleokadta az ablakot -wall eseteben mingw-vel is.