C++ IDE/Editor kerestetik

Fejlesztés

C++ IDE-t, vagy editort keresek.

Elvárások:
1) Ne akarjon mindenáron configure scripteket, meg makefile-okat generálni, ezt bízza rám. Itt kiesik szinte az összes IDE. Eclipse CDT veszi az akadályt.

2) Jól működő, és gyors kódkiegészítéss legyen benne. Eddig két IDE-t láttam ami ezen átment, a Visual Studio, és az Eclipse CDT. Sajnos ez utóbbi gyilkos lassú, 5-8 mp-ig is eltart, míg kiegészít egy lokális változónevet, miközben VS alatt ez szinte azonnal megtörténik.
Az 5-8 mp-vel az a baj, hogy ennyi idő alatt begépelem.

Lehetőleg cross-platform legyen, illetve per pillanat win alatt kellene.

Ötlet, vélemény?

  • 5665 megtekintés

( aperger | 2006. 10. 05., cs – 16:53 )

Meg kell venni a Qt-t és akkor VS alatt írhatsz crossplatform kódot... qva drága. Sajnos a free kiadás nem használható együtt (project templates nincs benne) a VS-val

Sajnos a VS nem megy át az első ponton...

Per pillanat wxWidgets/wxWindows+MinGW alatt dolgozom, tehát a qt nem alternatíva.

Igazábol remekül elvagyok én a Far-ral, meg a Colorer pluginnal, egyedül a kódkiegészítés hiányzik...

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

( aperger | 2006. 10. 05., cs – 16:58 )

Esetleg megpróbálhatod a KDevelop-ot de az csak linux alatt megy. Ott meg lehet hívni a qmake eszközt a Qt-s project lefordításához..., auztán ami kész azt a Qt free verziójával win alatt is megpróbálod lefordítani. (Ez csak a Qt-4-es verzióval érdemes ott van mindkettőhöz (Linux-Win free kiadás)... de csak OpenSource fejlesztésre tudod használni

plusz itt van a Qt Designer is!!!!

KDevelop kitünő példa arra, hogy mit nem szeretek az IDE-kben.
Rakás mindent legenerál új project létrehozásánál.
Persze lehet, hogy úgy is lehet új projectet kezdeni, hogy ne tegye meg, de számomra ez nem volt egyértelmű anno. Ebből a szempontból az Eclipse CDT eszméletlen jó.

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

A KDevelopnak minden verziójában van valami szopás, de pont a custom makefile-ok kezelése tetszik benne. CMake-et használok (out-of-source build, keresztplatform, cool), ami sima makefile-okat generál. Ha nem a CMake Kdevelop projectfile generátorát használom, akkor is lazán tudom importálni a projektet mint C++ project ami custom makefile-okat használ. A build menüben meg is jelennek a CMake által generált targetek. Ezen kívül annyi bosszantó hiba van benne, hogy kezdem utálni, pedig tényleg jó kis IDE lenne.
A vim viszont óriási, mindent tud ami nekem eddig kellett, eddig még nem tévedtem vele, csak kicsit sokáig tart amíg mindent beállít az ember. Annak ellenére hogy 6 éve használom. A 7-es verziótól már van beépített kódkiegészítés benne, amit még nem próbáltam, de a kódnavigáció kitűnően működik.

( aperger | 2006. 10. 05., cs – 17:09 )

Hát én még csak nézegetem a dolgokat mert szeretnék a Kylix/Delphi páros elhagyása után is natív programokat futtatni a sebesség miatt, de az általam fejleszett programok sok összetevővől állnak, GUI, adatbázisok, HTTP (jövőben SOAP) kommunikáció, nyomtatás és jó ha egy komplett IDE alatt tudnék dolgozni. Igaz ezek elég robosztusak, de legalább egyben megvan ami kell egységes egészként, ami szerintem csökkenti a fejlesztés idejét.

>> Nomeg egy jó GUI szerkesztő sem árt, bár nem feltétlen szükséges.
nem vagyunk egyformák, lehet notepadből is nyomni, de többen szeretnek használni fejlettebb, és már rég nem utópisztikus megoldásokat (távoli debuggolás, break után kódszerkesztés és folytatás újraindítás nélkül, objektumok tesztelése tervezési időben, korrekt refaktorálási lehetőségek, etc...)

Valóban nem vagyunk egyformák. :)

Az általad említett feature-ök közül max az utolsó 2 ami érdekelne, bár inkább az utolsó.
De én beérném kevesebbel. Egy normális kódkiegészítés kéne csak, és az, hogy egy Hello Wordhöz ne generáljon 3 megányi scriptet.
Olyan sokat kérek???

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

Lehet (sőt szinte biztos), hogy felületesen néztem meg az eddig talált IDE-ket, de a legtöbb mindenáron maga akarta managelni a makefile-okat, scripteket.
Ez alól az üdítő kivétel az Eclipse CDT volt, és már éppen kezdtem megszeretni, mire lenyomtam az első ctrl+space-t...

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

"szeretnék [...] natív programokat futtatni a sebesség miatt"
Ez a baj, az interpretált nyelvekkel.
Persze ahol nem olyan lényeges a sebesség, ott tényleg jól muzsikálnak.

(IronPython sebességtesztet látott már valaki?)

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

Ő mondta, hogy natív kódot használ a sebesség miatt, és én el tudom képzelni, hogy olyan projekten dolgozik, ahol a python sebessége nem megfelelő.
Persze nem tudom min dolgozik, így lehet, hogy igazad van.

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

Sajnos nem voltam itt... de köszönöm a sok hozzászólást.
Hogy miért nem fordulok egy python vagy ruby felé:
- nem feltétlen a sebesség az oka
- a munkaadók jelentős százalékánál C/C++, C#, Java nyelvekkel lehet munkát találni, nekem ez elég fontos indok: család + megélhetés!
- a megtanulás azért időt vesz igénybe a jelenlegi munkáim melett, de mindegyik nyelvben (Object Pascal, C/C++, C#, Java) vannak a "hello world"-nél jóval magasabb alapismereteim inkább úgy mondanám, hogy az osztály-struktúrát a legjobban a Delphi/Kylix vonalon ismerem, aztán Java (SWT/Eclipse, egy kis AWT/SWING), sajnos a legrégebben C/C++-ban dolgoztam (húúú már 4 éve, VC++ 6.0 + SP5).
És ha már nem natív a nyelv, akkor inkább Java és C#.
A C#-os MS VC# 2005 könyvön nagyjából túl vagyok... gondolkodtam a Gtk-csharp modulban is de elég kezdetleges...

ui.: nekem nem csak egy nyelv kell, hanem egy jó fejlesztőkörnyezet. Egyenlőre 1-2 ilyet próbáltam ki KDevelop, MonoDev)

Szerintem java-ban. Attól is ódzkodtam. :)
Mondjuk általában nem volt gondom a sebességével, leszámítva a kódkiegészítést, de azt nem gondolom, hogy az csupán a Java miatt ennyire lassú...

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

( zsolt | 2006. 10. 05., cs – 18:28 )

Ultimate++-t nézted? Mostanában ezzel fejlesztek Linux/Windows platform-független kódot.
Ez igazából egy IDE és egy teljes library BSD licensszel.
Az IDE tud kódkiegészítést (nagyon gyors), project-kezelést (nincsenek makefile-ok), távoli debug-ot. Van benne felületfejlesztő, képszerkesztő, dokumentáló eszköz. Könnyű vele a fordításokat (pl. magyar, angol, stb.) is karbantartani.
A mellékelt lib a Qt-hez hasonló módon nem natív widget-eket használ, hanem saját maga rajzol mindent, bár XP-n az oprendszer theming engine-jén keresztül.
A fordítási idő rettentően rövid, egy azonos kaliberű makefile-os Qt-s project-nél szerintem 4-5-ször gyorsabb, köszönhetően a beépített Blitz++ nevű fordítás-gyorsítónak. Ez egy nagyon elmés dolog, érdemes elolvasni, hogy működik.
Az alkalmazásokban a GUI tökéletesen elválik a logikától és szerencsére nem idióta kódgenerátorral oldották ezt meg (.lay file).
A nagyon átgondolt filozófiának és tervezésnek köszönhetően nincs szükség sem mutatókra sem GC-re, így hatalmas az előnye a CG-s megoldásokkal szemben.
A library adatbázis-kezelése még egy unikum. Sehol máshol nem láttam még zseniálisabb megoldásokat.

Ismerem igen.
De mint fentebb írtam, per pillanat wxWidgetsben dolgozom, és a project felénél tán nem kéne lib-et váltani. :)
Egyébként az nem tetszik az Ultimate++-ban, hogy nem natív Widgetet használ (a wxWidgets igen).

A Blitz++ egy expression template-ekre épülő numerikus lib, tehát valamivel kevered. :)

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

Bocs, simán BLITZ.
Egyébként én is wx-ről váltotam. Elegem lett az Event táblákból, a rettentő gagyi layout-kezelésből meg a normális felületfejlesztő hiányából. Kb 40-50%-on volt a project, mikor próbából nekiálltam átrakni Ultimate++-ra. Annyira könnyen ment, hogy áttettem az egészet pár nap alatt. Nagyon jó volt megszabadulni a wx kínjaitól :)

Igen, vannak benne nagyon fapados dolgok.
De nekem most szempont volt a natív widget kezelés, és már ez is hatalmas felüdülés volt az MFC-hez képest (na az tényleg szar...).

