C++ Zwei char vergleichen

Es ist irrelevant welche IDE man für C++ verwendet, solange der Compiler standardkonform arbeitet. Der Code (ANSI C++ oder Qt) ist plattformunabhängig und das reicht.

Wer unter Windows entwickelt, der ist mit Visual Studio 2010 bestens bedient. Die IDE von Microsoft ist exzellent. Nicht ganz so exzellent für die Entwicklung mit C++, wie für .NET, aber es reicht. Refactoring etc. ist nunmal bei einer derart komplexen Sprache, wie C++ selten in einer IDE vorzufinden und meist ist es nichts vernünftiges.

Wer natürlich ständig zwischen Linux, Mac oder Windows hin und her wechselt, ist mit einer plattformunabhängen IDE wahrscheinlich besser bedient.

Aber das ist sowieso völlig egal. Ich verwende beispielsweise NetBeans für Java und PHP, Visual Studio für C# und C/C++. Gelegentlich auch mal Eclipse.
 
Das ist alles gut und schön, für einen Anfänger aber völlig uninteressant. Die ersten Schritte macht der TE auch ohne STL und Cross-Plattform IDE. Als nächstes schlagt ihr noch vor, er solle das Quizprogramm zuerst in UML designen ...

Wer auf der Suche nach einer guten IDE unter Windows ist, wird bei Microsoft sicher fündig. VisualStudio 2010 ist derzeit auch meine erste Wahl. Auf Embarcaderos C++ Builder (seinerzeit von Borland bzw. Inprise entwickelt) sollte man aber auch ein Auge werfen bevor man sich festlegt. Insbesondere als RAD Werkzeug für UI-Entwicklung und UI-Prototyping, auch wenn Microsoft hier mittlerweile auch gute Werkzeuge anbietet.

Das sind aber professionelle Werkzeuge mit denen ein Anfänger schnell überfordert ist. Und teils auch Profis manchmal zur Verzweiflung treibt ;)
 
Was für ein Blödsinn! Hier hat kein Mensch dem Threadersteller eine Cross-Plattform IDE vorgeschlagen.

Und zum Thema STL sei gesagt. Die STL gehört zu C++, wie der Speck zum Frühstücksei.

Was ist das überhaupt für eine absurde Argumentation? Der Threadersteller benutzt auch iostream und die Ausgabeanweisung cout. Diese gehört zu den STL Streamklassen, d.h. er benutzt bereits die STL.

Auch string ist Bestandteil der STL. Willst du mir jetzt erzählen der Ausdruck

Code:
string name = "Bob";
string nachname = "Marley";
if(name == nachname)
    cout << name;

würde einen Anfänger überfordern, während

Code:
char name[] = "Bob";
char nachname[] = "Marley";
if(strcmp(nachname, name) == 0)
    cout << nachname;

kein Problem darstellt? Wenn dem so ist, dann sollte man am besten gleich das Programmieren sein lassen.
 
@Stefan_Sch

Und zum Thema STL sei gesagt.
... dass der TE die C++ Standard Library benutzt und nicht die STL deren Namen wir hier so salopp verwenden. Der TE benutzt also keineswegs die STL, nicht einmal, wenn er STLport als Bibliothek nutzt.

steinalte IDE (DevC++) verwendet, die seit 1857 nicht mehr weiterentwickelt wird
Die letzte Final von Bloodshed Dev-C++ stammt meines Wissens aus dem Jahr 2005. So alt ist das gar nicht, ich arbeite oft genug mit älteren IDEs und Compilern. Die Unterschiede und Feinheiten zu C++0x sind für den TE als Anfänger belanglos.

Das hat nichts mit Härte zu tun, sondern mit Korrektheit. Wenn man C++ verwendet, dann sollte man auch C++ verwenden und nicht eine Mischung aus C und C++.
Die C++ Standard Bibliothek enthält die gesamte C Bibliothek, und C++ enthält C. Was man wie verwendet ist grundsätzlich eine Stilfrage, die den TE erst später beschäftigen wird, wenn er die Grundlagen begriffen hat.

Ich persönlich war vor vielen Jahren froh, Ratschläge von C++-Experten zu erhalten, die mir meine Fehler aufzeigten und mir dabei halfen Sachverhalte besser zu verstehen.
Ich zweife daran, dass unsere Diskussion dem TE hilft, irgend etwas besser zu verstehen - das bedaure ich.

Warum hier cstring und auch noch cstdio zusammen mit iostream verwendet wird bleibt wohl ein Geheimnis für alle Ewigkeit.
Das ist kein Geheimnis, sondern das Ergebnis der ersten Schritte eines Anfängers, der herumprobiert. Ein C++ Experte sollte eigentlich verstehen warum das so ist - er hat selbst so angefangen ;)
 
Winterday schrieb:
... dass der TE die C++ Standard Library benutzt und nicht die STL deren Namen wir hier so salopp verwenden. Der TE benutzt also keineswegs die STL, nicht einmal, wenn er STLport als Bibliothek nutzt.

Das ist so nicht richtig. Die Standardbibliothek implementiert zahlreiche Algorithmen und Funktionen aus der STL, insofern greift sie durchaus auf die STL zurück, auch wenn sie davon unabhängig arbeitet. Prinzipiell ist die STL nur ein Teil der Standardbibliothek.

Aber natürlich kannst du diesen Korinthenkackerscheiß fortführen. Dummerweise kann man deine Argumentation genauso umdrehen und gegen dich wenden.

string ist nämlich Bestandteil der Standardbibliothek und nicht der STL. Inwiefern es nun Sinn macht iostream aus der Standardbibliothek zu verwenden, string aber nicht, das müsstest du hier schon plausibel darlegen. :rolleyes:

Diese Antwort bist du bisher nämlich schuldig geblieben und versuchst dich stattdessen in irgendwelche Ausflüchte zu retten.

Winterday schrieb:
Die letzte Final von Bloodshed Dev-C++ stammt meines Wissens aus dem Jahr 2005. So alt ist das gar nicht, ich arbeite oft genug mit älteren IDEs und Compilern. Die Unterschiede und Feinheiten zu C++0x sind für den TE als Anfänger belanglos.

Hier geht es nicht um C++0x. DevC++ erlaubt es unter anderem die Uralt-Header, wie iostream.h, einzubinden, die noch nicht im Standardnamensraum versammelt sind. Bestimmte Templatekonstrukte quittiert der Compiler mit einem Fehler. Darüberhinaus produziert der Compiler lausigen Maschinencode.

Da die IDE nicht mehr weiterentwickelt wird, hat sie keine Zukunft.

Es gibt keinen Grund DevC++ zu verwenden, nur die eigene Sturheit.

Winterday schrieb:
Die C++ Standard Bibliothek enthält die gesamte C Bibliothek, und C++ enthält C. Was man wie verwendet ist grundsätzlich eine Stilfrage, die den TE erst später beschäftigen wird, wenn er die Grundlagen begriffen hat.

Nein. Die C++ Standardbibliothek enthält keinerlei C-Bibliotheken, nur neue C-Header. Die C-Bibliothek ist eine Standalone Runtime Library.

C++ ist lediglich größtenteils abwärtskompatibel zu C, aber das hört auch schon bei der Semantik von Structs auf.

Darüberhinaus ist es mit Sicherheit keine einfache Stilfrage. C++ ist eine eigene Sprache und ist streng zu trennen von C. Du wirst auf den meisten Embedded Systemen kein C++ Code ausführen können, sehr wohl aber C Code.

Winterday schrieb:
Ich zweife daran, dass unsere Diskussion dem TE hilft, irgend etwas besser zu verstehen - das bedaure ich.

Wie bitte? Den Threadersteller darauf hinzuweisen C und C++ nicht zu mischen und ihm den korrigierten Code zu zeigen, soll nicht hilfreich sein?!

