Diese Seite ist unverschlüsselt! Um sicherzustellen, das Ihr Passwort nicht ausgelesen werden kann, sollten Sie auf die verschlüsselte Seite wechseln!

    Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » Allgemeines (OffTopic) » Aufgaben für c++
Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: [ 1 ] [ 2 ] [ 3 ] > 4 < [ 5 ]
030
08.08.2003, 16:36 Uhr
BeS



 Hallo spacelord,


Zitat:
Spacelord postete

Zum Beispiel diesen Post halte ich für kontra-IDE(nicht nur gegen Visual!)
Was stimmt denn mit Delphi nicht???


ganz einfach, mir gefällt delphi nicht.
Und auch an der IDE habe ich nichts entdecken können, was mich begeister hätte und was ich wo anders nicht auch haben kann.


Zitat:

Irgendwelche Zitate von Typen zu bringen,die zumindest ich nicht kenne, ist doch ein bisschen wenig!


Nur weil du ihn nicht kennst hat er keine Ahnung?
Aber ganz unabhängig davon wer der Typ ist steht das Zitat einfach mal so da und ich kann mich dem anschließen, weil ich an IDEs bisher nichts entdecken konnte was mir das Gefühl gegeben hat "Das brauchst du unbedingt".

Ausserdem sind schon ganze Betriebssysteme und grafische Oberflächen ohne IDE entstanden, so wichtig können die Dinger also nicht sein

Letztlich ist es doch aber Geschmacksache, jeder sollte verwenden was er will.
Ich bin mit meinem emacs, gcc, gdb voll zufrieden und mir fehlt nichts.
Wer lieber was anderes verwenden will soll das tun.


Zitat:

PS: Ich gebe virtual recht!Es ist auch vollkommen egal ob man zuerst,oder erst später von Hand linkt und kompiliert!
Am Anfang wundert man sich ohnehin warum den string mit iostream.h nicht funktioniert,und das sind Punkte die wesentlich interessanter sind.
Wer solche Anfangsschwierigkeiten übersteht hat ohnehin den nötigen Biss und wird früher oder später schon lernen was der Compiler und Linker machen!


Sicher ist es erstmal zweitrangig, aber wenn überhaupt ist es doch eher ein Vorteil wenn ein compiler dich zumindest mit einer Warnung darauf aufmerksam macht.

Prinzipiell gebe ich aber auch 0xdeadbeef recht was das lernen betrifft.
Man ließt z.B. immer wieder von GNU/Linux Anfängern in verschiedenen Foren Sachen wie "Ich verwenden jetzt GNU/Linux und möchte Programmieren wie unter windows welche IDEs gibt es".
Wenn man dann z.B. sagt, du kannst einen beliebigen Editor nehmen und das ganze dann mit gcc compiliere kommen solche Fragen "wie ein normaler editor? braucht man keine ide? was ist compiliern?"
Da wird in meinen Augen vielen Anfängern beigebracht das man VisualXYZ braucht, da kann man dann was eintippen und auf den grünen button clicken und dann hat man ein ausführbares Programm. Das man aber im Prinzip nur eine "Textdatei" erstellt und das dann "nur" von einem x-beliebigen compiler übersetzt wird, dass wird ihnen nie gesagt bzw. das haben sie nie verstanden.
Klar wenn man die Leute gleich daran gewöhnt und sie meinen, dass man sowas unbedingt braucht, kann man natürlich mehr davon verkaufen

Aber ich gehe einfach immer nach dem Motto "leben und leben lassen" Jeder soll das verwenden was er will und so wie du mich wahrscheinlich nie von VisualXYZ überzeugen wirst, werde ich dich nie von emacs überzeugen können. Das ist aber auch garnicht nötig, oder
--
If art interprets our dreams, the computer execute them in the guise of programs!
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
031
08.08.2003, 16:38 Uhr
0xdeadbeef
Gott
(Operator)


Äh, Code-Einrückung ist was anderes als Syntax-Highlighting.