Bevallom az Ultimate++-t is néztem, ott az nem tetszett, hogy úgy érztem feltalálták a melegvizet a saját container bevezetésével. Na meg a saját string osztállyal. És még sorolhatnám.
Ez nekem azért fájó pont, mert egyre többet használom a boost-ot, ami nagyon épít az STL-re.

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

Eleinte én is azt hittem, csak a "melegvizet" találták fel de egészen másról van szó. Bevezettek néhány olyan dolgot, ami STL-ben nincs és arra építve hozták létre a saját container-eiket meg egyéb sablonjaikat (NTL). Ha a moveable concept-et áttanulmányozod, megérted, miért használhatóbb ez mint az STL és ráadásul jóval gyorsabb is.
Kényelmes dolog pl. egy óriási méretű vektort simán visszatérési értékként átadni a stack-en anélkül, hogy kétszer létrejönne közben minden elem, mint STL esetében.
Saját string-re meg a normális unicode kezeléshez szükség van még wx-ben is.

"Kényelmes dolog pl. egy óriási méretű vektort simán visszatérési értékként átadni a stack-en anélkül, hogy kétszer létrejönne közben minden elem, mint STL esetében."
Erre mondjuk ott van az auto_ptr, vagy méginkább a smart_ptr (boost).

De ott van a String osztály. A copy constructor nem másol csak növeli a referencia számlálót. Ez engem zavar, mert pl fv-nek mindig const ref-ként adom át, ha nem akarom változtatni, ref-ként ha igen, és érték szerint, ha majd esetleg a fv-n belül mahinálok vele.
Itt meg a referencia szerinti ill. az érték szerinti átadás a gyakorlatban egybe esik.
Mondjuk ez nem túl nagy gond, ha minden Ultimate++ osztály így működik, mert akkor meg lehet szokni, akkor van gond, ha valamiért használsz sima stringet is.

"Saját string-re meg a normális unicode kezeléshez szükség van még wx-ben is."
Igen, bár ez már sima STL string-re épül.

Ez a másik ami nem tetszik (igaz ez egyik libben sem), hogy nem lehet egyszerűen konvertálni sima stringből Stringbe (vagy wxStringbe).
Ez néha marha idegesítő tud lenni, ha használsz valami külső C++ libet.

Egyébként nem mondom, hogy a wxWidgets jobb, csak nekem elsőre ezért nem tetszett az Ultimate++. Persze, most, hogy már megismertem a wxWidgets hülyeségeit, ez nem tűnik olyan nagy bajnak.

De még mindig keresem azt a GUI libet ami számomra kompromisszum mentes.
(A SmartWin igéretes, de sajnos nem cross-platform.)

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

String-ekkel nekem is minden bajom van C++-ban általában, de nekem ez az Ultimate++-os refcounter-es dolog bejön. A stack-en érték szerint átadott string bufferjét első íráskor klónozza. Szerintem ez teljesen korrekt és megmenekülsz egy csomó memóriamásolástól. Nem beszélve arról, hogy sok programozó simán érték szerint ad át mindent és így legalább megvédi őket a hülyeségüktől.

"Ez a másik ami nem tetszik (igaz ez egyik libben sem), hogy nem lehet egyszerűen konvertálni sima stringből Stringbe (vagy wxStringbe)."
Azért az alap C-s const char* mindenhol megvan.

"A stack-en érték szerint átadott string bufferjét első íráskor klónozza."
Copy-On-Write?
Az más. Wiki nem írta, máshol meg nem találtam a stringről semmit.

"Azért az alap C-s const char* mindenhol megvan."
Elég csúnya és fárasztó a sok c_str().
Arról nem is beszélve, hogy micsoda szívások vannak ha az egyik string wchar_t a másik utf-8-at használ az unicode szövegekhez. :)

Mindenesetre a köv projectnél adok egy esélyt az Ultimate++-nak, hátha.

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

( kr304 | 2006. 10. 05., cs – 20:21 )

emacs? vim? :)
bár a vim-be nem tudom lehet-e fájdalommentesen installálni plugint w32 alatt...

( uid_4672 | 2006. 10. 05., cs – 20:51 )

visual slickedit a te barátod...
fizetős, de működik

állítólag MS-ék is ezt használták a még anno NT szurszokhoz, mert csak ezzel lehetett több ezer fileot kezelni egy projektben. De erről nem sokat tudok...

( bocs | 2006. 10. 05., cs – 22:26 )

Most jött ki a Borland-tól a Turbo C++ 2006 fejlesztői környezet.