Was wäre dann hilfreich? Ihm einen Arschtritt zu verpassen damit er schnallt was Sache ist oder ihn einfach abzunicken und darauf zu spekulieren das der Threadersteller eines fernen Tages von alleine feststellt das es da noch soetwas wie eine Stringklasse in C++ gibt?

Winterday schrieb:
Das ist kein Geheimnis, sondern das Ergebnis der ersten Schritte eines Anfängers, der herumprobiert. Ein C++ Experte sollte eigentlich verstehen warum das so ist - er hat selbst so angefangen

Falsch! Weder ist dass das Resultat von Anfängerschritten, noch fängt ein "C++-Experte" so an.

So fängt jemand an, der keine Ahnung hat was er da eigentlich macht und, statt sich ein vernünftiges Buch zu kaufen oder Tutorial zu lesen, seine Informationen irgendwo aus dem Netz zusammenkopiert. Und das auch noch von offensichtlich lausigen Seiten.
 
Zuletzt bearbeitet:
Stefan_Sch schrieb:
Darüberhinaus ist es mit Sicherheit keine einfache Stilfrage. C++ ist eine eigene Sprache und ist streng zu trennen von C. Du wirst auf einem Embedded System kein C++ Code ausführen können, sehr wohl aber C Code.

Ich stimme dem Rest deines Beitrags größten Teils zu, aber hier muß ich Einspruch erheben. ;) Zufällig geht es nämlich in meinem Beruf zu einem nicht unerheblichen Teil um C++ und embedded systems (ARM und MIPS CPUs).
 
Zuletzt bearbeitet: (Rechtshcreibugn)
antred schrieb:
Zufällig geht es nämlich in meinem Beruf zu einem nicht unerheblichen Teil um C++ und embedded systems (ARM und MIPS CPUs).

Der Begriff Embedded Systems war offensichtlich zu pauschal von mir gewählt. ;) C++ spielt sicherlich auch in diesem Bereich eine signifikante Rolle, wobei C immer noch weit mehr dominiert.

Ich verweise auf viele Infineon Controller (C166, etc.). Die Embedded Development Tools von KEIL sind nachwievor hauptsächlich C-Compiler.
 
Zuletzt bearbeitet:
@Stefan_Sch

C++ ist lediglich größtenteils abwärtskompatibel zu C, aber das hört auch schon bei der Semantik von Structs auf.
Demzufolge kann der TE auch nicht C und C++ mischen, Dein ursprünglicher Einwand ist also obsolet. Wir diskutieren folglich nur über den Programmierstil und die verwendeten Bibliotheken.