Mit der MFC stimmt nicht:
1. Das ganze Late-Binding-Gesumse, Stichwort COM/OLE. Du kriegst dauernd Programme ohne Warnung und Fehlermeldung kompiliert, die garnicht laufen können, und dadurch entstehen Heisenbugs ohne Ende.
2. Der Linker ist total bescheuert. Je nachdem, ob du die MFC dynamisch oder statisch linkst, brauchst du unterschiedlichen Code.
3. Der Klassenbaum ist sehr merkwürdig organisiert. Nur um ein Beispiel zu nennen: Je nachdem, in welcher Event-Handling-Routine du dich befindest, brauchst du eine andere DC-Klasse, um in das Fenster zu malen. Ich musste mir da mit einem ziemlich kranken template-Move helfen, um meinen DC trotzdem vernünftig zu kapseln. Dann gibt es Klassen, die public-Methoden haben, die man nur bei ihrer Basis-Klasse aufrufen darf. Da wird dann durch Laufzeit-Asserts abgebrochen, siehe Punkt 1.
4. Diese merkwürdigen *MAP-Makros. Es ist sehr schwer nachzuvollziehen, was für Code du nachher eigentlich schreibst.

Nur, um ein paar zu nennen.

autoconf/automake stellt ein einheitliches Konfigurationsinterface zur Verfügung, das vieles von der Konfiguration deines Rechners selbstständig erkennt - gegen welche Bibliotheken das Programm nachher gelinkt wird, ob alle Abhängigkeiten erfüllt sind etc. Außerdem kannst du, ohne eine Datei editieren zu müssen, das Programm für den Rechner optimieren, für den du es übersetzt. Das sind so die prominentesten. Es ist ziemlich schwer, autoconf und automake in zwei Sätzen zusammenzufassen, ich schlage vor, du liest mal die Doku auf

www.gnu.org/manual/autoconf/index.html
www.gnu.org/manual/automake/index.html

durch.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
032
08.08.2003, 16:38 Uhr
ao

(Operator)



Zitat:
0xdeadbeef postete
Das wichtigste wird wohl die Klassenbibliothek sein - weder die VCL noch die MFC sind wirklich vernünftig durchgestylt.


Wie wärs denn mal mit konkreter Kritik? Pauschal abbügeln kann jeder.

Außerdem haben VS und MFC nichts miteinander zu tun, außer daß VS einige Wizards hat, die speziell auf MFC-Projekte zugeschnitten sind. Aber du kannst genausogut mit VS Programme entwickeln, die nichts von MFC wissen, und du kannst MFC-basierte Programme mit jedem anderen Entwicklungstool schreiben.


Zitat:

Man kann den Build-Prozess nur sehr eingeschränkt kontrollieren (im Vergleich zu automake/autoconf oder cons) und so weiter.

Was meinst du konkret? Was fehlt? Ich kenne Unix-Tools nur am Rand und weiß daher nicht, was automake & Co. alles können. Aber mit IDL-Integration, CustomBuild, PreLink und PostBuild müsste eigentlich alles erschlagen sein.

ao

ao
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
033
08.08.2003, 16:41 Uhr
Spacelord
Hoffnungsloser Fall


@ao:
Genau so sieht es aus!
Ich erinnere mich noch ganz genau an mein erstes C++ Problem.
Warum funktioniert #include<string> nicht mit #include<iostream.h>,obwohl es doch genau so in meinem Tutorial(für Borland Compiler,in Zeiten des Umschwungs)stand.
Das Letzte was ich damals gebraucht hätte wäre die Frage gewesen ob ich alles richtig kompiliert habe!
Gerade am Anfang ist man so hilflos dass man glücklich ist wenn die Beispiele funktionieren!!
Aber wie gesagt,irgendwann sollte man sich schon mal damit auseinandersetzen.

MfG Spacelord
--
.....Ich mach jetzt nämlich mein Jodeldiplom.Dann hab ich endlich was Eigenes.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
034
08.08.2003, 16:42 Uhr
0xdeadbeef
Gott
(Operator)


@ao: Das erste mehrdateiige Programm, was man schreibt, hat in der Regel nicht mehr als drei Dateien. Und sowas wie

Code:
$ gcc -c datei1.c
$ gcc -c datei2.c
$ ld -o programm datei1.o datei2.o

sollte man gerade noch von Hand hinkriegen. Beziehungsweise - wenn man es nicht von Hand hinkriegt (was beim ersten mal wohl der Fall sein wird), sollte man es lernen.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
035
08.08.2003, 16:49 Uhr
typecast
aka loddab
(Operator)


Wenn man sich sagt, dass beim Compilieren alle Dateien gebraucht werden, dann kommt man vielleicht auf die einfache Zeile

Code:
$ gcc datei1.c, datei2.c, datei3.c


Damit funktioniert es auch!
--
All parts should go together without forcing. ... By all means, do not use a hammer. (IBM maintenance manual, 1925)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
036
08.08.2003, 16:58 Uhr
0xdeadbeef
Gott
(Operator)


Schon klar, ich dachte nur, ich schreib ein bisschen ausführlicher, damit der eigentliche Ablauf klar wird.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
037
08.08.2003, 17:00 Uhr
typecast
aka loddab
(Operator)


Ich wollte damit ausdrücken, dass selbst wenn man wenig Ahnung hat schon irgendwie auch "größere" Programme compiliert bekommt. Wenn das schon nicht geht, dann zeigt dass, das die IDEs wirklich nicht vermittlen, was da passiert.
--
All parts should go together without forcing. ... By all means, do not use a hammer. (IBM maintenance manual, 1925)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
038
08.08.2003, 17:09 Uhr
virtual
Sexiest Bit alive
(Operator)


@hackfrag
Bitte teile mit, ob Deine Frage beantwortet wurde, denn duieser Thread ist mittlerweile gönzlich OT, so daß ich ihn gerne verschieben würde.

Ich schätze automake und autoconf auch als ein sehr mächtiges Tool ein, weil sie Portierungen ganz erheblich vereinfachen. Das konzept schaut stark vereinfacht so aus:

Mit Hilfe einer macrosprache (M4) kann man sich eine Configurationsdatei zusammenbasteln, die wiederum ein Script generiert. Dieses Script kann benutzt werden, um herauszufinden, welche Header/Libraries verfügbar sind, welche Features der Compiler unterstützt, welche Hilfstools vorhanden sind, welche Limitierungen das Betriebssystem hat usw. Aus diesen Informationen bauen die tools dann Header und makefiles, in denen man auf Standardisierte Art und weise diese Sachen wieder auslesen kann und im Source zB für bedingte compilierung abfragen kann.

Nur hat das dummerweise garnichts mit IDEs zu tun: es ist ein mächtiges Tool, nicht mehr. Und als ich noch vermehrt unter Windows programmiert habe, habe ich dieses Tool als ersten Custom build Step in meine Projekte Integriert (man muß eben cygwin installieren und ein paar quere Sachen machen, aber es geht). Und da es mir zu blöd war, das immer Händisch zu machen, habe ich da direkt einen Wizard für geschrieben (Übrigens meine erste Begegnung mit COM!).
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
039
08.08.2003, 23:41 Uhr
Hans
Library Walker
(Operator)



Zitat:
Loddab postete
... dann zeigt dass, das die IDEs wirklich nicht vermittlen, was da passiert.
Hallo Leute,

soweit ich weis, gehört jede IDE in die Kategorie RAD-Tool (Rappid Application Developement Tool). Demnach ist es doch ihr oberster Zweck, all das, was beim zusammenbauen eines Projekts passiert, im Hintergrund zu erledigen, und es somit im wesentlichen vor dem Entwickler zu verbergen. Damit sollte eigentlich klar sein, das eine IDE nicht vermittelt, was da passiert - sie tut es einfach nur.

Hans
--
Man muss nicht alles wissen, aber man sollte wissen, wo es steht. Zum Beispiel hier: Nachdenkseiten oder Infoportal Globalisierung.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: [ 1 ] [ 2 ] [ 3 ] > 4 < [ 5 ]     [ Allgemeines (OffTopic) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: