VC++ vagy C++Builder?
2003-09-09T11:12:14+02:00
2003-09-24T21:02:05+02:00
2022-07-27T17:07:31+02:00
  • Igen ezek alapdolgok, de mostmár kiválasztottam a C++ Buildert, és nem volt új forumot nyitni kedvem. Kösz, minden működik, már csak 1 kérdés:
    OpenGL-ről valami online doksi?
    Mutasd a teljes hozzászólást!
  • Ezek alapdolgok.
    A legjobb minden deklarációt egy .h fájlba berakni, de a fügvényeket (az osztályokét is) egy .cpp -ben Aminek az elejében ott kell lennie az illető headerre utaló
    #include " .h" -nak.
    A legegyszerűbb Builderben a New / unit menüpontot választani, ez létrehoz .cpp-t , .h-t ,mindent.
    És Az előbbieket követve mindenhova ahol szükséged van a fügvényekre be kell írni az includot.
    De vigyázz! a változókat mindíg valamelyik .cpp -ben deklaráld.
    Ha több helyen is szükséged van rá akkor
    Például: int a;
    Az öszzes többi helyen: extern int a;
    Az extern class is használható.
    Unit1.cpp -ben ha mondjuk Form2->Caption -ra akarsz hivatkozni akkor az elején írd be, hogy #include "unit2.h"
    Ilyen egyszerű

    2 és 3D hez egyaránt jó az OpenGL
    A Hogyan Programozzunk C++Builder Rendszerben című könyv CD mellékletén minden rajta van róla.
    Mutasd a teljes hozzászólást!
  • C++ Builderben hova kell tenni a változó és a class deklarálást ahhoz hogy a programban mindenhonnan(minden cpp és h fileból formból, mindenből) használható legyen?

    Hogy lehet az egyik Form-ról a másikra, pontosabban a másik Form cpp- file-jában zajló dolgokra utalni, fügvényeket meghívni?

    Hogy lehet gyorsan 2D, 3D-t rajzolni, milyen componens-el vagy módszerrel?
    Mutasd a teljes hozzászólást!
  • A C++ - mint nyelv - tekintetében mindegy. A legjobb C++ könyvtárak (példa: libcrypt) itt is, ott is mennek, tehát emiatt is mindegy. Ha a Windows tehnnológiára kihegyezett programozás a lényeg, akkor viszont a véleményem a következő:
    Én 1986 óta használok Borland eszközöket és egészen 2001-ig az volt az érzésem, hogy az MS cuccai sehol sincsenek. Azonban a Visual Studio .NET szerintem jobba lett, azaz megtört a jég. Valszeg a gond az, hogy a Borland is csak követni tudja az MS technológiáit. A Borlandos .NET lehet, hogy jobb (lesz), nem ismerem még. A Borland Kylix-nak 3 (ami mostmár C++-t is tud) viszont van egy nagy előnye: Linux-on is működik. Ezt viszont az MS Vis. .NET nem mondhatja el magáról.
    Mutasd a teljes hozzászólást!
  • Hát, ha kétségeid vannak akkor szerintem te is próbáld ki a kódot amit küldtem...
    Mutasd a teljes hozzászólást!
  • Akkor kicsit felremagyaraz az MSDN :

    "SetTimer
    ...
    If lpTimerFunc is NULL, the system posts a WM_TIMER message to the application queue. The hwnd member of the message'sMSG structure contains the value of the hWnd parameter.
    ..."

    "WM_TIMER
    The WM_TIMER message is posted to the installing thread's message queue when a timer expires.
    You can process the message by providing a WM_TIMER case in the window procedure. Otherwise, the default window procedure will call the TimerProc callback function specified in the call to the SetTimer function used to install the timer.

    Remarks
    The WM_TIMER message is a low-priority message.
    The GetMessage and PeekMessage functions retrieve this message only when no other higher-priority messages are in the thread's message queue. "

    Bar az konnyen lehet hogy ezt inkabb a hasznalathoz irtak le, mintsem hogy osszezavartak volna az 1ugyu fejlesztoket,
    es tenyleg nem kerul tenylegesen uzenetsorba az WM_TIMER, de akkor nem latom be miert csinaltak egy masik implementaciot egy standard mukodeshez...

    Az mindenesetre biztos hogy ha nem adsz meg hWnd-t csak proc-t akkor a foszallat leszamitva magadnak kell gondoskodni a dispatch-rol... legalabbis MFC app-nal tuti, ui. ket hete csinaltam ilyet !
    Mutasd a teljes hozzászólást!
  • Meggyozo volt.
    Mutasd a teljes hozzászólást!
  • Csináltam neked egy kis tesztkódot. Remélem nem kell részletesen elmagyarázni mit csinál.
    var H: HWND; Cnt: integer; Msg: tagMsg; begin H:=CreateWindow('STATIC',nil,0,0,0,0,0,0,0,0,nil); Win32Check(H<>0); Win32Check(SetTimer(H,1,500,nil)<>0); Sleep(5*1000); // ez ido alatt cirka 10 db WM_TIMER-nek kellene keletkeznie Win32Check(KillTimer(H,1)); if PeekMessage(Msg,H,WM_TIMER,WM_TIMER,PM_REMOVE) then ShowMessage('Sting tévedett') else ShowMessage('Stingnek igaza volt. A WM_TIMER csak on-the-fly generálódik.'); DestroyWindow(H); end;

    A Sleep()-et kicserélheted/kiegészítheted egy üzenetfeldolgozó ciklussal is, vagy bármilyen más várakozással ami alatt a rendszernek bőven lenne ideje WM_TIMER-eket az üzenetsorba pakolni.

    Szintén kipróbálhatod, hogy mi történik akkor ha a PeekMessage() előtt valahol egy
    Win32Check(PostMessage(H,WM_TIMER,1,lParam(nil)));

    üzenetet raksz be az üzenetsorba, vagy ha a KillTimer()-t a PeekMessage() utánra mozgatod (értelemszerűen ezek esetében a kiírt üzenet nem megfelelő).
    Mutasd a teljes hozzászólást!
  • Nincs két kezelési módja, mert mindenképpen üzenetként jelenik meg. A timerproc abból a szempontból érdekes, hogy ha ez a mezője az üzenetnek ki van töltve, akkor az alapértelmezett üzenetkezelő (ha megkapja) meghívja az adott címen kezdődő callback-rutint. (Ez utóbbi feature-en alapul a nem is olyan régen kicsit túldramatizált WM_TIMER sebezhetőség.) Ha nincs megadva timerproc, akkor az alkalmazásnak magának kell a saját üzenetkezelőjében a timert azonosítania, és a megfelelő akciót végrehajtania hozzá.

    Amiről én beszélek az az, hogy WM_TIMER üzenet sosem kerül be az üzenetsorba (mármint a Windows sosem rakja bele, mert nyilván lehet postázni ilyen üzenetet alkalmazásból is, ami belekerült), hanem mindig on-the-fly generálja, amikor szükség van rá. Az alkalmazás ettől függetlenül természetesen úgy látja mintha az üzenetsorból jönne - de nem onnan jön, és ezért "viselkedik" néha furcsán. A WM_TIMER-en kívül egyébként van még néhány más üzenet is ami így működik (pl. WM_PAINT, bár ezt is lehet explicit postázni).

    Ha nem hiszel nekem, olvasd el a megfelelő dokumentációkat!
    Mutasd a teljes hozzászólást!
  • "A WM_TIMER nem kerül az üzenetsorba"

    Attol fugg. Ket kezelesi modja van aszerint, hogy van-e megadva timerproc. Ha nincs, akkor az uzenetsroba kerul.
    Mutasd a teljes hozzászólást!
  • A WM_TIMER nem kerül az üzenetsorba, hanem on-the-fly generálja a Windows - de amúgy igazad van.
    Mutasd a teljes hozzászólást!
  • + nezd meg a Multimedia timer-t, ez lehet hogy jobb lesz neked, foleg jatekhoz, ui. nem a foszelban fut, hanem sajat thread-je van!
    timeSetEvent es tsai.!
    Mutasd a teljes hozzászólást!
  • Egyébként A TTimer lassúsága a builder sajátossága vagy csak rossz eszközt használok. Uganis elég ciki egy RealTime


    Szerintem maga a TTimer nem lassu, ill. nem a komponens lassu. Max az lehet a gondod hogy a Windows timer-e nem garantalt, azaz hiaba allitassz be mondjuk 10 msec-es idozitest az nem garantalt hogy 10 msec elteltevel fog vegrehajtodni. Sot egesz pontosan csak annyit garantal a rendszer hogy egyszer vegre fog hajtodni, mivel az adott ido leteltevel egy WM_TIMER uzenet kerul az alkalmazas uzenet soraba, ami gyk. a foszalon lesz vegrehajtva ha sorra kerul !
    A Windows (egyik verzio sem!) az nem real-time oprendszer, bar gyanitom hogy neked nincs is igazan erre szukseged... ui. ha pl. tul hosszu az OnTimer alatt elvegzendo feladat mar az is keslelteti a kovetkezo timer esemeny vegrehajtasat !
    Mutasd a teljes hozzászólást!
  • Nekem C++Builder5-öm van.
    Még nem foglalkoztam sokat VC++ al de nem állnék át könnyű szívvel.
    A Builder elrejt egy csomó kódót amitől a VC++ ban kirázott a hideg, és a felülete is jobb a Buildernek.
    OpenGL -t vagy DirectX -et használó programok esetében is megállja a helyét.
    Sajnos arra mék nem sikerült rályönnöm hogy hogyan készíthetnék hibátlan lekerekített szélű ablakokat.(ez még apróbb hibákkal is nehézkes Builderben)
    Egyébként A TTimer lassúsága a builder sajátossága vagy csak rossz eszközt használok. Uganis elég ciki egy RealTime
    -os játéknál a 10-20 FPs.

    Tom
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Honnan tudnám leszedni a C++ Builder -t ingyen? :)
    Mutasd a teljes hozzászólást!
  • Az elolvasottak alapján azthiszem nekikzedek a C++ Buildernek, aztán meglátjuk mi sül ki belőle. (pillanatnyilag az 5 van meg).

    Hogyan érdemes gyorsan változó grafikát csinálni? (nem hiszem hogy a canvas->lineto() a legjobb megoldás...)

    Mindenkinek kösz az eddigi és jövőbeni segítséget.
    Mutasd a teljes hozzászólást!
  • VC6 vs C++ Builder 6
    Sebesség1:
    VC6 -ot próbáltam használni valamikor. Kínszenvedés benne GUI-t művelni. Végül még egy oktatási anyagot is el kellett olvasnom az MFC-ről, mire kb. felfogtam hogy is gondolja ezt az MS. Ezután sem lett könnyebb.
    Builder6: 5 perc használat után gond nélkül megy minden.


    Sebesség2:
    C++ Builder6: Az előző gépemen majd elaludtam egy-egy kódkiegészítésre várva, vagy amíg megtudtam egér föléhúzással egy változó típusát. Újítottam 2.4-es P4-re, 512mega DDR-re. Még mindíg q*** lassú. Szerintem ez azért fontos, mivel egy nagyobb proginál az ember nem nagyon tudja fejben tartani az összes osztályának összes metódusát és adattagját.
    Mj: Delphi alatt nincs ilyen probléma.

    Sebesség3:
    Rengeteget teszteltem. A generált kód sebességében hol az egyik, hol a másik a jobb.

    Kód:
    VC6: a kód fele olyan makrókbol áll, amiket meg lehet ugyan érteni doksiolvasgatás után, de fölösleges, mert úgysem tanácsos hozzányúlni a generált kódhoz.
    Builder6: A kód nagyrésze olvasható és érthető.
    Én fontosnak tartom, hogy a kód olvasható legyen és ne legyen teletűzdelve bonyolult, ronda, olvashatatlan ... makrókkal.

    Szabványosság: (még mindíg a 6-os verziók)
    Builder SOKKKAL közelebb áll a C++ szabványhoz. Ezt nem felmérések mérőszámaira alapozom (x% vs y%), hanem programozói tapasztalatra.
    -Stroustrup "2D"-s vector létrehozása 1 sorban (már nem tudm hanyadik oldal): Builder megeszi, Visualban írhacc hozzá ciklust
    - for ciklus már említett hülyesége. Nagyon zavaró.
    - szabvány szerint egy függvény deklarációját utolsó körben paraméterei névterében is keresni kell. Visual nem teszi.
    - Ha jól emlékszem Visual az std névteret automatikusan behozza ha használsz valamit belőle. Ezzel gyakorlatilag elvész a névterek egyik fő funkciója.

    Persze a Builder is messze van a szabványtól.

    --------------------------------------
    C#: majdnem akkora fejlődés a jávához képest, mint a jáva a C++ -hoz képest.
    .Net framework: detto

    VC 7.1:
    .Net
    Gyors.
    GUI készítés ugyanolyan egyszerű, mint Builderben.
    MSDN
    Generált kód: gyönyörű :)
    futási sebesség: ellentétben azzal, amit lentebb írt valaki:
    NEM interprál a .Net. Natív kódot fordít futtatáskor a függvény első használatakor. Továbbá lehet előre is fordítattni, így gyorsabban "indul be" a progi.
    szabványosság:
    ~100%-ban szabványos a C# nyelvvel :)
    A (managed) C++ -t meg tessék elfelejteni .Net alatt. C++ -ban programozni a nyelv megerőszakolása.

    C# Builder-t még nem próbáltam, mivel a Visual-lal semmi bajom. De majd megnézem. El tudom képzelni, hogy nem sok különbség lesz köztük.

    PS: Mintha már írtam volna egy ugyanilyen topikba. Elöször azt hittem ez az, de aztán nem találtam itt a hozzászólásomat.
    Mutasd a teljes hozzászólást!
  • Hat ha a trial butabb, mint a rendes, az nagyon nagy hulyeseg a Borland reszerol.
    Mutasd a teljes hozzászólást!
  • A szépséghiba csak az, hogy enterprise trial-t próbált ki. Én a Delphi enterprise trial-t próbáltam, az le volt butítva a pénzes verzióhoz képest, valamint a kód is más volt, nem lehetett rátenni az időközben megjelent javításokat.
    Mutasd a teljes hozzászólást!
  • Ittvagyok még, csak 1-2 napot hagytam ki, most sietek majd még írok. Látom igen sok vélemény érkezet, kösz mindenkinek. Próbálom mindegyiket értelmezni.

    Egyébként rövidtávon a már említett közlekedési szimulációt kéne megcsinálni, valami grafikus felületen, mert prezentációt kell tartanom, és ott nemhiszem hogy értékelnék a karakteres képernyőn változó számokat.



    P.S.: hogy lehet letiltani hogy e-mail jöjjön az új bejegyzésekről? mert nagyon sok levelet kaptam, és nem látom hol lehetne letiltani...
    Mutasd a teljes hozzászólást!
  • 3. A C#Builder ben használhatod a VCL -t, tehát aki ehhez hozzászokott, annak hasznos lehet


    Áruld már el nekem hogy szerinted hogy lehet VCL-t használni C# builderben ? Mert nekem csak Windows.Forms alkalmazást sikerült csinálnom az Enterprise Trial-lel. Van ugyan pár plusz komponens (egy ComponentOne nevű cuccos, szvsz külső cég).

    4. A Microsoftban hosszútávon asszem jobban lehet bizni mint a Borlandban.


    Mindkettő nagyjából a .NET framework-re épít (azaz ugyanaz a komponens könyvtár, ugyanaz a fordítóprogram) úgy hogy itt szvsz a program szempontjából nagyjából mind1 hogy C# Builder vagy Visual Studió vagy Notepad.Exe az amivel a kódod előállítottad. Csak a fejlesztőeszköz ára és szolgáltatásai a lényegesek.
    Mutasd a teljes hozzászólást!
  • ..hát igen. az igazság az hogy én is csak VS.NET -et használok. 20 percet foglalkoztam C#Builderrel és jónak tünt. ez amúgy pár éve jellemző a Borlandra. Mármint, hogy nemfejezik be a termékeiket. Én pl. még mindig CBuilder5 -öt használok. A 6-os sokkal bugosabb.
    Mutasd a teljes hozzászólást!
  • C# Builder vs VS.NET
    Dr. Dobb's
    Mutasd a teljes hozzászólást!
  • És a Visual Studio .NET és a Borland C# Builder is hasonló viszonyban áll egymással? Melyikbe érdemes beletanulni?


    bocs, hogy ilyen későn reagálok a kérdésedre. ebben az esetben már teljesen más a helyzet mint a VisualC és a CBuilder összehasonlitásánál.
    1. A C#Builder és a VS.NET szinte ugyanolyan minőségü és mennyiségü szolgálktatást nyujt. Nagyon egyformák. Ha nemvagy figyelmes szinte észre sem veszed, hogy épp miben programozol :)
    2. A C#Builder mindig levan maradva egy nagyon picit, de ez asszem nem mérvadó
    3. A C#Builder ben használhatod a VCL -t, tehát aki ehhez hozzászokott, annak hasznos lehet
    4. A Microsoftban hosszútávon asszem jobban lehet bizni mint a Borlandban.

    Én inkább a VS.NET -et ajánlom, de ebben az esetben a .NET és a C# a lényeg. A fejlesztőkörnyezet nemannyira mérvadó.
    Mutasd a teljes hozzászólást!
  • Ezzel együtt szvsz sokkal lassabb mint Pl. egy Delphi, ugyanúgy ahogy a java. Azért szvsz mert nem csináltam tesztet, csak a look&feel-re tudok támaszkodni
    Mutasd a teljes hozzászólást!
  • "mert a Javahoz hasonloan egy koztes kodot fordit, amit egy kvazi interpreter vegrehajt, ezzel jelentosen csokkentve a hatekonysagot."

    Ez marhasag. A .NET nem interpretaltan futtat. Mire elkezd futni a kodod, addigra mar native kod lesz belole.
    Mutasd a teljes hozzászólást!
  • akkor is az IE-n belül vagy



    csak annyira mint az explore.exe, <ironia>ja hogy ossze vissza bele drotozva </ironia>

    a masodik felevel egyetertek
    Mutasd a teljes hozzászólást!
  • Mindegy, akkor is az IE-n belül vagy, az egész dolog sokkal kötöttebb és nehézkesebb mint ha egy Delphit használnék. És nem igazán látom azt hogy a végeredmény mivel lesz jobb mint egy hagyományos ablakozós cucc ?

    Másik dolog hogy ha webes user intefészt csinálnék és nem *nix alá akkor nem C++-t használnék hanem C#-t és .NET-et. Ha meg multiplatformot akkor java-t, rosszabb esetben PHP-t.
    Mutasd a teljes hozzászólást!
  • Az en velemenyem az, hogy mindket fejlesztokornyezet mas celcsoportoknak felelhet meg.

    Ugyebar a VC++ a MS termeke, ezaltal a Windows minden reszet legjobban ezzel lehet kiaknazni (gondolok itt az MFC-re meg egyeb dolgokra). Tehat ha olyan programot szeretne vki irni, ami erosen hasznalja a rendszer lehetosegeit annak tudom ajanlani. Tovabbi elonye egyebkent meg az MSDN konyvtar. Ebben minden eleg jol dokumentalva van.

    A C++ Builder egy nagyon jo fejlesztoeszkoz a gyors es hatekony programozashoz. Hasonlo egy kicsit a Visual Basichez, csak C++-szal. (A Delphi meg pont ugyanaz, csak Pascal forditoval). Sok jo komponenst adnak hozza, tenyleg nagyon gyorsan lehet vele fejleszteni. Ha a programod lenyege nem a rendszerszintu dolgokban van, akkor kivaloan alkalmazhato. Viszont ha ki akarsz torni az altaluk adott keretek kozul, akkor kemenyen szivni fogsz. (En meg a regi C++ builderes tapasztalatok alapjan mondom, hogy meg azt is nehez volt megoldani hogy a foablakot normalisan minimalizalja a talcara.)

    A .Net-rol annyi a velemenyem, hogy egy nagy humbuk meg, felesleges hasznalni. Ahhoz hogy pl. egy programod mashol is fusson telepiteni kell az adott gepre a hozza szukseges bazinagy kornyezetet. Kiveve az XP-s vagy ujabb windozos gepekre. Ez a magyarorszagi viszonylatban keves gepet jelent.
    Szerintem a .Net egyebkentis a Java ellen kuldott probalkozas, amin meg boven van mit fejleszteni. A C# mint nyelv viszont szimpatikus es jol hasznalhato. A VS7 fejlesztokornyezet is turheto.
    Szoval a .Net nekem eleve azert nem tetszik, mert a Javahoz hasonloan egy koztes kodot fordit, amit egy kvazi interpreter vegrehajt, ezzel jelentosen csokkentve a hatekonysagot. Az viszont igaz, hogy a netes es webes alkalmazasok nagyon jol fejleszthetoek benne. Vegulis a neveben is benne van...

    Mutasd a teljes hozzászólást!
abcd