C++ Builder-t használók figyelem
2005-05-06T17:24:05+02:00
2005-12-09T13:41:00+01:00
2022-07-26T21:47:30+02:00
  • Kezdem a rosszabb falatokkal: a portolhatóságnál valóban nem ezt kellett volna írnom, hanem hogy szabvány-kompatibilitás (legalábbis erre gondoltam). Én sok, magát szabványosnak nevező könyvtárat kipróbáltam a Builder-rel, nem volt vele hiba. És a Builder-ről ezt állítják, nem azt, hogy a vele készített kód portolható - eltekintve azoktól az esetektől, amiket a szétbontással kapcsolatban írtam. Olyat számonkérni, amit senki nem ígért, értelmetlen (hogy ismételjem magam).
    Ez felvetheti azt a kérdést is, hogy mit jelent az, "vele készített". Ezt arra is mondhatom, hogy ha csak unit-ot készítek (amiben történetesen csak szabványos elemekre hivatkozom), vagy igénybe veszem a környzet szolgáltatásait is.
    És itt jön a képbe az általad nagyon utált __property (vagy a __fastcall): ez ugyanis csak akkor kerül a kódba, ha te olyan elemeket akarsz használni, amiket a környezetben (főleg a Property editor-ban) is el akarsz érni. Az IDE-nek valamilyen módon információval kell rendelkeznie arról, hogy melyek is azok a mezők (eseménykezelők) az osztályodban, amiket a környzeteben is el akarsz érni (meg tárolni a beállított értékeket úgy, hogy azok a lefordított programban is benne legyenek és az azokat használja, automatikusan létrehozza).
    Egy ilyen elem létrehozása azonban nem kötelező, a programod felületét felépítheted az egyéb (többplatformos) könyvtárakhoz hasonlóan is: a konstruktorban (vagy akár egyéb metódusban) hozod létre az elemeket és adod nekik a megfelelő értéket (komponensfejlesztésre ez kifejezetten ajálott). Ekkor semmilyen __propery bejegyzésre nincs szükség (bár megteheted, a Builder-ben ezzel nem okozol problémát). Ezzel a VCL-t, vagy a CLX-et ugyanúgy használhatod, mint a wxWindows vagy a Qt elemeit - az egy más kérdés, hogy a Borland gyakorlatilag csak a fejlesztőeszközökhöz készítette el ezek implementációit.
    Itt a tradeoff elemeit kell látni: a környzet neked tud segíteni valamiben (ez az elemek létrehozása és értékeinek beállítása - és azért ez egy komolyabb méretű program esetében nem jelentéktelen), viszont valamilyen árat kell fizetni ezért - ez a környzet információtárolása a __property-k révén. Itt mindig a fejlesztőnek kell mérlegelnie, hogy neki az adott szempontok szerint mi a fontos, illetve mit hogy tud kezelni. Ezt igazából felelősséggel csak akkor lehet megtenni, ha valaki viszonylag jól ismeri az eszközöket és azok lehetőségeit - ehhez pedig gyakran kísérletezni is kell.

    Hogy valami példát is adjak a sok dumára, ne csak lebegjen a levegőben:
    Qt:
    QEdit *myEdit = new QEdit(this, ...);
    myEdit->setGeometry(...);
    VCL: (IDE nélkül):
    TEditBox *myEdit = new TEditBox(this);
    myEdit->Left = ...;

    A kettő max. abban különbözik egymástól, hogy nem ugyanazt az osztálykönyvtárat használja, egyébként mindkettő szabványos (ezt nem befolyásolja az sem, hogy a Left valójában __property, ehelyett lehetne SetLeft() is). Hogy az adott könyvtár megvan-e egy bizonyos platformon, az csak a könyvtár fejlesztőinek felelőssége (a többplatformosok speciel megvannak, de a VCL-lel is meg lehetne csinálni). Ezek csak felületek, az implementáció bármilyen tartalmú lehet.

    Ha a többplatformos könyvtárakat nézem, pontosabban annak tervezőeszközeit, akkor jól látható, hogy azok nem csinálnak többet, mint amit mi is megtehetnénk a forráskódban (elemek létrehozása, beállítása). És ehhez külön alkalmazások kellenek (pl. Qt Designer), ezek pedig a programfordítástól, futtatástól függetlenek. Ráadásul ezek eredményeit nem is célszerű kézzel buherálni, mert egy újragenerálás törölheti a mi módosításainkat (erre figyelmeztető szöveg is szokott lenni).
    A Builder-ben az IDE pont azt jelenti, hogy ezeket az eszközöket egy csoportban teszi elérhetővé - és ezért nem mondják ezt a könyvtárakra és az azokhoz tartozó tool-okra. Az IDE (pontosabban annak bevonása a megoldásba) pont olyan eszköz, mint bármi a világon: vannak valamilyen tulajdonságai és azt nekünk kell kontrollálnunk (megfelelő ismeretek birtokában), hogy az előnyök és hátrányok kielégítik-e az igényeinket, illetve hogy ezek közül mit használunk.
    Ezért fontos, hogy ítéletalkotás előtt megismerjük az adott rendszert, és ne csak "játszadozzunk" (az idézet tőled) vele. Egy eszközt csak akkor lehet megfelelően használni, ha feladatot és az eszköz tervezőinek gondolatmenetét egybe tudjuk fésülni - és ez a fejlesztői munka, a többi inkább csak szakmunka (betanított értelmiségi - a'la Para-Kovács).

    A string-es példához visszakanyarodva: a kritikád alapja, hogy szerintem nem ismerted meg kellőképpen a rendszert (meg valszeg a hibaüzenetet sem értelmezted). CLX-et használva (nem VCL-t) a vezérlők string mezői WideString-ek - ez e könyvtár tervezői szempontjából pont a rugalmasságot célozza (a 16 bites karakterkészletekhez). Ha egyszerű string-eket akarsz használni (char * vagy hasonló), akkor szkség van konverzióra. A help-ből kb. 5 perc kiszedni, hogy a WideString-nek nincs c_str() metódusa, az AnsiString-nek van, az az AnsiString-nek van egy WideString-et váro konstruktora. Innen egyszerűen jön: char *s = AnsiString(Edit1->Text).
    Hogy miért van szükség a string-ek megkülönböztetésére, arról inkább az ASCII kitalálóit is terjesztőit kellene kérdezni - ez szerintem nem a Borland-osok sara. Ők megpróbáltak egy adott feltételrendszerhez (8 és 16 bites string-ek) egy általános megoldást adni - és mint minden ilyen megoldás, ez is egy trade-off. Az egyedi esetekben szinte senkinek sem pont jó, de összességében (adott feltételek mellett) elfogadható.
    Mutasd a teljes hozzászólást!
  • Nem az a baj hogy nem tudom mi az az ansistring illetve widestring hanem az hogy egy osztálykönyvtáron belül ezt illene egységesen használni. Azaz a TEdit.Text-nek illenék ugyanolyan típusúnak lennie mint a TLabel.Caption-nak vagy a Listbox.Items elemeinek. Persze lehet hogy ez naiv elvárás tőlem egy pár százezer forintos eszközzel szemben...

    Egyébként a "BCB-s kód" kifejezés jól rávilágít a lényegre: ennek nem is kell portolhatónak lennie. Te választottad, hogy ilyen kódot használsz (mármint a Builder-en belül is).

    Pontosan. Én választok - és nem választok ilyet. A krumplileves legyen krumplileves, a C++ pedig legyen C++ ne egy Object Pascal osztály tetején ülő __property-kel teletűzdelt szutyok.

    Másrészt a portolhatság nem azt jelenti, hogy az adott eszköz specifikumai más helyeken is értelmezhetőek, hanem hogy az adott eszköz ismeri és jól kezeli a szabványban definiált elemeket.

    Nem. A portolhatóság azt jelenti hogy ha te csinálsz egy kódot akkor azt minimális erőfeszítéssel át tudod vinni egy másik, az adott nyelvre fordítóval rendelkező platformra. BCB esetén erre esélyed sincs, max. azt teheted meg hogy leválasztod a program egy részét a BCB-ről, és az valóban portolható lesz. Csak az ezzel a baj hogy az egyik végén a GUI, a másik végén az adatbáziskezelés az ami ezt eléggé valószerűtlenné teszi.
    Azaz ezt max. úgy lehet megcsinálni ha nem csak a user interfészt de a data access layert is leválasztod az üzleti logikádról. Ilyet meg általában max az SAP szintű ERP-k csinálnak...

    Egyébként ez ilyen "mindent egyben" portolhatóság az erre szánt könyvtárakkal sem megy feltétlenül minden esetben: a makefile-t gyakran az adott platformhoz kell igazítani.

    Erre a problémára találták ki a configure scriptet . De az sem mindegy hogy portoláskor egy makefile-t kell átírni vagy az egész programot. A gondom az ezzel hogy a dolog elvben sem portolható Pl. gcc/linux-ra, mivel maga az alap osztálykönyvtár tartalmaz olyan dolgokat (lásd __property) amit a BCB-n kívül semmilyen más fordító nem tud lefordítani. És ebből a szempontból a BCB fejlesztői vannak a világon a legkiszolgáltatottabb helyzetben: delphi fordítók léteznek a borlandos implementáción kívül is (lásd Free Pascal, de még ezen kívül is van legalább kettő), C#, java fordítók is létezik többféle, ugyanakkor a BCB C++ kódját semmi más fordító nem tudja lefordítani csak a BCB.

    A Kylix érdekes kérdés: én két évig dolgoztam vele, a néhány hiba kiismerése után szerintem nincs vele gond (ezek sem olyan eget rengetőek - hogy a delphi-s példádnál maradjak: én csak a 3-400-as formszámig jutottam el, nem volt vele probléma - ahgy az intenzív többszálúsággal sem, még a debug is megfelelő).

    Tény hogy a Delphi CLX-e jóval bugosabb mint a Kylixé, ugyanakkor a wine alapú IDE implementáció egyre inkább gázos. Tavaly ilyenkor még elment, de a 2.6.10 feletti kerneleken egyszerűen lehetetlen debuggolni, de már előtte is LD_ASSUME_KERNEL és más hasonló trükkök kellenek, és néha elég érdekes effekteket tud produkálni (Pl. időnként belefagy a fájl megnyitásba meg ilyenekbe). De a Pascal IDE még nem is annyira veszettül rossz, a C++ IDE sokkal problémásabb, azt már a tavaly ilyenkori disztribeken sem tudtam életre kelteni (amikor utoljára sikerült akkor az LD_ASSUME_KERNEL melett át kellett állítani a include keresési sorrendet meg valamelyik libet is ki kellett cserélni egy régebbire ha jól emléxem, ez úgy 3 éve volt, utána többször már nem sikerült életre hozni).

    És megértem őket, hogy nem az a mánuájuk, hogy minden héten nyomogatják a make/make install stb. parancsokat és nézik, hogy most is megy-e a dolog - ennél jobb dolguk is lehet.

    Na ja, amikor utoljára néztem a quality centert volt benne pár száz bug aminek a javításába még bele sem kezdtek. Nem ez a baj, hanem az hogy utána sz...tak az egész termékvonalra. Ugyanúgy egyébként ahogy a BCB-re is, csak aztán valamiért megint előszedték a dolgot, talán rájöttek hogy .NET vonalon úgysem igen tudnak labdába rúgni a Visual Studió mellett Persze lehet hogy úgy 5 év múlva amikor már senki sem használ CLX-et majd eszükbe jut hogy kiadjanak belőle egy új verziót
    Mutasd a teljes hozzászólást!
  • Ha tényleg ez volt a bajod, akkor tipikusan abba a helyzetbe kerültél, amikor valami nem a te elképzelésed szerint megy (és ennek kialakításához még nem biztos, hogy minden információd megvolt), aztán rávágod, hogy "rossz". Többnyire a hibaüzenet értelmezése is elég ilyen helyzetekben (O.K., ez C++-ban néha nehézkesebb lehet, nem az a szájbarágós fajta), meg nem árt a help-et sem használni. Jelen esetben az AnsiString és WideString közötti megkülönböztetésnek megvannak az okai (és ezt jó látni, mert leggyakrabban az okok nem megfelelő ismerete okozza a legnagyobb frusztrációt - és a rugalmasság bevonása egy rendszerbe ezt gyakran magával vonja), és a kettő közötti transzformálhatóság a doksi alapján könnyen kihámozható. Személyes véleményem, hogy pont az ilyenek miatt lehet szükség az "igényes programozók" kifejezésre (hogy egy Index fórumot idézzek): a hatékony munkához nem elég ismerni a felületeket, valamilyen szinten bele kell látni a tervezők gondolatmenetébe is. (Sanyinak, a melósnak nem kell ismernie sem az elektromos áram, sem a kompresszor jellemzőit ahhoz, hogy a légkalapáccsal feltörje a betont - aztán legfeljebb anyázik, ha nem megy a dolog. A főnökének viszont nem árt belelátni ezekbe, hogy csak olyan munkát vállaljanak el, ami megvalósítható az adott eszközzel).

    Egyébként a "BCB-s kód" kifejezés jól rávilágít a lényegre: ennek nem is kell portolhatónak lennie. Te választottad, hogy ilyen kódot használsz (mármint a Builder-en belül is). Ez arra hasonlít, mintha azt mondanám, hogy a QT-hoz szükséges QT_OBJECT makrók miatt nem megy a kód mindenhol: persze, ennek ismerete az adott platform feladata - amire vagy képes, vagy nem.
    És a Builder-ben ez nem is volt cél, ezt számon kérni szerintem értelmetlen.
    Másrészt a portolhatság nem azt jelenti, hogy az adott eszköz specifikumai más helyeken is értelmezhetőek, hanem hogy az adott eszköz ismeri és jól kezeli a szabványban definiált elemeket. Ezzel pedig nincs baj a Builder-ben (sem): a szabvány C++ kódot elég jó mértékben feldolgozza (100%-os fordító még talán ma sincs). A Builder által nyújtott szolgáltatás (pl. az eseménykezelők) _lehetőség_, amivel nem kötelező élni.

    Másrészt ha a programod lényegét (algoritmusok - adatszerkezetek) portolhatóvá akarod tenni és emellett használni akarod az eszköz nyújtotta (szerintem kénylemes) lehetőségeket, akkor azért fejlesztői oldalról is tenni kell és szét kell választani ezek megvalósításait.
    Én ilyen esetekben azt csinálom, hogy nem az OnCalcButtonClick-be írom a tényleges számítást (bármilyen csábító is), hanem csinálok egy új modult, ebbe csak szabványos C++-t írok (struktúrák, függvények), és az itt definiált függvényt hívom a "Builder-függő" részből. Nekem ez mindíg bejött, mert a programjaim jelentős részét ezek tették ki (meg a modularitás amúgy sem hátrány).
    Egyébként ez ilyen "mindent egyben" portolhatóság az erre szánt könyvtárakkal sem megy feltétlenül minden esetben: a makefile-t gyakran az adott platformhoz kell igazítani. Most akkor miért pont itt húzzuk meg a határt abban a kérdésben, hogy egy program portolhatósága milyen elemek módosítás nélküli használatát jelenti.

    A Kylix érdekes kérdés: én két évig dolgoztam vele, a néhány hiba kiismerése után szerintem nincs vele gond (ezek sem olyan eget rengetőek - hogy a delphi-s példádnál maradjak: én csak a 3-400-as formszámig jutottam el, nem volt vele probléma - ahgy az intenzív többszálúsággal sem, még a debug is megfelelő). Ezzel inkább tipikusan az a baj, ami szerintem a Linux-szal általában: a Borland megpróbálta magát tartani egy felülethez, de az alatta lévő dolgok - hála a folytonos buherálásnak - lassan megváltoztak (kernel fícsörök - interfész). És megértem őket, hogy nem az a mánuájuk, hogy minden héten nyomogatják a make/make install stb. parancsokat és nézik, hogy most is megy-e a dolog - ennél jobb dolguk is lehet.
    Mutasd a teljes hozzászólást!
  • Talán elsőként a "jelenlevőket" felvehetnéd egy tájékoztató hírlevélre.
    Igy talán könnyebben kapcsolódhatnak be, ha nem is fejlesztéssel, de lektorálássál, témafelvetéssel, cikkekel, saját forrásokkal támogatva a melót.

    eMeL
    Mutasd a teljes hozzászólást!
  • Kiegészítem előző soraimat, a csomagban fellelhető még ez a csoda is: Inklusive Kylix 3 Professional
    Mutasd a teljes hozzászólást!
  • Szia!

    A doksi külön IS megvásárolható, természetesen angol nyelven is:
    Doku Borland C++ Builder 6 Manual

    Sprache: deutsch
    Ausstattung: Box
    Seitenzahl: 2100
    Bestellnummer: BOR290
    erschienen: 03/2002
    Preis: EUR 59,95 (inkl. MwSt.)
    lieferbar in: 2-3 TAGE


    Der Handbuchsatz besteht aus: Borland C++Builder Entwicklerhandbuch Band 1 & 2. Das Entwicklerhandbuch enthält Informationen über mittelschwere Programmiertechniken. Dazu gehören das Erstellen von Client/Server-Datenbankanwendungen, das Entwickeln von benutzerdefinierten Komponenten, das Erstellen von Web-Server-Anwendungen und das Bereitstellen von Standardspezifikationen wie SOAP, TCP/IP, COM+ und ActiveX.

    Az én olvasatomban ez azt jelenti, hogy az 5-ös változat embertelen vastag, szinte kézbevehetetlen papírkötegét simán csak ketté vették. A bevezető könyvecskét pedig egyszerűen kihagyták. Mondjuk ez utóbbi valóban értéktelen volt.

    Most olvastam egy olyan akcióról, hogy amennyiben upgradelsz egy 6-os Builderre, megkapod a nyomtatott doksit, a D 2005 Prof-ot, továbbá egy másik BCB könyvet.
    Akkor melyik változatot szeresse most szegény Borland függő bitvadász ?

    Üdv: Karcsi
    Mutasd a teljes hozzászólást!
  • Őszintén szólva kb. akkor játszottam utoljára a bcb6-tal amikor kihozták, lehet hogy nem pont ebbe de valami hasonlóba futottam bele, valami alapvető helyen a VCL egyik komponense AnsiStringet adott vissza a másik pedig valamilyen más Object Pascal-os stringet várt, már nem emléxem melyiket (talán WideString ?). Mindenesetre míg ez a dolog Object Pascal-ban nem okozott problémát, C++-ban igen. Ami pedig azt jelenti hogy a VCL-t ilyen szempontból nem igazán nézték át Borlandnál. Ami mondjuk nem olyan nagy tragédia ahhoz képest hogy Pl. a CLX-ben a Delhi7 TPrinter objektuma nem igazán reagál az orientation beállításra meg pár más hasonlóan "kellemes" dologhoz, de azért elég gusztustalan. Amúgy a Pascal legalább olyan szigorúan típusos mint a C++, de speciel ezt a konverziót megeszi.

    Nos, nekem a Builder-en kívül volt szerencsém elég sok fordítóhoz elég sok környezetben, és ha valakivel hiba volt a C++ kompatíbilitást illetően, az leginkább a (")Visual(") Studio volt (legalábbis a 6-osig).

    Nekem igazából a szabványossággal az volt a bajom hogy egy BCB-s kódot az életben nem fogsz tudni portolni más platformra, azaz a C++ egyik fontos tulajdonságát, a portolhatóságot veszíted el. Pont a VCL és a __property és más hasonló gyönyörűségek miatt. Én anno elég sok C++ kódot írtam gcc-vel és wxWidgets-szel, nost az valóban C++ volt ,bár az sem az STL-t használta hanem saját string könyvtárat, de azt a programot le lehetett fordítani szinte mindenhová bármilyen fordítóval.

    Az, hogy nem "fejlesztik", nem feltétlen ellenérv: nem akarom a Candide-ot idézni, és nem ez a világok (fejlesztőkörnyezetek) legjobbika, de alapvetően ebben a témában milyen nagy durranást lehetne csinálni?

    Ez mar nem teljesen igaz, a Delphi 2006-ban állitólag már ismét van C++ builder, igaz csak win32-es kódot tud fordítani.

    Én úgy látom, a Borland-nak ezzel most pont az a baja, hogy túl jól dolgozott és most nincs mire azt mondani, hogy "már jön az újabb, a jobb, sok hibajavítással"

    Nos, maga a C++ fordító annyira nem volt rossz, picit lassú, de hát a gcc sem gyorsabb. A VCL olyan amilyen, viszont maga BCB6 a fejlesztőkörnyezet mai szemmel nézve vérgagyi. A form designer még csak-csak, bár ami azt illeti van open source-os cuccos ami jobb nála, de az IDE az egy vicc. Még egy nyomorú zárójelkiemelés sincs benne nemhogy refactoring. A D2k6 már ígéretesebbnek tűnik de én a magam részéről inkább átálltam C#-ra és .NET-re arra pedig a Visual Studió 2k5 jobbnak tűnik.

    Arról nem szólva hogy a Kylixos kaland után jó ideig nem veszek borlandos terméket a kezembe...
    Mutasd a teljes hozzászólást!
  • LC!
    A hivatkozott példát legalább kipróbálhattad volna - és akkor keresel egy újat, ami igaz is. A VCL objektumok kapcsolata pontosan olyan jó, mint a Delphiben - sőt, ha cast-olásokról van szó, akkor én jobban bízom a C++ szigorú típuskezelésében (nem beszélve a nem felületet illető dolgoról, amik egy programban legalább olyan fontosak, így pl. az STL tárolókról).

    Egy előbbi hozzászólásodban kitértél a gcc-"szabványos fordító" témakörre. Nos, nekem a Builder-en kívül volt szerencsém elég sok fordítóhoz elég sok környezetben, és ha valakivel hiba volt a C++ kompatíbilitást illetően, az leginkább a (")Visual(") Studio volt (legalábbis a 6-osig). Igen sok kódot csináltam a Builder-rel (még csak nem is a legújabb 6-ossal), amiket aztán más fordítóval (és más platformon) használtam - hiba nélkül. Ennek egyik motiváló oka pontosan a fejlesztőkörnyzet volt - szerintem az egyik legjobb (programozói) editor van benne, és a debug is nagyon kézre áll (bár ez mindig vitára ad okot, ki mihez mennyire szokott alapon).
    Az olyan speciális elemek, mint __property, __fastcall (esetleg a PACKAGE) és társaik soha nem is tartoztak a sztandard C++-hoz, nem is fognak (egyébként pl. a gcc-nek is vannak ilyen elemei (pl. packed), amit vagy használsz, vagy nem, rajtad múlik), és kizárólag ott van rájuk szükség, ahol az IDE-nek is van köze a dolgokhoz - ez gyakorlatilag csak a felület (legalábbis szerintem annak kellene lennie) - és ezt nem is minden esetben kötelező használni. Egy rendes programban az adatszerkezetek és a felület szét vannak választva, már csak tesztelés vagy többszemélyes fejlesztés miatt is (tudom ajánlani másoknak is: John Lakos: Large Scale C++ Sotfware Design)

    Az, hogy nem "fejlesztik", nem feltétlen ellenérv: nem akarom a Candide-ot idézni, és nem ez a világok (fejlesztőkörnyezetek) legjobbika, de alapvetően ebben a témában milyen nagy durranást lehetne csinálni? Én úgy látom, a Borland-nak ezzel most pont az a baja, hogy túl jól dolgozott és most nincs mire azt mondani, hogy "már jön az újabb, a jobb, sok hibajavítással" - pl. a VC++ 6 után ezt nem volt nehéz megtenni. És a dolog még ekkor sem egyértelmű, lásd az anomálikákat a 3.0.0-s gcc-vel.
    A komponensszerkezet kiváló arra, hogy ezzel ne csak a Borland foglalkozzon ("the guys out there" - ahogy David I mondta), a C++ kompatíbilitásban sincsenek olyan nagy hibák. Végül is máshol sem történnek olyan nagy dolgok, a C++ alapszemléletének megfelelően megvan egy rugalmas alaprendszer, amire jó könyvtárakkal lehet programokat építeni - és szerintem is ez a fontos, egy alkalmazáshoz ne egy adott rendszer megoldásaira legyen utalva a fejlesztő, hanem válogathasson olyan (általános) megoldások között, amelyek illenek az ő egyedi problémájára. Na ja, ez némi rálátást igényel a fejlesztőtől is, nem feltétlenül elég összekötni a feladat nevét a rendszernek azzal az elemével, amiben ez a név szintén szerepel.
    Mutasd a teljes hozzászólást!
  • Attól függ mit akarsz csinálni. A BCB ügyvitelre jó, de arra meg szvsz a C++ nem az igazi. Inkább Java vagy C#. Ráadásul szvsz a BCB elég szerencsétlen egy jószág: az objektum-hiereachia amire épül az a VCL ami Pascal-ban van írva. De amíg a Pascal egy rakás dolgot automatikusan konvertál (Pl String, AnsiString, stb) ezt C++-ban csak castolással lehet megoldani, így Pl. egy label1->caption=edit1.->text konverzióhoz is ez kell. Legalábbis ha jól emléxem a BCB6 környékén voltak ilyen szépségek... Ha már Borland akkor inkább Object Pascal.
    Mutasd a teljes hozzászólást!
  • Nem tartozéka egyik sem.
    Mutasd a teljes hozzászólást!
  • Tudja-e valaki, hogy a bolti, dobozos, jogtiszta, eredeti, stb. BCB Prof. 6-os csomagnak tartozéka-e a Referencia kézikönyv, illetve az Objektumok hierarhia térképe?
    Mutasd a teljes hozzászólást!
  • Üdv,

    a BCB oldal engemet is érdekel. Már régóta rágódom azon, hogy váltsak-e fejlesztőeszközt. A Borland trehányul kezeli a BCB. Pascalért v. Javaért nem szívesen hagynám el a C/C++-t.Így maradtam BCB-s.
    Mutasd a teljes hozzászólást!
  • Üdv Mindenkinek!

    Teljes mérékben igaza van LCnek. Érdemes megnézni a hivatalos Borland hírcsoport Non-technikai listájának a BCB-vel foglalkozó levelezését.
    A fejlesztők totál ki vannak bukva, a borlandos mókusok meg kábítják a népet. gyakorlatilag, amennyiben az új Delphi-vel nem jeleneik meg egy ütőképes új BCB, el lehet a SZEMÉTBE DOBNI jó kis megszokott proginkat, meg a befektetett energiánk nem kis részét !
    Üdv: Karcsi
    Mutasd a teljes hozzászólást!
  • Na ja, tök jó lenne egy BCB híroldal, teli lenne vadiúj hírekkel.
    Pl. Megjelent a BCB6...

    Mert kb. ez volt az utolsó hivatalos hír a BCB vonallal kapcsolatban. Komponensek vannak rá, többnyire azok amiket a jó öreg Delphi6-ból portoltak, igaz ezek a komponensek általában Object Pascal-ban íródtak, hasonlóan az egész komponens osztályt adó VCL-hez, de azért C++ rulez...

    Szvsz a BCB az a termék amire az égvilágon semmi szükség nincs. A C++ nem az a kimondottan RAD-orientált dolog, amit C++-ban ír az ember (Pl. adatbázisszerver, játék, stb) ahhoz nem RAD kell hanem egy jó IDE. Viszont a Borlandos IDE minden csak nem jó, annak egyedül a RAD-dal egybeépítve van értelme.

    Amit meg RAD-ban kell csinálni (Pl. 1000 formos ügyviteli szoft) arra sokkal szerencsésebb az Object Pascal mint a C++, különösen ha figyelembe veszed a fordítási időt. Ráadásul a BCB mindig mostohagyerek volt a Borlandnál, afféle rút kiskacsa aki mindig legalább félévvel az aktuális Delphi után jött ki. Plusz a vele írt C++ nem igazán C++, annak hogy ezt lefordítsd egy gcc-vel vagy más szabványos C++ fordítóval kb annyi esélye van mint a .NET-es managed C++-nak ami windows.forms-t használ... Ami azt illeti az Object Pascal ebből a szempontból még jobb, azt legalább a Free Pascal fordító megeszi linuxon, de a BCB6 C++ nyelvjárását (Pl. _property) rajta kívül más nemigen eszi meg. Max. a Kylix-szal lehet kísérletezni, de abból az utolsó változat kb egyidős a BCB6-tal, és úgy tűnik hogy a ... borland teljesen leállította ezt a vonalat
    Mutasd a teljes hozzászólást!
  • Én már nem csinálom, elvileg TomX csinálja nem tudom kivel (talán egyedül). Szóval minden kérdést hozzá.
    Mutasd a teljes hozzászólást!
  • No!
    Annó gondoltam, hogy írok, de aztán elkallódtam, és csak most találtam meg ismét ezt az oldalt...
    Király gondolat, de asszem már tart valahol a projekt nem? Hol?
    Ha be lehet szállni valamivel, akkor szólhatnál...
    Viva Builder!
    Mutasd a teljes hozzászólást!
  • Hello!

    Ők már nem foglalkoznak BCB-vel ezért abbahagyták.

    De jelentem halad!
    Ha egy hónapon belül nem leszek készen vele akkor főbelövöm magam.
    Mutasd a teljes hozzászólást!
  • Hella! Halad még a portál készítése? írtam mailt...
    Mutasd a teljes hozzászólást!
  • Lefoglaltam a tárhelyet, a címe jelen állapotok szerint ez lesz: http://bcbportal.uw.hu

    Egy designer jelentkezése megkönnyíteni a dolgunkat, ha valakinek van egy kis ideje és kedve, akkor szóljon.
    Mutasd a teljes hozzászólást!
  • saabi:
    Röviden ilyenekre gondoltam:
    - hírek
    - komponensek
    - Tippek & Trükkök
    - Linkek
    - Fórum
    - Cikkek
    - Hírdetések
    - Programok

    Lehetne arra is lehetőség hogy a regisztrált tagok, tippeket és komponenseket tölthessenek fel stb.

    Mindent jól kategórizálva, fejlesztő nevével és egyéb információval ellátva lesz az oldalon. Szavazni lehet az egyes dolgokra, és véleményt hozzáfűzni.

    CHM:
    Igen, eddigi tapasztalataim szerint elég kevés delphi cuccot evett meg.
    Az oldal csak BCB fejl. környezettel fog foglalkozni.
    A weboldal PHP-s portál motorjára elvilág már van ember. Egy designer kellene még, meg további emberkék, akik egyéb feladatokban tudnának segíteni.
    És szívesen fogadok/fogadunk minden irányú segítséget.
    Mutasd a teljes hozzászólást!
  • Jó ötlet. Ha készül ilyen oldal, én írok rá

    Meglátásom szerint nagyon kevés BCB-vel foglalkozó weboldal van. (delphi-s oldalakkal meg már Dunát lehet rekeszteni)


    Talán azért, mert a Builder (jól-rosszul) megeszi a Delphi-s komponenseket. Fordítva viszont ez nem igaz.

    Amiről viszont tényleg kevés infó van, az a VCL és a C++ kacsolata, ill. az e környéken lévő buktatók.

    Az oldal fejlesztésében nem igazán tudnék közreműködni (html-es ismeretek és idő hiánya miatt), de ha készül ilyen oldal írok rá, az biztos.

    Ha itt lenne a fejlesztőeszközök közt Builder-es kategória, az sem lenne rossz, de hát Sting erre (kb 1 ébve) nem volt vevő.
    Mutasd a teljes hozzászólást!
  • Hello!

    Segítek én is szívesen, ha tudok. Van vmi konkrét elképzelésed is a tartalomról? Milyen "rovatok" lesznek az oldalon?

    Üdv.
    Szabi
    Mutasd a teljes hozzászólást!
  • Hát nem szeretnék kihalt oldalt. Majd ha elkészül lesz hirdetve. Vagy az UW-re, vagy a Fw-re lesz feltöltve.

    Ha tényleg érdekel a dolog, akkor írj valami elérhetőséget, MSN cím lenne a legjobb.
    Mutasd a teljes hozzászólást!
  • Én benne vok! De hova raknád fel, hol hirdetnéd? Ez is egy kihalt oldal lenne, vagy megfűznéd a prog.hu teamot?
    Mutasd a teljes hozzászólást!
  • Nem, nem ismertem.
    Ilyesmire gondoltam, de ennél jobbat. Komponensek látom vannak ott, elég sok, de más nagyon nincs rajta. Meg kicsit halottnak tűnik az oldal, de lehet, hogy csak én látom így.
    Mutasd a teljes hozzászólást!
  • Ezt ismered?

    Hasonló ahhoz, amit te gondolsz. De az sosem baj, ha a jó dolgokból több is van....
    Mutasd a teljes hozzászólást!
  • Hali!

    Ha C++ Builder-ben szoktál programozni, vagy ismered a BCB-t, akkor olvasd el az alábbi pár sort.

    Meglátásom szerint nagyon kevés BCB-vel foglalkozó weboldal van. (delphi-s oldalakkal meg már Dunát lehet rekeszteni)
    Éppen ezért arra gondoltam, hogy létre kellene hozni egy nagy BCB-el foglalkozó oldalt (komponensek, tippek, függvényes, fórum stb).

    Viszont egyedül kicsit nagy falat lenne mindent megcsinálni és fenntartani, ezért keresek vállalkozó egyéneket, akik benne lennének ilyenben. Biztos, hogy jól meglennénk.

    Ha kedvet kaptál, vagy kérdésed van, akkor írj ide, vagy e-mailre a blackcat@invitel.hu címre.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd