Van-e különbség a Delphi és a C++-ban írt programok között?

Címkék
Van-e különbség a Delphi és a C++-ban írt programok között?
2003-05-05T14:29:47+02:00
2003-05-29T09:14:35+02:00
2022-11-02T05:00:34+01:00
  • Szvsz a property-t mint nyelvi elem az Object Pascalban vezettek be es a C++Builder mint a Delphi-bol kvazi kinovo fejleszto eszkoz (mivel VCLt nem irtak at C++ra) kenytelen volt alkalmazkodni hozza ! Ezert vezettek be egyaltalan nem szabvanyos elemeket a Borland C++-ba.
    Amik nelkul tulkepp nem tudsz VCL-el programozni, de innentol oda a hordozhatosagank minden eselye is. Ui. nem hiszem hogy az MS majd tesz a VC++-ba VCL project import wizardot mint a Borland tette az MFC-vel.

    Ezt szabvány C++-ban csak úgy tudod megoldani ha írsz egy setFont nevű függvényt ami viszont nem az igazi mivel így a Font mint attributum értelmét veszti.

    Amugy ha jol megnezed pontosan ez is tortenik a property-kel C++Builder-ben van egy +nyelvi elem ami azt az erzetet kelti veled hogy egy attributumot allitassz valojaban pedig egy set/get fuggvenyt fog meghivni! Tehat ugyan az mintha egy set/get accessorral ernel el egy protected/private tagot (ez is tortenik, csak igy esetleg olvasmanyosabb, osszetett attributumokat konnyebb kezelni).

    Mutasd a teljes hozzászólást!
  • A property-k azért kellettek mert nem árt ha egy osztály értesül arról hogy egy attributuma megváltozik. Ha Pl. egy TLabel Font attributuma megváltozik akkor nem árt őt újrarajzolni. Na erre jó a property. Ezt szabvány C++-ban csak úgy tudod megoldani ha írsz egy setFont nevű függvényt ami viszont nem az igazi mivel így a Font mint attributum értelmét veszti.
    Mutasd a teljes hozzászólást!
  • Szia !

    Remelem nem ram ertetted az arrogans stilust !
    De ha barkit megbantottam volna, nos akkor bocsanat !
    Udv., S.
    Mutasd a teljes hozzászólást!
  • Hello!

    Egyettértek a munka minősgétől függ minden. Akkor mondjuk ugy hogy durván cseréltek eszmét ezt értem a heves, kicsapongo már már arrogáns irásokra. ( tisztelett a kivételnek )
    Mutasd a teljes hozzászólást!
  • Szerintem nem vitatkozunk, inkabb csak eszmet cserelunk! Vagy mondtam volna valami negativat a OP-re ??

    Letezik 1altalan olyan hogy egy nyelv sebessege (nem interpretalt nyelvekre/eszkozokre gondolok) ???
    Szerintem minden attol fugg hogyan hasznaljak ki az nyelv/eszkoz adottsagait!

    A smile-k tenyleg jok !
    Mutasd a teljes hozzászólást!
  • Vegul alljon itt egy pelda a C++ mellett, es bar nem szerencsem mas tollaval ekeskedni, hadd mutassak egy osztalyt !
    Boccs ha ez mar egy picit OFF...
    ez az osztaly amugy a Boost-rol valo amely "a minden ami az STL-bol kimaradt de remeljuk a kov. C++ STL szabvanyban mar benne lesz" cimet is viselhetne'...

    #include <algorithm> #include <typeinfo> class Any { public: // structors Any() : content(0) { } template<typename ValueType> Any(const ValueType & value) : content(new holder<ValueType>(value)) { } Any(const Any & other) : content(other.content ? other.content->clone() : 0) { } ~Any() { delete content; } public: // modifiers Any & swap(Any & rhs) { STLPORT::swap(content, rhs.content); return *this; } template<typename ValueType> Any & operator=(const ValueType & rhs) { Any(rhs).swap(*this); return *this; } Any & operator=(const Any & rhs) { Any(rhs).swap(*this); return *this; } public: // queries bool empty() const { return !content; } const STLPORT::type_info & type() const { return content ? content->type() : typeid(void); } private: // types class placeholder { public: // structors virtual ~placeholder() { } public: // queries virtual const STLPORT::type_info & type() const = 0; virtual placeholder * clone() const = 0; }; template<typename ValueType> class holder : public placeholder { public: // structors holder(const ValueType & value) : held(value) { } public: // queries virtual const STLPORT::type_info & type() const { return typeid(ValueType); } virtual placeholder * clone() const { return new holder(held); } public: // representation ValueType held; }; private: // representation template<typename ValueType> friend ValueType * any_cast(Any *); placeholder * content; }; class Bad_any_cast : public STLPORT::bad_cast { public: virtual const char * what() const throw() { return "Bad_any_cast: " "failed conversion using any_cast"; } }; template<typename ValueType> inline ValueType * any_cast(Any * operand) { return operand && operand->type() == typeid(ValueType) ? &static_cast<Any::holder<ValueType>*>(operand->content)->held : 0; } template<typename ValueType> inline const ValueType * any_cast(const Any * operand) { return any_cast<ValueType>(const_cast<Any *>(operand)); } template<typename ValueType> inline ValueType any_cast(const Any & operand) { const ValueType * result = any_cast<ValueType>(&operand); if(!result) throw Bad_any_cast(); return *result; } template<typename ValueType> inline bool operator>>=(const Any & operand, ValueType &value) { try { if (operand.empty()) { return false; } value = any_cast<ValueType>(operand); return true; } catch(const Bad_any_cast &) { return false; } }

    (a >>= operatort mar en tettem hozza, csak hogy meg konnyebben hasznalhato legyen!)
    Szerintem ez az osztaly zsenialis, es remekul kihasznalja a C++ majd minden elemet, de ahhoz hogy valaki ertse hogy mukodik tenyleg ertenie kell a nyelvhez !
    Udv. S.
    Mutasd a teljes hozzászólást!
  • Hello!

    Én tudjátok mit láttam, massievly multiplayer onlne játékokat fejlesztenek delphivel ahhol fontos a sebbeség ( a játék stílusára értem ) tehát szerintem sebbeségben semmi különbség, tökéletes játékfejlesztésre a delphi is
    Mutasd a teljes hozzászólást!
  • hello

    minek ilyen kis aproságon vitatkozni, valaki a delphit valaki a c++ szereti izlések és pofonok
    sőt szerintem egyenértékű a kétprogram nyelv ( jók ezek a smylik! )
    Mutasd a teljes hozzászólást!
  • A C++ oldalán pedig a property-k hiányoznak de nagyon.

    property-k vannak C++Builderben is, mint nyelvi kiterjesztes.... de egyaltalan nem hordozhato.... es csak a Delphi miatt kellett !

    Meg van még egy kellemes tulajdonsága a Pascal-nak: a halmazok.

    Erre talaltak ki az STL-t es nem vezettek be kulon nyelvi elemet hanem a meglevokkel megcsinaltak... de ugy mondanom sem kell hogy sokkal tobb mindenre hasznalhato!

    Reszemrol pont azert szeretem a C++-t amiert regen a Delphi-t ! ->

    Szvsz a Delphi legnagyszerubb eleme komponenes alapu programozas ami mara mar teljesen elfogadott es tamogatott (lasd .Net), ui. nagyon jol bovitheto a VCL es ezzel nagyon sok munkat tud megtakaritani... de leginkabb valljuk be inkabb a UI feljesztesre hasznaljak !

    Mig C++-nal ugyanezek az epitokovek vannak leginkabb programozasi paradigmak feloldasara (STL, ACE, ...), ill. a nyelv tokeletesen alkalmas mindenfele pattern leirasara (pl. strategy)!
    Mutasd a teljes hozzászólást!
  • de nem kell egy objektumnak COM objektumnak lennie ahhoz OP-ben, hogy lehessenek interface-ei, és így több őse (deklarációs ős).

    De szvsz anelkul lehet bele sem teszik a nyelvbe, mert az orokles amugy sem mindig a legszerencsesebb megoldas es feloldhato aggregacioval.

    a for ciklusban igazad van, bar meg amikor pascaloztam nem igazan zavart... alkalmazkodtam a nyelvhez !
    Es azert C/C++ban is rendesen el lehet irni egy for ciklust pl. ',' irsz ';' helyett es mukodni fog csak nem azt csinalja....

    Nagyon jó példát hoztál (az én állításom mellett ), mert pl. ha erre ránéz valaki, aki nem ismeri a szóban forgó konvenciót (ti. hogy a '<<' operátort milyen funkcióval ruházod fel), akkor csak vakarni fogja a fejét

    Aki nem tudja elolvasni az ilyen kodot az nem tud C++-ban programozni !!!
    De miert is a nyelv hibaja ez ! Olyan ez mint a nyelvtudas (marmint nem prg nyelv), ha nem ismered a nyelvtani szabalyt nem fogod megerteni mit akartak mondani, vagy min. felreerted !
    Az OP csak megkonnyiti a kezdok helyzetet... szvsz !
    Szerintem amiert sokan ellenszenveznek a C++-al az hogy gyk. mindent megenged a programozonak... sokan meg pont ezert szeretik !

    Azért azt észre kell venni, hogy ma már nem magányos programozók dolgoznak

    Ebben teljesen igazad van, en is egy nagy multi cegnek dolgozom, sokad magammal, az egesz rendszer C++-ban van irva (sosem szamoltam de tobb millio sor) es sosem a nyelv-vel van a gond hanem annak nem ismeresevel + ezt meg paran sikeresen keverik a programozashoz (alapelvek, OO) nem ertessel ! De ettol en meg tudok szep es olvashato kodot irni...
    Mutasd a teljes hozzászólást!
  • A << tényleg nem a legszerencsésebb példa. De Pl. a +, -, *, / felülírása néha nagyon jól jöhet ha olyan osztályokat írsz amikre ezeket a műveleteket értelmezni lehet. Általában az operator overloadingot nem formokon használja az ember hanem olyan osztályokon amiket utána több helyen is felhasznál. Az ilyen osztályokat pedig illik alaposan dokumentálni.
    Mutasd a teljes hozzászólást!
  • + javits ki ha tevedek de Delphi-ben is elsosorban a COM miatt kellett mintsem annyira hianyzott volna !

    Az lehet, hogy a COM miatt került bele, de nem kell egy objektumnak COM objektumnak lennie ahhoz OP-ben, hogy lehessenek interface-ei, és így több őse (deklarációs ős).

    Ezt a 'for ciklus' dolgot magyarazd el legyszi! ... mert szeirintem ez pusztan szintaktikai kulonbseg a ket nyelv kozott, de ennyi erovel emlithettel volna ezer mas dolgot is !

    Nézd meg a Delphi for-ciklusát, meg nézd meg a C for-ciklusát! Míg utóbbival gyakorlatilag tetszőleges while-do és repeat-until ciklus kiváltható (és egyben sokkal átláthatóbbá tehető a ciklus szervezése), addig a Pascal-é a legbénább for szerkezete amivel valaha találkoztam, és aminél még a BASIC-é is jobb, mert ott legalább van STEP a lépésköz meghatározására.

    vagy mennyiben lenne szebb function overloadingot hasznalni ami ugye mar van OPascalban !
    e helyett:

    ostrstream o;
    o << 1 << "Sting" << endl << myclass << ends;

    Nagyon jó példát hoztál (az én állításom mellett ), mert pl. ha erre ránéz valaki, aki nem ismeri a szóban forgó konvenciót (ti. hogy a '<<' operátort milyen funkcióval ruházod fel), akkor csak vakarni fogja a fejét, hogy vajon mit shiftel balra azokon a szerencsétlen operátorokon a kód. És ez nagy baj szerintem, ti. ha valaki nem tud közvetlenül olvasni egy kódot, hanem az egész - sokszor több százezer kódos -programon át kell rágnia magát mire elkezdi kapizsgálni miről van szó.

    Azért azt észre kell venni, hogy ma már nem magányos programozók dolgoznak, és az olyan nyelv, ami megenged ilyen "disznóságokat" is, elősegíti a nehezen karbantartható és átlátható kódok fejlesztését is - ez pedig fatális következményekkel jár piaci körülmények között.
    Mutasd a teljes hozzászólást!
  • 1&értek, az operator overloading szerintem is jó ötlet. For ciklus: na igen, ez a Pascal egyik állatsága. Nem tudsz csak +1 vagy -1 lépésközzel haladni. A C for ciklusa ennél több fényévvel jobb. De én ide sorolnám a kapcsos zárójelet a begin end helyett, a prefix/postfix operátorokat (++/-- és társai). A C++ oldalán pedig a property-k hiányoznak de nagyon. Meg van még egy kellemes tulajdonsága a Pascal-nak: a halmazok.
    Mutasd a teljes hozzászólást!
  • Én nem a fordítási sebességről beszéltem hanem a generált kód sebességéről. Szvsz egy Object Pascal-ban írt program nem lassabb mint egy C++-ban írt ha nagyjából ugyanolyan minőségű a Pascal és a C++ fordítónk.
    Mutasd a teljes hozzászólást!
  • Hello Sting!

    Picit felreertettel, nem mondtam hogy azert mert a C++ban van 'implementacios' tobbszoros orokles attol tobb lenne a OPascalnal, mindosszesen annyit tesz hogy az OO elvek szelesebb koret implementalja, de pl. Javaban is csak interface-el van tobbszoros orokles, de szerintem sokkal inkabb OO nyelv mint a C++!
    Hisz a C++ egy hibrid nyelv, es pont ez amiert igen rugalmasan hasznalhato !
    + javits ki ha tevedek de Delphi-ben is elsosorban a COM miatt kellett mintsem annyira hianyzott volna !

    -A template-ket emlitettem, es azt is hogy semmi koze az OOP-hez, talan ezert sem illik a OPascal-ba!
    De teny hogy nagyon elegansan hasznalhato !
    A makrok orok tema C++os korokben, marmint hogy illik-e hasznalni vagy sem, ui. nagyban ronthatja egy forras atlathatosagat es debuggolhatosagat... ha rosszul hasznaljak, es megvannak a nyelvi elemek a kikerulesukre !!!

    -Ezt a 'for ciklus' dolgot magyarazd el legyszi! ... mert szeirintem ez pusztan szintaktikai kulonbseg a ket nyelv kozott, de ennyi erovel emlithettel volna ezer mas dolgot is !


    "szigorubb lathatosagi szabalyok, friend-ek
    Na, az egy dolog, hogy Borlandék kellemesen eltolták a protected és private szkóp implementációját a saját kényelmük érdekében,..."

    -Ratapintottal a lenyegre... ui. ezert randa a C++Builder-ben az ahogy a VCL-t ala toltak ! Ui. a Pas->hpp konverter egyszeruen semmibe veszi ezt a kulonbseget a ket nyelv kozott !!!
    Sokkal jobban jartak volna ha veszik a faradsagot es ujra irjak nativan C++ban!

    -A 'friend'-is csak egy nyelvi elem...


    operator overloading !
    Én speciel ezt nem feltétlenül említeném az előnyök között. Elég rossz, amikor egy "+" jel szorzást jelent, és ez csak akkor derül ki, amikor átnézed a 68 szint mélyen lévő headert, és megtalálód benne az operator overloadot...

    -Ezt asszem mar olvastam toled vagy mastol a Delphi listan !
    Szerintem ez is egy olyan nyelvi elem amit ha okosan hasznalnak, elegansabba, olvashatobba teszik a kodot !
    Pl. eleg gusztustalanul nezne ki igy :
    ostrstream o; o.addInt(1); o.addString("Sting"); o.addEndl(); o.addMyClass(myClass); o.addEndString(); ...
    vagy mennyiben lenne szebb function overloadingot hasznalni ami ugye mar van OPascalban !
    e helyett:
    ostrstream o; o << 1 << "Sting" << endl << myclass << ends;

    -Az a meglatasom, (mindenfele hitvita tavol alljon tolem !) hogy a legtobb erv amit felhoznak a C++ ellen abbol ered hogy a tomor szintakszis es az ilyen konnyen rosszul (vagy inkabb konnyen helytelenul) hasznalhato nyelvi elemek sokak keze alatt eredmenyeznek olvashatatlan, kibogozhatatlan kodot !!! Ami igaz is, de en ezt nem ronam fel a C++ ellen, inkabb meg kene tanulni rendesen programozni !

    Udv.
    Schwarzy
    Mutasd a teljes hozzászólást!
  • Ami nagy kulonbseg pl. a ObjectPascal es a C++ kozott az az OO alapelvek implementalasaban (is) van : tobbszoros orokles

    Delphi-ban is van D3 óta többszörös öröklés az interface-ek révén, bár ez nem implementációs, csak deklarációs öröklést jelent. Egyébként nem értem, hogy ez miért jön elő, mint akkora plusz a C++ mellett, mert én egy kezem meg tudom számolni, hogy az utóbbi három évben hányszor használtam többszörös öröklést - pedig nem számlázóprogramokat írok.

    Egyébként ha már valami olyasmi dolgokat kellene említenem a C/C++-ból amiben jobb, mint a Delphi, akkor a class template-eket és a for ciklust említeném. Előbbi igazából nem illik a Pascal filozófiába - mint ahogy a makrók sem -, de utóbbi nagyon király lenne benne.

    szigorubb lathatosagi szabalyok, friend-ek

    Na, az egy dolog, hogy Borlandék kellemesen eltolták a protected és private szkóp implementációját a saját kényelmük érdekében, de az azért már furcsa, hogy pont a szigorú láthatósági szabályokról beszélsz és aztán pont a friend osztályokat hozod fel. Ti. utóbbi lehetőség (friend) szerintem ugyanolyan durva - bár néha a kódot nagy mértékben egyszerűsítő - áthágás, mint a private és a protected "pongyola" implementációja az Object Pascalban.

    operator overloading !

    Én speciel ezt nem feltétlenül említeném az előnyök között. Elég rossz, amikor egy "+" jel szorzást jelent, és ez csak akkor derül ki, amikor átnézed a 68 szint mélyen lévő headert, és megtalálód benne az operator overloadot...
    Mutasd a teljes hozzászólást!
  • Picit vitatkoznek veled (KoMBanY hozzaszolasaval szvsz nem is erdemes...)
    :

    "- Jóformán semmi sebességkülönbség nincs egy C++ -ban és egy Delphi-ben fordított azonos szerkezetű kód között. A sebesség meg 98%-ban a technikától/algoritmustól függ, a többi a fordító dolga..."

    Ha jol ertem itt most a vita a Delphi es a C++Builder viszonyarol folyik... ui. azert a C++Builder es a C++ nem ua !
    Amit sokszor hallok a Delphi lassusagarol az inkabb a VCL altal biztositott kontenerek-bol adodik szerintem, ui. azok nagyon nem hatokony tarolok osszehasonlitva pl. az STL kontenereivel !
    Szerintem pont ezert lehet jo valasztas a C++Builder a Delphi-vel szemben, bar ketsegtelenul tovabbra is a Delphi a mainstream es VCL object pascalos volta miatt nagyon szenvedos Builderben dolgozni a D.hez kepest ! Viszont Builderben megvannak a VCL RAD elonyei (ami mas eszkozokre kevesse mondhato el) es ki lehet hasznalni egy eleg jo, szabvanyos C++ fordito elonyeit is !

    "- Nem Pascal, hanem ObjectPascal. Sok különbség van, több mint C és C++ között :)"

    Ez biztos
    Nezd meg jobban a C++ szabvanyt a C-hez kepest....

    "- Miért? Jobb lenne C++ -t tanítani elsőre? Próbáltad már egy kezdőnek elmagyarázni a Pointert és a PChar-t??? Vagy azt, hogy az a karakter most "karakter" vagy "szám" ?"

    Az hogy mit kene elso nyelvkent tanitani, tenyleg nehez megvalaszolni.. (sok helyen mar Java-val kezdenek - majd kiderul jol teszik-e, bar SZVSZ egy jo C++ programozobol konnyen valhat valaki jo Java programozova, forditva gyanitom csak nagyon-nagy kinok aran ...)

    De azt kotve hiszem hogy a C++ a pointer aritmetika miatt lenne nagyon bonyolult egy kezdonek, szvsz ezek Pascalban is ugyanugy benne vannak (csak picivel korulmenyesebb)! Ami nagy kulonbseg pl. a ObjectPascal es a C++ kozott az az OO alapelvek implementalasaban (is) van : tobbszoros orokles, szigorubb lathatosagi szabalyok, friend-ek, operator overloading !
    + amiben tobb a C++ es nem OO tulajdonsag az pedig a generikus programozas -> template-k amit Pascalos hozzaallassal felfogni el tudom hinni hogy nehez, foleg egy kezdonek ! De ugye egy kezdo sem hasznalja ki a Pascal minden csinjat-binjat az elejen...
    ...+ C++-ban elvileg lehet hordozhato kodot irni tobb platformra/tobb forditora
    (van ra pelda)... nem egyszeru de lehet

    Az elotted szolo Delphi - VB osszevetesehez meg csak annyit hogy a Delphi nativ kodot fordit mindig !!!
    Mig a VB max osszeforditja a P-code-ot a fottato motorral....

    "if Button->Name == 'akarmi'" ->
    if (Button->Name == 'akarmi')
    {...
    ...ugye !

    Bye.
    Schwarzy
    Mutasd a teljes hozzászólást!
  • És a Borland fordítói amúgy elég jók sebesség szempontjából, és a Free Pascal is elég gyors.

    Én azért nem említeném egy lapon a Pascal és a C/C++ fordítók sebességét. Se Borlandét, se Microsoftét.
    Mutasd a teljes hozzászólást!
  • Az Object Pascal és a C++ között tényleg nincs lényegi sebességkülönbség. Egyébként a sebesség elég nagy mértékben a fordítótól függ. A C++ és az Object Pascal szintaktika között nincs olyan érdemi különbség ami miatt jelentős sebességkülönbség lenne a két nyelv között. És a Borland fordítói amúgy elég jók sebesség szempontjából, és a Free Pascal is elég gyors. A Pascal előnye hogy mivel valamivel kötöttebb a nyelv szerkezete mint a C gyorsabb fordítókat lehet rá írni. Gyakorlatilag ugyanez a helyzet a basic-cel is, arra is lehet gyors fordítókat csinálni (ha jól tudom az M$ VB6-ban ha exe-t fordítasz a régebbi MS Visual C++ motorja ketyeg) Basic: Na te sem írtál még nagyobb programot bézikben... Maga a nyelv igen-igen ocsmányságos, a VB.NET pedig szvsz még tovább rontott rajta. Én elég sok (>20 000 sor) programot írtam mindhárom nyelven. (A bézikre mentségemre legyen mondva hogy akkor még nem volt Delphi és RAD jellegű meló volt) Az Object Pascal szvsz inkább RAD-orientált dolgokra jó de arra nagyon, a C++ RAD-os feladatokra nem az igazi viszont Pl. szerver szoftvereket, játékokat írni nagyon jó. A bézik pedig annak való aki nem tudja megtanulni sem a Pascal sem a C++ nyelvet. Amúgy szvsz ma a legjobb nyelv a C#, ebben szinte minden megvan ami a Pascal-ban és a C++-ban jó.
    Mutasd a teljes hozzászólást!
  • A sebesség meg 98%-ban a technikától/algoritmustól függ, a többi a fordító dolga...


    A VCL tényleg lassúcska kicsit, de nem ez fogja a mai alkalmazások sebességét megszabni, az már biztos.

    Péter
    Mutasd a teljes hozzászólást!
  • Összefoglalva: unatkozó középiskolás :-]
    Nem baj, éljen a fiatalság, a nagy koppanásokon mindenkinek túl kell esnie.
    Mutasd a teljes hozzászólást!
  • Ebből a hozzászólásodból annyit lehet megtudni, hogy:
    1. nem ismered a Delphi-t
    2. nem ismered a Pascal-t
    3. nem ismered a Basic-et
    4. nem ismered az assembly-t
    5. nem ismered a programozás alapjait
    6. szimpatikusnak tartod a C++ (de a fentiek alapján kevés következtetésre lehet jutni a C++ ismereteidet illetően)
    7. általad nem ismert dolgokról alaptalanul lesújtó kinyilatkoztatást teszel (és valószínűleg nem vagy tudatában, hogy alaptalan, mert 1-6. pontok)
    Mutasd a teljes hozzászólást!
  • "A Delphi inkább a visual Basic szintjén van mint szükséges tudás, mind sebesség terén"

    - Mennyivel több tudás kell egy C++ -hoz, mint Delphi-hez??? Én ebből a hozzászólásodból, csak azt szűrtem le, hogy nem igazán ismered a Delphi-t és "kattingatós" programnyelvnek hiszed... Igen RAD, de lehet - és kell is benne - programozni.

    - Jóformán semmi sebességkülönbség nincs egy C++ -ban és egy Delphi-ben fordított azonos szerkezetű kód között. A sebesség meg 98%-ban a technikától/algoritmustól függ, a többi a fordító dolga...


    " Pascal -t meg felejtsük már el.. annál gusztustalanabb programnyelvet még ember nem találti ki.. "

    - Nem Pascal, hanem ObjectPascal. Sok különbség van, több mint C és C++ között :)

    - Mitől gusztustalan??? Ezt részleteznéd???

    " ugyanazt a progit majdnemhogy könnyeb ASM -ben megírni min pascalban.. "

    - Ezt ugye Te sem gondolod komolyan?


    "ami szerintem röhelyes.. soha nem fogom megérteni, hogy a sulikban miért apscal-t tanítanak.."

    - Miért? Jobb ötlet a főiskolán egyből Java-t tanítani??? Szegény elsős azt sem tudja mi az a for ciklus és egyből objektumokkal kell dolgoznia...

    - Miért? Jobb lenne C++ -t tanítani elsőre? Próbáltad már egy kezdőnek elmagyarázni a Pointert és a PChar-t??? Vagy azt, hogy az a karakter most "karakter" vagy "szám" ?


    "Sehova sem tartozik igazán, és egyszerűen csúnya"

    - A magas szintű nyelvekhez tartozik. Az ObjectPascal-os Delphi meg RAD.

    - Mitől csúnya? Az, hogy:

    if Button->Name == 'akarmi'
    {
    Button->Caption = 'valami';
    Button->Left = 5;
    Button->Top = 10;
    }

    helyett írhatod ezt is:

    with Button do
    if Name = 'akarmi' then
    begin
    Caption := 'valami';
    Left := 5;
    Top := 10;
    end;

    - Amúgy meg mit nevezünk csúnyának??? Most mondjam, hogy a C-sek meg nem programoznak csak commenteket írnak? { } :))))
    Mutasd a teljes hozzászólást!
  • Üdv ALL!

    A Delphi inkább a visual Basic szintjén van mint szükséges tudás, mind sebesség terén. Adatnázis kezelő meg multimédiás progikra tökéletesek, de ahova sebesség kell, ott csak a C++ jöhet szóba.

    A Pascal -t meg felejtsük már el.. annál gusztustalanabb programnyelvet még ember nem találti ki.. ugyanazt a progit majdnemhogy könnyeb ASM -ben megírni min pascalban.. ami szerintem röhelyes.. soha nem fogom megérteni, hogy a sulikban miért apscal-t tanítanak.. ha a programozás alapjait akarják megtanítani, akkor arra jobb a basic. egyszerűbb is átláthatóbb is. A pascal valahol középen van az alacsony és a magasszintű nyelvek között. Sehova sem tartozik igazán, és egyszerűen csúnya.

    BYe:

    KoMBanY
    Mutasd a teljes hozzászólást!
  • Péter:Hivatalos helyen szerintem el sem ismernék, mert nem érdekük sem a szolgáltató cégeknek, sem az állami szférának.

    Kár pedig azt megnéztem volna
    Mutasd a teljes hozzászólást!
  • Hivatalos helyen szerintem el sem ismernék, mert nem érdekük sem a szolgáltató cégeknek, sem az állami szférának.

    Sok munkaügyi központ kínál(t) átképzés/továbbképzés keretében felsőfokú OKJ-s programozói papírt, de ez gyakorlatilag nem elégséges ahhoz, hogy valaki ilyen jellegű területen el tudjon helyezkedni.

    Péter
    Mutasd a teljes hozzászólást!
  • Ja bocs, azt hittem vm hivatalos helyen láttad vmkor.
    Mutasd a teljes hozzászólást!
  • ...tanfolyamok hatékonysága 0.1 és 1% között mozog...

    Ezt a statisztikát honnan vetted?


    Olvasd el, amit irok :)

    Fejbőlkapott statisztikák szerint...


    Ha azt nézem, hogy volt középiskolai osztályomból (programozó) azt hiszem egyedül én dolgozom igazából szakmámban, egy hasonló tanfolyam után azt hiszem kb. szintén én dolgozom egyedül fejlesztőként...

    Más, szintén "felsőfokú OKJ hax0r" tanfolyamot végzett ismerőseim szerint is kb. 30 főből 2-3-nak sikerült a szakmában elhelyezkednie és ezek az emberek 105%-ban előtte is alapos ismeretekkel rendelkeztek legalábbis a számítástechnikában, de inkább a programozás területén.

    Péter
    Mutasd a teljes hozzászólást!
  • ...tanfolyamok hatékonysága 0.1 és 1% között mozog...

    Ezt a statisztikát honnan vetted?

    Azért nem hinném, hogy ennyire rossz lenne. Én adnék egy 10-20%-ot lagalább.
    Mutasd a teljes hozzászólást!
  • Nem akarlak untatni


    Dehogyis!

    egy programozói tanfolyamra járok ami jó drága, de úgy érzem ezért a pénzért nem kaptam szinte semmit.


    Fejbőlkapott statisztikák szerint az egyéves/másféléves gyorstalpaló tanfolyamok hatékonysága 0.1 és 1% között mozog. Páran végeztünk itt ilyen tanfolyamot, de nem ott tanultunk meg programozni. Egyszerűen kevés az idő a biztos alapokhoz és a szükséges minimális tapasztalat megszerzéséhez.

    Nagy kiszúrás annak, aki saját zsebből fizeti :(

    Most itt a tanfolyam vége és azt sem tudom, hogy kezdjek hozzá a szakdolgozathoz.


    A formai és tartalmi követelmények általában adottak. Fix témaválasztási lehetőség nincs? Szokott olyasmi lenni, hogy 15-20 fix szakdolgozattémából lehet választani.

    Milyen témában (adatbázis, hálózat, stb.) kell beadni a dolgozatot? Mikorra? Mennyire vagy otthon Delphiben?

    Ezért gondoltam, hogy keresek valakit a neten aki tud segíteni.


    Próbálkozhatunk, de nem tudom, mennyi idő van...

    Péter
    Mutasd a teljes hozzászólást!
Címkék
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd