Hallo,
ich lerne gerade C++, und jetzt habe ich mal eine dumme Frage:
Wo erfährt man die Funktionen die von Header-Dateien geliefert werden?
z.B. iostream = cout usw.
Ich habe zwar ein C++ Buch, da steht darüber aber nicht viel drinn.
Ich entschuldige mich für den nichtssagenden Titel, aber ich wusste keinen passenden.
Frage
Re: Frage
Hi!
Am besten in den Headern nachschauen. <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
Cheers,
GNU/Wolfgang
Am besten in den Headern nachschauen. <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
Cheers,
GNU/Wolfgang
-
Steffan R
Re: Frage
Kommt es mir nur so vor, oder ist C++ irgendwie schwer zu lernen, oder bin ich zu dumm?
Naja, grundlegende Sachen wie "Hallo Welt" oder kleine Rechner sind ja kein problem, was ich aber immernochnicht verstehe sind die Klassen, was sind die eigentlich? Sowas wie "structs"?
Und was mich schon immer interessierte:
Rein theoretisch gesehen sind doch alle (kompilierten) Programmiersprachen gleich schnell oder? (Jetzt mal abgesehen von Java)
Jetzt habe ich aber gelesen, daß folgende Reihenfolge zutrifft:
Assembler soll am schnellsten sein.
Dann C
Dann C++
Und dann der Rest, was stimmt jetzt eigentlich?
Gruß
Steffan
Naja, grundlegende Sachen wie "Hallo Welt" oder kleine Rechner sind ja kein problem, was ich aber immernochnicht verstehe sind die Klassen, was sind die eigentlich? Sowas wie "structs"?
Und was mich schon immer interessierte:
Rein theoretisch gesehen sind doch alle (kompilierten) Programmiersprachen gleich schnell oder? (Jetzt mal abgesehen von Java)
Jetzt habe ich aber gelesen, daß folgende Reihenfolge zutrifft:
Assembler soll am schnellsten sein.
Dann C
Dann C++
Und dann der Rest, was stimmt jetzt eigentlich?
Gruß
Steffan
Re: Frage
Deine Reihenfolge der Geschwindigkeiten ist korrekt. Allerdings, kann es sein, dass ein sehr schlechter Assembler Programmierer genauso schelchten bzw. schlechteren Code erzeugt als ein C kompiler <img src="http://www.pl-forum.de/UltraBoard/Images/TooHappy.gif" border="0" align="middle"> (womit natürlich die Reihenfolge nicht mehr stimmen würde).
Last edited by trinity on 25. Feb 2002 18:20, edited 1 time in total.
"Korrekt, Freundlich, Kostenfrei", wähle genau zwei. (Lutz Donnerhacke in dcsf)
Re: Frage
Hi!
> Kommt es mir nur so vor, oder ist C++ irgendwie schwer zu lernen, oder bin ich zu dumm?
<polemic against="C++">
C++ ist zum einen extrem schwer zu lernen und zum anderen extrem schwer zu verwenden, ja. Es hat gewiss nichts mit Dummheit deinerseits, eher mit Inkompetenz oder Bösartigkeit (wir sind nicht sicher, welches davon zutrifft) derjenigen, die für C++ verantwortlich sind.
</polemic>
> Naja, grundlegende Sachen wie "Hallo Welt" oder kleine Rechner sind ja kein problem, was ich aber immernochnicht verstehe sind die Klassen, was sind die eigentlich? Sowas wie "structs"?
Klassen sind ein wichtiges Grundprinzip der objektorientierten Programmierung. Sie ermöglichen:
1.) Datenkapselung, d.h. die interne Darstellung von Daten kann vom Großteil des Codes ignoriert werden, weil auf die Daten über eine wohldefinierte Schnittstelle zugegriffen werden kann.
2.) Vererbung, d.h. es wird möglich, Code wiederzuverwenden, indem man zuerst eine Klasse für einen abstrakteren Begriff (z.B. "Fahrzeug") festlegt mit den Eigenschaften und Methoden, jene alle unterarten gemeinsam haben und dann darauf spezifischere Klassen (z.B. "Auto", "Fahrrad") aufbauen lässt.
3.) Polymorphie, d.h. verschiedene Klassen bieten die gleiche Schnittstelle an und der Code, der damit arbeitet, braucht sich nicht darum zu kümmern, wie diese genau implementiert ist, so würden sowohl ein Rechteck als auch ein Kreis eine Methode wie "zeichnen" anbieten, jene das Objekt auf den Bildschirm bringt. Der Code, der solche Objekte verarbeitet braucht sich nicht dafür zu interessieren, was das Objekt macht. Ein anderes schönes Beispiel sind die Gerätedateien im Unix-Dateisystem, die allesamt Operationen wie read() und write() anbieten, sodass Programme sich nicht darum kümmern müssen, ob sie nun eine normale Datei kopieren oder eine Partition duplizieren.
> Und was mich schon immer interessierte:
> Rein theoretisch gesehen sind doch alle (kompilierten) Programmiersprachen gleich schnell oder?
Nein, warum sollten sie? Das hängt vom Compiler ab bzw. dem Code, den er produziert. (Allen anders lautenden Aussagen zum Trotz produziert der GCC übrigens ziemlich guten Code.) Oft hängt es auch von der betreffenden Aufgabe ab. Angeblich soll ja bei numerischen Problemen Fortran typischerweise am schnellsten sein.
Cheers,
GNU/Wolfgang
> Kommt es mir nur so vor, oder ist C++ irgendwie schwer zu lernen, oder bin ich zu dumm?
<polemic against="C++">
C++ ist zum einen extrem schwer zu lernen und zum anderen extrem schwer zu verwenden, ja. Es hat gewiss nichts mit Dummheit deinerseits, eher mit Inkompetenz oder Bösartigkeit (wir sind nicht sicher, welches davon zutrifft) derjenigen, die für C++ verantwortlich sind.
</polemic>
> Naja, grundlegende Sachen wie "Hallo Welt" oder kleine Rechner sind ja kein problem, was ich aber immernochnicht verstehe sind die Klassen, was sind die eigentlich? Sowas wie "structs"?
Klassen sind ein wichtiges Grundprinzip der objektorientierten Programmierung. Sie ermöglichen:
1.) Datenkapselung, d.h. die interne Darstellung von Daten kann vom Großteil des Codes ignoriert werden, weil auf die Daten über eine wohldefinierte Schnittstelle zugegriffen werden kann.
2.) Vererbung, d.h. es wird möglich, Code wiederzuverwenden, indem man zuerst eine Klasse für einen abstrakteren Begriff (z.B. "Fahrzeug") festlegt mit den Eigenschaften und Methoden, jene alle unterarten gemeinsam haben und dann darauf spezifischere Klassen (z.B. "Auto", "Fahrrad") aufbauen lässt.
3.) Polymorphie, d.h. verschiedene Klassen bieten die gleiche Schnittstelle an und der Code, der damit arbeitet, braucht sich nicht darum zu kümmern, wie diese genau implementiert ist, so würden sowohl ein Rechteck als auch ein Kreis eine Methode wie "zeichnen" anbieten, jene das Objekt auf den Bildschirm bringt. Der Code, der solche Objekte verarbeitet braucht sich nicht dafür zu interessieren, was das Objekt macht. Ein anderes schönes Beispiel sind die Gerätedateien im Unix-Dateisystem, die allesamt Operationen wie read() und write() anbieten, sodass Programme sich nicht darum kümmern müssen, ob sie nun eine normale Datei kopieren oder eine Partition duplizieren.
> Und was mich schon immer interessierte:
> Rein theoretisch gesehen sind doch alle (kompilierten) Programmiersprachen gleich schnell oder?
Nein, warum sollten sie? Das hängt vom Compiler ab bzw. dem Code, den er produziert. (Allen anders lautenden Aussagen zum Trotz produziert der GCC übrigens ziemlich guten Code.) Oft hängt es auch von der betreffenden Aufgabe ab. Angeblich soll ja bei numerischen Problemen Fortran typischerweise am schnellsten sein.
Cheers,
GNU/Wolfgang
Re: Frage
Hi,
C++ ist gleich schnell wie C. Im schlimmsten Fall ein paar indirekte Funktionsaufrufe mehr, doch solange diese nicht in inneren Schleifen vorkommen, ist das nicht relevant. Andere compilierte Sprachen können je nach Qualität des Compilers und nach der Anwendung schneller oder langsamer als C sein. So sind numerische Programme in Fortran, die mit einem guten Compiler übersetzt wurden, schneller als C, bei Übersetzung mit GNU-Fortran dagegen eher langsamer. Und schlechter handcodierter Assemblercode kann langsamer sein als der Code, den ein guter Compiler erzeugt.
Gruß,
hjb
C++ ist gleich schnell wie C. Im schlimmsten Fall ein paar indirekte Funktionsaufrufe mehr, doch solange diese nicht in inneren Schleifen vorkommen, ist das nicht relevant. Andere compilierte Sprachen können je nach Qualität des Compilers und nach der Anwendung schneller oder langsamer als C sein. So sind numerische Programme in Fortran, die mit einem guten Compiler übersetzt wurden, schneller als C, bei Übersetzung mit GNU-Fortran dagegen eher langsamer. Und schlechter handcodierter Assemblercode kann langsamer sein als der Code, den ein guter Compiler erzeugt.
Gruß,
hjb
Pro-Linux - warum durch Fenster steigen, wenn es eine Tür gibt?
-
Steffan R.
Re: Frage
Nun gut, ich glaube ich verstehe Klassen langsam, ich habe jetzt sogar mal ein kleines Eingabe/Ausgabe Programm mit klassen gemacht:
<blockquote><pre><font size="1" face="">code:</font><hr><font face="Courier New" size="2">
#include<iostream>
using namespace std;
class Test
{
private:
char i[30];
public:
void EA()
{
cout<<"Geben sie irgendwas ein:"<<endl;
cin>>i;
cout<<"Sie haben "<<i<<" eingegeben"<<endl;
};
};
void main ()
{
Test newtest;
newtest.EA();
}
</font><hr></pre></blockquote>
Was haltet ihr von meiner Klasse, ist es so richtig oder völlig falsch?
Und was ist eigentlich besser bzw. richtig, <iostream> mit "using namespace std" bzw. "std::" oder <iostream.h>?
<blockquote><pre><font size="1" face="">code:</font><hr><font face="Courier New" size="2">
#include<iostream>
using namespace std;
class Test
{
private:
char i[30];
public:
void EA()
{
cout<<"Geben sie irgendwas ein:"<<endl;
cin>>i;
cout<<"Sie haben "<<i<<" eingegeben"<<endl;
};
};
void main ()
{
Test newtest;
newtest.EA();
}
</font><hr></pre></blockquote>
Was haltet ihr von meiner Klasse, ist es so richtig oder völlig falsch?
Und was ist eigentlich besser bzw. richtig, <iostream> mit "using namespace std" bzw. "std::" oder <iostream.h>?
Re: Frage
> Und was ist eigentlich besser bzw. richtig,
> #include <iostream> mit "using namespace std" bzw. "std::"
auf jeden Fall richtig
> oder #include <iostream.h>?
könnte auch richtig sein, habe ich aber bei C++ Programmen bisher nur extrem selten (eigentlich nur in gewissen Diskussionsforen wo auch mit M$VS programmiert wird) gesehen
> Was haltet ihr von meiner Klasse, ist es so richtig oder völlig falsch?
die Klasse ist so schon richtig
ABER:
* C++ bietet dir eine eigene String-Klasse "string" an (#include <string>) die dir viele Aufgaben abnimmt die ein C Programmierer machen muss (Speicher belegen/freigen mit malloc/free; Arraylänge anpassen wenn die Stringlänge sich ändert; etc.), wenn er CStrings ("char* variable" oder "char variabel[<!--no--><!--no-->]") verwendet.
* die main Routine soll/muss in C++ immer einen Return Code zurückliefern (auch wenn einige Compiler hier nicht einmal eine Warning ausgeben):
g++ -Wall -o main main.cpp
main.cpp:21: `main´ must return `int´
main.cpp:21: return type for `main´ changed to `int´
also:
int main()
int main(void)
int main(int argc, char** argv)
aber nicht
void main()
void main(void)
void main(int argc, char** argv)
hier dann dein Beispiel
<blockquote><pre><font size="1" face="">code:</font><hr><font face="Courier New" size="2">
#include <iostream> // cin, cout, endl
#include <string> // string
using namespace std;
/////////////////////////////////////////////////////////////////////
// Meine Test Klasse
//
class Test
{
private:
string m_Irgendwas;
public:
void EA();
};
/////////////////////////////////////////////////////////////////////
// Hauptprogramm
//
int main(int argc, char** argv)
{
Test newtest;
newtest.EA();
return 0;
}
/////////////////////////////////////////////////////////////////////
// Implementierung der Funktionen der Test Klasse
//
void Test::EA()
{
std::cout << "Geben Sie irgendwas ein: " << std::endl;
std::cin >> m_Irgendwas;
std::cout << "Sie haben " << m_Irgendwas << " eingegeben." << std::endl;
}
</font><hr></pre></blockquote>
> #include <iostream> mit "using namespace std" bzw. "std::"
auf jeden Fall richtig
> oder #include <iostream.h>?
könnte auch richtig sein, habe ich aber bei C++ Programmen bisher nur extrem selten (eigentlich nur in gewissen Diskussionsforen wo auch mit M$VS programmiert wird) gesehen
> Was haltet ihr von meiner Klasse, ist es so richtig oder völlig falsch?
die Klasse ist so schon richtig
ABER:
* C++ bietet dir eine eigene String-Klasse "string" an (#include <string>) die dir viele Aufgaben abnimmt die ein C Programmierer machen muss (Speicher belegen/freigen mit malloc/free; Arraylänge anpassen wenn die Stringlänge sich ändert; etc.), wenn er CStrings ("char* variable" oder "char variabel[<!--no--><!--no-->]") verwendet.
* die main Routine soll/muss in C++ immer einen Return Code zurückliefern (auch wenn einige Compiler hier nicht einmal eine Warning ausgeben):
g++ -Wall -o main main.cpp
main.cpp:21: `main´ must return `int´
main.cpp:21: return type for `main´ changed to `int´
also:
int main()
int main(void)
int main(int argc, char** argv)
aber nicht
void main()
void main(void)
void main(int argc, char** argv)
hier dann dein Beispiel
<blockquote><pre><font size="1" face="">code:</font><hr><font face="Courier New" size="2">
#include <iostream> // cin, cout, endl
#include <string> // string
using namespace std;
/////////////////////////////////////////////////////////////////////
// Meine Test Klasse
//
class Test
{
private:
string m_Irgendwas;
public:
void EA();
};
/////////////////////////////////////////////////////////////////////
// Hauptprogramm
//
int main(int argc, char** argv)
{
Test newtest;
newtest.EA();
return 0;
}
/////////////////////////////////////////////////////////////////////
// Implementierung der Funktionen der Test Klasse
//
void Test::EA()
{
std::cout << "Geben Sie irgendwas ein: " << std::endl;
std::cin >> m_Irgendwas;
std::cout << "Sie haben " << m_Irgendwas << " eingegeben." << std::endl;
}
</font><hr></pre></blockquote>
Re: Frage
Hi!
Zum Thema "iostream" mit "std::" gegen "iostream.h": Da sich der C++ Standard minütlich ändert, gibt es eben beide Varianten.
Ursprünglich verwendete man die Header mit ".h" und ohne eigenen Namensraum. Damals gab es auch noch keine STL, also keine "string" Klasse und ähnliches. Anscheinend zeitgleich mit der STL wurde die Variante ohne ".h" eingeführt, bei der alles im Nanensraum "std::" ist. Die STL-Header verfügen über keine Variante ohne ".h", da diese teilweise mit den Namen von C-Headern kollidieren würden. Zusätzlich sind die C-Header auch noch via "cstdio" statt "stdio.h" usw. verfügbar, wobei m.W. diese neue Variante ebenfalls in "std::" residiert.
D.h. wärend die Sachen aus "iostream.h" (ohne "std::") nun in "iostream" (mit "std::") sind, sind die C-Funktionen zum Arbeiten mit Strings ohne Namensraum in "string.h" und mit Namensraum in "cstring", wärend in "string" die STL-Klasse "string" zu finden ist.
Nein, es ist nicht logisch oder sinnvoll, sondern C++.
Cheers,
GNU/Wolfgang
Zum Thema "iostream" mit "std::" gegen "iostream.h": Da sich der C++ Standard minütlich ändert, gibt es eben beide Varianten.
Ursprünglich verwendete man die Header mit ".h" und ohne eigenen Namensraum. Damals gab es auch noch keine STL, also keine "string" Klasse und ähnliches. Anscheinend zeitgleich mit der STL wurde die Variante ohne ".h" eingeführt, bei der alles im Nanensraum "std::" ist. Die STL-Header verfügen über keine Variante ohne ".h", da diese teilweise mit den Namen von C-Headern kollidieren würden. Zusätzlich sind die C-Header auch noch via "cstdio" statt "stdio.h" usw. verfügbar, wobei m.W. diese neue Variante ebenfalls in "std::" residiert.
D.h. wärend die Sachen aus "iostream.h" (ohne "std::") nun in "iostream" (mit "std::") sind, sind die C-Funktionen zum Arbeiten mit Strings ohne Namensraum in "string.h" und mit Namensraum in "cstring", wärend in "string" die STL-Klasse "string" zu finden ist.
Nein, es ist nicht logisch oder sinnvoll, sondern C++.
Cheers,
GNU/Wolfgang
Re: Frage
> ... Da sich der C++ Standard minütlich ändert, ...
so so; sieht für mich eher so aus, als sei der ISO C++ Standard bereits seit 1998 "fest" <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">
ISO/IEC 14882-1998: Information Technology - Programming Languages - C++
<a href="http://webstore.ansi.org/ansidocstore/p ... 882%2D1998" target="_blank"><!--auto-->http://webstore.ansi.org/ansidocstore/p ... <!--auto-->
weiteres auf der C++ FAQ bei <a href="http://www.voyager.prima.de/cpp/online.html" target="_blank"><!--auto-->http://www.voyager.prima.de/cpp/online. ... <!--auto-->
> ... gibt es eben beide Varianten. ...
Wobei die Varianten iostream.h und string.h veraltet sind.
Im Standard wird verwendet <iostream> und <string> (C++ Strings); <cstring> (C Strings; das was du mit <string.h> meinst) und <cstdio> (das was bei C in <stdio.h> steht -- allerdings hier im Namespace std::).
siehe auch:
How to mix C and C++
<a href="http://www.parashift.com/c++-faq-lite/m ... d-cpp.html" target="_blank"><!--auto-->http://www.parashift.com/c++-faq-lite/m ... <!--auto-->
> Nein, es ist nicht logisch oder sinnvoll, sondern C++.
IMHO ist es logisch (wenn man sich mal überlegt /warum/ es so gemacht wurde) und daher auch sinnvoll
PS: Ich krieg' dich schon noch dazu, dass du C++ nicht so ablehnst <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
so so; sieht für mich eher so aus, als sei der ISO C++ Standard bereits seit 1998 "fest" <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">
ISO/IEC 14882-1998: Information Technology - Programming Languages - C++
<a href="http://webstore.ansi.org/ansidocstore/p ... 882%2D1998" target="_blank"><!--auto-->http://webstore.ansi.org/ansidocstore/p ... <!--auto-->
weiteres auf der C++ FAQ bei <a href="http://www.voyager.prima.de/cpp/online.html" target="_blank"><!--auto-->http://www.voyager.prima.de/cpp/online. ... <!--auto-->
> ... gibt es eben beide Varianten. ...
Wobei die Varianten iostream.h und string.h veraltet sind.
Im Standard wird verwendet <iostream> und <string> (C++ Strings); <cstring> (C Strings; das was du mit <string.h> meinst) und <cstdio> (das was bei C in <stdio.h> steht -- allerdings hier im Namespace std::).
siehe auch:
How to mix C and C++
<a href="http://www.parashift.com/c++-faq-lite/m ... d-cpp.html" target="_blank"><!--auto-->http://www.parashift.com/c++-faq-lite/m ... <!--auto-->
> Nein, es ist nicht logisch oder sinnvoll, sondern C++.
IMHO ist es logisch (wenn man sich mal überlegt /warum/ es so gemacht wurde) und daher auch sinnvoll
PS: Ich krieg' dich schon noch dazu, dass du C++ nicht so ablehnst <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
It just works.
Re: Frage
Hi!
Ah, eine Diskussion über den PDP-11 Assembler, der sich für ein Objektsystem hält.
> sieht für mich eher so aus, als sei der ISO C++ Standard bereits seit 1998 "fest"
Ich weiß, aber da sich der C++ Standard in der Vergangenheit einfach zu oft auf inkompatible Weise geändert hat, wird C++ diesen (berechtigten) Ruf so schnell nicht loswerden. Eine Sprache, in der sich selbst der Gültigkeitsbereich von Variablen im Laufe der Zeit ändert, stößt naturgemäß bei vielen Leuten eben auf wenig Begeisterung.
> Wobei die Varianten iostream.h und string.h veraltet sind.
Heißt das etwa, dass sie laut Standard eigentlich bereits jetzt nicht mehr gültig wären? Das würde ja das Problem der Inkompatiblität noch verstärken. (Wenn ja, dann danke für den Hinweis *g*)
> IMHO ist es logisch (wenn man sich mal überlegt /warum/ es so gemacht wurde) und daher auch sinnvoll
Vorher hatten wir: iostream.h und string.h
Jetzt haben wir jedoch NICHT: iostream und string
sondern: iostream und cstring
... weil string etwas ganz anderes ist.
Ich finde das nicht logisch.
Logisch und sinnvoll wäre es gewesen, die neuen Header so zu benennen, dass kein Konflikt entstanden wäre. Die Abgrenzung zwischen Sachen, die aus C kommen und solchen, die aus C++ kommen ist für Leute, die C++ lernen wollen, ohne vorher C zu können, eher verwirrend. Und brauchen tut man diese Funktionen oft auch in C++ (z.B. "math.h", äh Verzeihung: "cmath").
> PS: Ich krieg' dich schon noch dazu, dass du C++ nicht so ablehnst
Je mehr ich mich mit C++ befasse, desto mehr lehne ich es ab, das ist das Problem bei der Sache. Du müsstest mich also dazu bringen, mich nicht damit zu befassen, um dieses Ziel zu erreichen. Ich plädiere derzeit allerdings eher dafür, C++ komplett zu verbannen, da ich diese Sprache für kontraproduktiv halte. Insbesondere dann, wenn man Objektorientierung lernen will, aber auch sonst erscheint mir die Kombination aus C und Ruby sinnvoller.
Cheers,
GNU/Wolfgang
Ah, eine Diskussion über den PDP-11 Assembler, der sich für ein Objektsystem hält.
> sieht für mich eher so aus, als sei der ISO C++ Standard bereits seit 1998 "fest"
Ich weiß, aber da sich der C++ Standard in der Vergangenheit einfach zu oft auf inkompatible Weise geändert hat, wird C++ diesen (berechtigten) Ruf so schnell nicht loswerden. Eine Sprache, in der sich selbst der Gültigkeitsbereich von Variablen im Laufe der Zeit ändert, stößt naturgemäß bei vielen Leuten eben auf wenig Begeisterung.
> Wobei die Varianten iostream.h und string.h veraltet sind.
Heißt das etwa, dass sie laut Standard eigentlich bereits jetzt nicht mehr gültig wären? Das würde ja das Problem der Inkompatiblität noch verstärken. (Wenn ja, dann danke für den Hinweis *g*)
> IMHO ist es logisch (wenn man sich mal überlegt /warum/ es so gemacht wurde) und daher auch sinnvoll
Vorher hatten wir: iostream.h und string.h
Jetzt haben wir jedoch NICHT: iostream und string
sondern: iostream und cstring
... weil string etwas ganz anderes ist.
Ich finde das nicht logisch.
Logisch und sinnvoll wäre es gewesen, die neuen Header so zu benennen, dass kein Konflikt entstanden wäre. Die Abgrenzung zwischen Sachen, die aus C kommen und solchen, die aus C++ kommen ist für Leute, die C++ lernen wollen, ohne vorher C zu können, eher verwirrend. Und brauchen tut man diese Funktionen oft auch in C++ (z.B. "math.h", äh Verzeihung: "cmath").
> PS: Ich krieg' dich schon noch dazu, dass du C++ nicht so ablehnst
Je mehr ich mich mit C++ befasse, desto mehr lehne ich es ab, das ist das Problem bei der Sache. Du müsstest mich also dazu bringen, mich nicht damit zu befassen, um dieses Ziel zu erreichen. Ich plädiere derzeit allerdings eher dafür, C++ komplett zu verbannen, da ich diese Sprache für kontraproduktiv halte. Insbesondere dann, wenn man Objektorientierung lernen will, aber auch sonst erscheint mir die Kombination aus C und Ruby sinnvoller.
Cheers,
GNU/Wolfgang
-
Sulu
Re: Frage
@Wolfgang.
Soll ich wegen der Unzulänglichkeiten in C++ nicht anfangen GUI mit QT (Kdevelop) zu programmieren? Ich hab keine Lust Pascal oder was ähnliches zu lernen. Es geht nur um GUI. Number-Crunching macht man sowieso in C <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
Gruss
Andy
Soll ich wegen der Unzulänglichkeiten in C++ nicht anfangen GUI mit QT (Kdevelop) zu programmieren? Ich hab keine Lust Pascal oder was ähnliches zu lernen. Es geht nur um GUI. Number-Crunching macht man sowieso in C <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
Gruss
Andy
Re: Frage
Hi!
> Soll ich wegen der Unzulänglichkeiten in C++ nicht anfangen GUI mit QT (Kdevelop) zu programmieren?
Ob du mit den "Unzulänglichkeiten" leben kannst, ist deine Entscheidung, die ich dir weder abnehmen kann noch will. Wenn's nur um GUIs geht, sollten Ruby, Perl und Python die Anforderungen aber doch wohl auch erfüllen, oder? Und mit Gtk+ gibt's ja ein ganz nettes C-Toolkit (bald in Version 2.0).
Cheers,
GNU/Wolfgang
> Soll ich wegen der Unzulänglichkeiten in C++ nicht anfangen GUI mit QT (Kdevelop) zu programmieren?
Ob du mit den "Unzulänglichkeiten" leben kannst, ist deine Entscheidung, die ich dir weder abnehmen kann noch will. Wenn's nur um GUIs geht, sollten Ruby, Perl und Python die Anforderungen aber doch wohl auch erfüllen, oder? Und mit Gtk+ gibt's ja ein ganz nettes C-Toolkit (bald in Version 2.0).
Cheers,
GNU/Wolfgang
-
Sulu
Re: Frage
Hi Wolf.
Nix mag GTK.
Besser gesagt erst noch anschauen muss.
Sei aber eine recht verwinkelte Sache <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
Will aber lieber KDE-Apps machen da mir das durchgängiger erscheint und die Apps schön im Desktop integrierbar wären und ausserdem gleich noch eine Entwicklungsumgebung geboten wird.
Wobei man sagen muss dass der GIMP (GTK) schon sehr proper daherkommt. Rein optisch gefällt mir der GIMP sogar besser als die KDE-Apps.
Das Ganze ist nicht allzu ernst zu nehmen, da ich erst am ausloten bin und auch nicht die Diskussion hier zu sehr verwässern möchte.
Gruss
Sulu
Nix mag GTK.
Besser gesagt erst noch anschauen muss.
Sei aber eine recht verwinkelte Sache <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
Will aber lieber KDE-Apps machen da mir das durchgängiger erscheint und die Apps schön im Desktop integrierbar wären und ausserdem gleich noch eine Entwicklungsumgebung geboten wird.
Wobei man sagen muss dass der GIMP (GTK) schon sehr proper daherkommt. Rein optisch gefällt mir der GIMP sogar besser als die KDE-Apps.
Das Ganze ist nicht allzu ernst zu nehmen, da ich erst am ausloten bin und auch nicht die Diskussion hier zu sehr verwässern möchte.
Gruss
Sulu
Re: Frage
Hi,
wie oben erwähnt ist bei ANSI C++ das .h weggefallen
um es mal so auszudrücken.
Ob das sinvoll ist oder nicht erschließt sich nicht sofort.
Auch ich hatte meine probleme damit. Und da ANSI C++ "nur"
ein standart ist muss sich kein compiler hersteller zwingend
dran halten und deshalb entsteht meist die inkompatiblität.
So ist die toleranz bei einem angeblichen ANSI C++ konformen
compiler so hoch das man beide varianten benutzen kann <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">.
>Nein, es ist nicht logisch oder sinnvoll, sondern C++.
Ein wichtiger grund weshalb das .h verschwand ist, das bei
ANSI C++ die header nicht mehr dateien repräsentieren. Soll
heißen, die header können bei ANSI C++ im compiler eingebaut
oder als datei irgendwo gespeichert sein.
>plädiere derzeit allerdings eher dafür, C++ komplett zu verbannen...
Hast du dich den schon genauer mit ANSI C++ auseinander gesetzt oder
wie kommst du zu der aussage. Ok, muss ehrlich zugeben das ich von
ANSI C++ nicht die meiste ahnung habe.
PS: ANSI C und ANSI C++ header sind sehr wohl abgegrenzt. Ein ANSI C++
header der ANSI C functionen bereitstellt werden mit einem c geschrieben
sprich string.h = cstring usw... wurde aber hier schon genannt, nur zur
erinnerung.
regards
tHepLaYer
wie oben erwähnt ist bei ANSI C++ das .h weggefallen
um es mal so auszudrücken.
Ob das sinvoll ist oder nicht erschließt sich nicht sofort.
Auch ich hatte meine probleme damit. Und da ANSI C++ "nur"
ein standart ist muss sich kein compiler hersteller zwingend
dran halten und deshalb entsteht meist die inkompatiblität.
So ist die toleranz bei einem angeblichen ANSI C++ konformen
compiler so hoch das man beide varianten benutzen kann <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">.
>Nein, es ist nicht logisch oder sinnvoll, sondern C++.
Ein wichtiger grund weshalb das .h verschwand ist, das bei
ANSI C++ die header nicht mehr dateien repräsentieren. Soll
heißen, die header können bei ANSI C++ im compiler eingebaut
oder als datei irgendwo gespeichert sein.
>plädiere derzeit allerdings eher dafür, C++ komplett zu verbannen...
Hast du dich den schon genauer mit ANSI C++ auseinander gesetzt oder
wie kommst du zu der aussage. Ok, muss ehrlich zugeben das ich von
ANSI C++ nicht die meiste ahnung habe.
PS: ANSI C und ANSI C++ header sind sehr wohl abgegrenzt. Ein ANSI C++
header der ANSI C functionen bereitstellt werden mit einem c geschrieben
sprich string.h = cstring usw... wurde aber hier schon genannt, nur zur
erinnerung.
regards
tHepLaYer