The C++ Standard Library also incorporates the ISO C90 C standard library.
und
Header files in the C++ Standard Library do not end in ".h". However, the C++ Standard Library includes 18 header files from the C Standard Library, with ".h" endings. Their use is deprecated.
(Quelle: http://en.wikipedia.org/wiki/C++_Standard_Library)

C++ is designed to be as compatible with C as possible, therefore providing a smooth transition from C
(Quelle: http://en.wikipedia.org/wiki/C++)
Ich muss meine Aussage folglich korrigieren, dass C ein Teil von C++ sei. Korrekt ist, dass C++ auf C basiert und nahezu vollständig kompatibel ist. Somit mischt der TE nicht C und C++ - und wir landen wieder bei der Stilfrage.

Die Standardbibliothek implementiert zahlreiche Algorithmen und Funktionen aus der STL, insofern greift sie durchaus auf die STL zurück, auch wenn sie davon unabhängig arbeitet. Prinzipiell ist die STL nur ein Teil der Standardbibliothek.
Wenn wir es so sehen, darf man durchaus behaupten, C sei ein Teil von C++ und dass die C Standard Library ein Teil der C++ Standard Library ist. Wenn wir es aber genau nehmen, stimmt keine Behauptung, denn C++ Standard Library und STL sind zwei voneinander unabhängige Bibliotheken, bei der keine von beiden ein Subset der anderen ist.

Aber natürlich kannst du diesen Korinthenkackerscheiß fortführen. Dummerweise kann man deine Argumentation genauso umdrehen und gegen dich wenden.
Dann betrachten wir einmal die Tatsachen und lernen alle etwas daraus. Insofern hat der TE jetzt doch ein paar Dinge über C, C++ und die Standard Libraries erfahren ;)
 
Winterday schrieb:
Wenn wir es aber genau nehmen, stimmt keine Behauptung, denn C++ Standard Library und STL sind zwei voneinander unabhängige Bibliotheken, bei der keine von beiden ein Subset der anderen ist.

Wie? std::vector, string, map, etc. sind deiner Meinung nach NICHT Teil der C++ Standard Library? Wie kommst du zu diesem Schluß?
 
Winterday schrieb:
Demzufolge kann der TE auch nicht C und C++ mischen, Dein ursprünglicher Einwand ist also obsolet.

Selbstverständlich kann er C und C++ mischen, schließlich ist C++ abwärtskompatibel zu C. Sobald er eine C-Funktion aufruft, verwendet er die C-Runtimes. Diese sind zwar mit C90 Bestandteil von C++, weil C++ nunmal größtenteils abwärtkompatibel zu C ist, aber er verlässt damit die C++-Runtimes und das macht keinen Sinn.

Abwärtskompatibilität bedeutet nicht das es Sinn macht in C++ im C-Stil zu programmieren!

Kompatibilität mit C

Um an die Verbreitung der Programmiersprache C anzuknüpfen, wurde C++ als Erweiterung von C gemäß dem damaligen Stand von 1990 (ISO/IEC 9899:1990, auch kurz C90 genannt) entworfen.

Die Kompatibilität mit C zwingt C++ aber auch zur Fortführung einiger dadurch übernommener Nachteile. Dazu zählt die teilweise schwer verständliche C-Syntax, der als überholt geltende Präprozessor sowie verschiedene von der jeweiligen Plattform abhängige Details der Sprache. Plattformabhängigkeiten erschweren die Portierung von C++-Programmen zwischen unterschiedlichen Rechnertypen, Betriebssystemen und Compilern.

Die letzten Änderungen an C fanden im Jahr 1999 statt (ISO/IEC 9899:1999, auch kurz C99 genannt), also nach der Normung von C++, sodass dort eingeflossene Änderungen nicht in C++ berücksichtigt werden konnten.

Winterday schrieb:
Wir diskutieren folglich nur über den Programmierstil und die verwendeten Bibliotheken.

Was heißt "nur über den Programmierstil und die verwendeten Bibliotheken". Natürlich geht es NUR um den Programmierstil und die verwendeten Bibliotheken. Dass das Programm auch mit C-Funktionen funktioniert, wissen wir auch alle, schließlich ist auch C eine vollwertige Programmiersprache. :rolleyes:

Winterday schrieb:
und

Header files in the C++ Standard Library do not end in ".h". However, the C++ Standard Library includes 18 header files from the C Standard Library, with ".h" endings. Their use is deprecated.


(Quelle: http://en.wikipedia.org/wiki/C++)

Ich hoffe du weißt was der Begriff "deprecated" in deinen Zitaten bedeutet. Falls nicht, hier eine Begriffserklärung.

In computer software or authoring programs standards and documentation, the term deprecation is applied to software features that are superseded and should be avoided.

http://en.wikipedia.org/wiki/Deprecation

Winterday schrieb:
Ich muss meine Aussage folglich korrigieren, dass C ein Teil von C++ sei. Korrekt ist, dass C++ auf C basiert und nahezu vollständig kompatibel ist.

Das C++ größtenteils abwärtskompatibel zu C ist, hatte ich hier schon lange erwähnt.

Winterday schrieb:
Wenn wir es so sehen, darf man durchaus behaupten, C sei ein Teil von C++ und dass die C Standard Library ein Teil der C++ Standard Library ist. Wenn wir es aber genau nehmen, stimmt keine Behauptung, denn C++ Standard Library und STL sind zwei voneinander unabhängige Bibliotheken, bei der keine von beiden ein Subset der anderen ist.

Das die STL unabhängig von der Standardbibliothek arbeitet, hatte ich auch bereits erwähnt. Auch hatte ich erwähnt das die STL als Teil der Standardbibliothek bezeichnet wird, nicht zuletzt deshalb, weil die Standardbibliothek sehr viele Funktionen aus der STL übernommen hat.

C++ was designed to support object-orientated programming. It also supports "polymorphism", allowing routines to be written without needing to worry at a high level about the type of the data, thus allowing "generic" programming. This is useful, not least because it is often as easy to write a general (and reusable) solution to a problem as it is to tackle a particular case.

However, this support hasn't always been easy to use. Templates (which were introduced into C++ in 1989) helped. In 1995 the Standard Template Library (STL) was developed, which uses templates to provide users with easy access to powerful generic routines. The STL is now part of the C++ Standard, subsumed within the "Standard Library". With it, programmers can express concepts in a more natural way, and at a higher level of abstraction, without losing the efficiency and power of C. Furthermore, by reducing the need for loops and the "switch" keyword the STL helps make code more sequential, so that it's simpler as well as more powerful.

http://www.eng.cam.ac.uk/help/tpl/talks/C++.html

und weiter

What is the "STL"?

STL ("Standard Templates Library") is a library that consists mainly of (very efficient) container classes, along with some iterators and algorithms to work with the contents of these containers.

Technically speaking the term "STL" is no longer meaningful since the classes provided by the STL have been fully integrated into the standard library, along with other standard classes like std:: ostream, etc.

http://www.parashift.com/c++-faq-lite/class-libraries.html

Winterday schrieb:
Dann betrachten wir einmal die Tatsachen und lernen alle etwas daraus. Insofern hat der TE jetzt doch ein paar Dinge über C, C++ und die Standard Libraries erfahren

Ich bin es langsam leid mit dir andauernd denselben Mist durchzukauen und anschließend zuzusehen, wie du erneut irgend ein abstruses Ablenkungsmanöver startest, um dich um deine ursprüngliche Ausage zu drücken.

Bleibt als Resümee festzuhalten. Du kannst weder einen Grund liefern, warum der TE Dev-C++ verwenden sollte, noch kannst du den Einsatz von C-Strings anstatt von string begründen.

Dein ursprünglicher Einwand

Winterday schrieb:
Als nächstes schlagt ihr noch vor, er solle das Quizprogramm zuerst in UML designen ...

ist absolut haltlos, wie meine Codebeispiele gezeigt haben. Die Nutzung von string ist für den TE nämlich deutlich einfacher, als die Nutzung von C-Strings, die besonders in Verbindung von strlen oder strcmp und beim Einlesen massive Gefahren eines Buffer Overflows nach sich ziehen.

Wie auch immer. Diese Diskussion ist völlig fruchtlos, nicht zuletzt, weil es dem TE offensichtlich vollkommen am Arsch vorbei geht. Insofern klinke ich mich hier auch aus, ich habe sinnvolleres zu tun.
 
Zuletzt bearbeitet:
Wie? std::vector, string, map, etc. sind deiner Meinung nach NICHT Teil der C++ Standard Library? Wie kommst du zu diesem Schluß?

Nein, was ich meinte ist in der Wikipedia schön formuliert:

The C++ Standard Library is based upon conventions introduced by the Standard Template Library (STL). Although the C++ Standard Library and the STL share many features, neither is a strict superset of the other. For example, the C++ Standard Library does not provide an slist container.
Quelle: http://en.wikipedia.org/wiki/C++_Standard_Library


An meiner ursprünglichen Meinung ändert sich auch nichts. Die Fehler in seinem Programm wurden dem TE vor Stefan_Schs ersten Beitrag bereits aufgezeigt und behoben. So viele neue Elemente verwirren nur unnötig, wenngleich deren Erwähnung gut gemeint sein mag.
 
Zuletzt bearbeitet:
Zurück
Oben