- nem keresztplatformos /csak win32/
- abszolút gyors és szép GUI fejlesztés, debuggolás, code completion, STL, saját string osztályok, Unicode, hálózatkezelés, reportolás, grafika...
- az alapverzizója ingyenes, és a vele fejlesztett programok is eladhatóak /NEM kell hozzá forrást adni/
- kb ugyanazt tudja, mint a Borland C++ Builder 6 Professional, ami cirka 300 eFt volt
- kb 1 nagyságrenddel többet tud, mint a Visual Studio Express 2005
- hátránya, hogy egy nem túl fényes jövő előtt álló cég fejleszti

A kritikámat fenntartom.

Több mint 10 éve Borland C++ termékeket használok, de színvonaluk szinte folyamatosan romlik.
Élesben fejlesztek Borland C++ Builderrel és Turbo C++ 2006-tal is.
Az új Turbo C++ csak a kb 4-5 éves Builder picit ráncfellvart változata, szinte ugyanazokkal a bossantó hibákkal, compiler bugokkat, instabilitással.

Vagyis 4-5 éve semmi igazán újat nem tudtak kifejleszteni - a marketing droidok a Borlandnál átvették az irányítást, és fejlesztőeszköz készítés helyett "életciklus management" meg mindenféle ilyen buzzword-öket dobálnak évek óta.

A Borland átszervezését is hiszem, ha látom: volt ez a Turbo termékvonal, aztán Borland, aztán Inprise, aztán Borland, aztán DevCo lett most, újra Turbo termékvonallal...
szóval kíváncsi vagyok, ez is ugyanolyan parasztvakítás lesz-e, mint eddig volt.

Hasonlítsd össze a Qt-val vagy a Visual Studio-val: összehasonlíthatatlanul gyorsabb a fejlődésük, van koncepciójuk, van jövőképük, vannak új, és jó ötleteik, van jövőjük:
a Borlandnak ezek közül egyik sincs :((

Pár évvel ezelőttig még én is Borland cuccokkal dolgoztam, de tényleg úgy van, ahogy a kolléga mondja. Minőség folyamatosan romlik. Mióta elmentek a Borland fejlesztői a Microsft-hoz .NET-et fejleszteni, azóta már csak toldozzák-foltozzák a Borland cuccokat minden koncepció nélkül. Egy hatalmas bloatware lett az egész. A legújabb Delphiben (2006) már a help-et sem lehet használni... Viszont 1.1-es .NET az van menne.

( dejo v | 2006. 10. 06., p – 08:26 )

Windowsra a DevC++ megér egy próbát. GPL-es.
http://www.bloodshed.net/devcpp.html

Feature list
* Support GCC-based compilers
* Integrated debugging (using GDB)
* Support for multiple languages (localization)
* Class Browser
* Code Completion
* Debug variable Browser
* Project Manager
* Customizable syntax highlighting editor
* Quickly create Windows, console, static libraries and DLLs
* Support of templates for creating your own project types
* Makefile creation
* Edit and compile Resource files
* Tool Manager
* Print support
* Find and replace facilities
* Package manager, for easy installation of add-on libraries
* CVS Support
* To-Do List
* CPU Window

( lbodnar | 2006. 10. 06., p – 10:05 )

slickedit ...
beleszerettem mind win mind linux alatt.
es az arat is megeri ha nem otthoni hobbi dologrol van szo

( Joejszaka v | 2006. 10. 06., p – 10:40 )

Vim, +1 szavazat.

Honapok ota hasznalom C++ fejlesztesre win alatt is. A legjobb automatikus kiegeszito van benne, amit ismerek. Ra kell szanni egy hetet, amig az ember kiismeri a lehetosegeket.

( emberk | 2006. 10. 06., p – 12:33 )

Win alá a devc++ de az nem keresztplatformos az vin-es én azt használom és szeretem.
Lin alá meg a rhide csak 64-biten kicsit necces jó sokat konfigoltam mire elindult, de én nem írok komoly fejllesztéseket egyedi kis progikat csinálgatok velül.

( wias | 2006. 10. 08., v – 10:22 )

Én csak annyit szertenék kérdezni, hogy milyen report generator programokat ismertek ami, platform független és használható?

( crape | 2006. 10. 08., v – 11:20 )

Akkor már miért nem Emacs? Amúgy Eclipse alatt a kódkiegészítés legfeljebb 2 másodperc nálam, nem értem, hoyg tarthat helyenként 6-7 mpig. Továbbá érdemes kipróbálni a 3.2-est (nemrég jött ki). Nagyságrendekkel gyorsabb a 3.1-nél. Néha valóban zavaró, hogy Java-s (lassabb, sokat eszik), de én még mindig nem találkoztam jobb fejlesztői környezettel (kivéve MonoDevelopot, de az csak C#)...

3.2 van fennt.

Talán az lehet a gond, hogy az include-path-ben benne van a teljes STL, Boost, wxWidgets, meg még pár dolog.
Tehát elég sokmindent kell átnyálazni egy kiegészítésnél.
De szerintem 7 mp akkor is nonszensz.

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