was haltet ihr von Leuten die ne Art C C++ verwenden?
-
In diesem Forum sind relativ viele Leute abgeneigt gegen eine Mischung aus C und C++.

Wenn man die Möglichkeit hat, C++ zu nutzen, sollte man das meiner Ansicht nach auch tun. Viele Dinge sind einfach komfortabler und weniger fehleranfällig (Container zum Beispiel). Es spricht auch nichts dagegen, Container mit WinAPI zu verwenden - als C-Schnittstelle zu Arrays kann man den kompatiblen
std::vectoreinsetzen.Klar, ganz strikt kann man die Trennung vielleicht nicht durchsetzen, denkt man dabei an
<cmath>etc. Auch C-Bibliotheken wie WinAPI sind eigentlich legitim. Aber bei den Dingen, wo equivalente Mittel in der C++-Standardbibliothek vorhanden sind (die gegenüber den C-Methoden meistens Vorteile bieten), würde ich jeweils die C++-Methoden nutzen.Im Weiteren ist C++ nicht nur etwas mehr als C. Die Konzepte und Paradigmen können sich total unterscheiden (OOP, Templates). Gerade bei grösseren Projekten ist es ratsam, dass man sich festlegt, beispielsweise objektorientiert zu programmieren. Dass dann innerhalb noch prozedurale Teile vorkommen, weil sie eben für irgendwelche APIs benötigt werden, ist auch nicht weiter schlimm, solange man im Grossen und Ganzen eine einigermassen konsistente Struktur hat.
-
> Jedenfalls habe ich mir danach ein WINAPI Buch gekauft und jetzt nach ner Zeit verwende ich eigentlich (fast) nur noch so C Elemente und WinApi um Programme zu schreiben.
Welches Buch war das? Das könnte ich gebrauchen, es gibt nur zu wenige gute WinAPI-Tutorien...
An sich könnte man doch auch WinAPI-Klassen verwenden. Zwar beinhalten die nicht was anderes, sind dann aber objektorientiert und dann kann man einheitlich bleiben.
-
Ad aCTa schrieb:
Welches Buch war das? Das könnte ich gebrauchen, es gibt nur zu wenige gute WinAPI-Tutorien...
Windows Programmierung von Charles Petzold ist ein sehr gutes Buch.
Ad aCTa schrieb:
An sich könnte man doch auch WinAPI-Klassen verwenden. Zwar beinhalten die nicht was anderes, sind dann aber objektorientiert und dann kann man einheitlich bleiben.
Die MFC kapselt die WinApi in Klassen.
@Threadersteller du könntest ja die Paradigmen die du nicht benutzt nochmal wiederholen bzw. nachlernen.
-
Melan schrieb:
Die MFC kapselt die WinApi in Klassen.
@Threadersteller du könntest ja die Paradigmen die du nicht benutzt nochmal wiederholen bzw. nachlernen.Unbedingt empfehlenswert. Hat man einmal mit Klassen und Templates gearbeitet, will man gar nicht mehr anders.
(OK, ein wenig übertrieben,aber C++ ist halt schon recht mächtig)
-
drakon schrieb:
Hat man einmal mit Klassen und Templates gearbeitet, will man gar nicht mehr anders.
(OK, ein wenig übertrieben,aber C++ ist halt schon recht mächtig)Kann ich so bestätigen. Ich finds nicht mal so übertrieben...

Man muss einfach aufpassen, dass man nachher nicht die Motivation verliert, weiterhin mit C bzw. WinAPI zu arbeiten... :p
-
Maxximillian schrieb:
Sollte ich dann lieber gleich mit nem C Compiler arbeiten? Mein Freund meinte C in C++ ist nichts halbes und nichts ganzes. Ich hoffe ihr wisst was ich meine.
Nein - ich denke, Du solltest bei dem C++-Compiler bleiben und Dich nach und nach in die Möglichkeiten von C++ einarbeiten.
Dass immer noch (sehr) viele Leute ein C-lastiges C++ schreiben, hängt meines Erachtens mit der bloßen Unkenntnis von vielen Konstruktionen in C++ zusammen.Zum anderen wird es Ihnen auch noch so beigebracht. Wenn ich z.B. diesen Thread hier lese, dann wird schon aus der Aufgabenstellung klar, dass damit niemand niemals wirklich C++ lernt.
C++ ist keine leichte Sprache und man muss neben der Sprache an sich auch noch die C++-Library kennen und vor allen Dingen anwenden lernen.
Dass man bei der WinAPI C-Arrays benötigt, bedeutet nicht, dass man sein ganzes Programm in der Art aufbauen muss. Und außerdem gibt es auch hier Möglichkeiten 'intelligentere' Konstruktionen zu wählen.
Ein Beispiel aus meiner Programmierpraxis:const HANDLE devHandle_ = CreateFile( // ... aus der WinAPI if( devHandle_ == INVALID_HANDLE_VALUE ) { return false; // Fehler } const boost::shared_ptr< void > devHandle( devHandle_, ::CloseHandle );Das 'HANDLE' ist ein void* und durch die Übergabe an einen boost::shared_ptr<> stelle ich sicher, dass die Datei automatisch geschlossen wird (::CloseHandle) sobald der Scope verlassen wird.
Eine Serie von 3 bis 5 API-Aufrufen hintereinander aufzubauen, die - egal welcher von ihnen schief gehen kann - immer in einer korrekten Fehlerbehandlung münden, ist ohne solche Konstruktionen schwer denkbar und mindestens sehr unübersichtlich. Daher würde ich auch hier auf C++ ungern verzichten.
Gruß
Werner
-
Werner Salomon schrieb:
Ein Beispiel aus meiner Programmierpraxis:
const HANDLE devHandle_ = CreateFile( // ... aus der WinAPI if( devHandle_ == INVALID_HANDLE_VALUE ) { return false; // Fehler } const boost::shared_ptr< void > devHandle( devHandle_, ::CloseHandle );wundert mich fast, daß du nicht den schritt weiter gegangen bist nach
boost::shared_ptr< void > WinWrap::CreateFile( /* ... wie WinAPI */ );//throws WinException
-
Werner Salomon schrieb:
Eine Serie von 3 bis 5 API-Aufrufen hintereinander aufzubauen, die - egal welcher von ihnen schief gehen kann - immer in einer korrekten Fehlerbehandlung münden, ist ohne solche Konstruktionen schwer denkbar und mindestens sehr unübersichtlich.
würde ich nicht so direkt sagen.
bool f() { //getDevHandle const HANDLE devHandle_ = CreateFile( ... ); if( devHandle_ == INVALID_HANDLE_VALUE ) goto failGetDevHandle; //getOtherThing const HANDLE otherHandle_ = CreateOther( ... ); if( otherHandle_ == NULL ) goto failGetOtherThing; //weitere drei schachtelungsebenen CloseThing(otherHandle_); failGetOtherThing: CloseHandle(devHandle); failGetDevHandle: return false; }ja, das war der punkt, wo man in c goto braucht.
-
drakon schrieb:
Es gibt gewisse Dinge, die in C++ nicht gehen, die in C funktionieren. Das ist aber nur ein sehr kleiner Teil.
Nur so aus Interesse: Was geht in C, was in C++ nicht geht?
-
tntnet schrieb:
drakon schrieb:
Es gibt gewisse Dinge, die in C++ nicht gehen, die in C funktionieren. Das ist aber nur ein sehr kleiner Teil.
Nur so aus Interesse: Was geht in C, was in C++ nicht geht?
Er meint sicherlich nicht Fähigkeiten. Sondern wohl eher umgesetzte Features. In C++ kannste das hier nicht machen, was aber in C geht:
int x = 5; char a[x];Natürlich kann man das in C++ auf andere Art lösen:
int x = 5; std::vector<char> a(x);Probleme Lösen kann man aber mit beiden Sprachen.
-
tntnet schrieb:
Nur so aus Interesse: Was geht in C, was in C++ nicht geht?
int* x = malloc( sizeof( int ) * 10 ); assert( sizeof( char ) != sizeof( 'a' ) ); // in C99 int func( int size ) { char array[ size ]; } struct tm y = { .tm_mday = 11 };
-
Melan schrieb:
Ad aCTa schrieb:
Welches Buch war das? Das könnte ich gebrauchen, es gibt nur zu wenige gute WinAPI-Tutorien...
Windows Programmierung von Charles Petzold ist ein sehr gutes Buch.
Hm, hab grad darueber gelesen, dass es eher fuer C-Programmierer besser geeignet ist. Ich will jedoch nicht den gleichen Fehler wie der Threadsteller machen

Ist das Buch trotzdem empfehlenswert?
-
Eric Cartman schrieb:
Melan schrieb:
Ad aCTa schrieb:
Welches Buch war das? Das könnte ich gebrauchen, es gibt nur zu wenige gute WinAPI-Tutorien...
Windows Programmierung von Charles Petzold ist ein sehr gutes Buch.
Hm, hab grad darueber gelesen, dass es eher fuer C-Programmierer besser geeignet ist.
Das haben Bücher über die WinApi so an sich
-
Ich versuche Leute nicht anhand des Codes zu beurteilen, sondern anhand dessen, was dabei rauskommt. Wen interessierts, wie der Code geschrieben ist (solange es nicht C&P von der nächstbesten OSS-App ist ) solange er das macht, was er soll?
rya.
-
scorcher24@arbyte schrieb:
Ich versuche Leute nicht anhand des Codes zu beurteilen, sondern anhand dessen, was dabei rauskommt. Wen interessierts, wie der Code geschrieben ist (solange es nicht C&P von der nächstbesten OSS-App ist ) solange er das macht, was er soll?
rya.Jeder beurteilt andere nach dem Code, das kannst du mir doch nicht erzaehlen :p
Man kann eine Sache einfach oder auch umstaendlich loesen. Wenns umstaendlich geloest wird, zeigt das meistens eine fehlende Erfahrung.
-
scorcher24@arbyte schrieb:
Ich versuche Leute nicht anhand des Codes zu beurteilen, sondern anhand dessen, was dabei rauskommt. Wen interessierts, wie der Code geschrieben ist (solange es nicht C&P von der nächstbesten OSS-App ist ) solange er das macht, was er soll?
rya.Hä? Wie Code geschrieben ist, ist wichtig! Das hat auch was mit Wartungsfähigkeit u.ä. zu tun. Ich glaube das heißt "Nachhaltigkeit". Egal ist das nicht! Natürlich kann jeder z.B. einen eigenen Stil haben, dieser darf aber nicht zu weit abdriften, vom "guten Ton".
-
scorcher24@arbyte schrieb:
Ich versuche Leute nicht anhand des Codes zu beurteilen, sondern anhand dessen, was dabei rauskommt. Wen interessierts, wie der Code geschrieben ist (solange es nicht C&P von der nächstbesten OSS-App ist ) solange er das macht, was er soll?
Sehr weitsichtig ist diese Sichtweise aber nicht. Was wäre, wenn du den Code verstehen oder sogar daran weiter arbeiten müsstest?
Zu den Fähigkeiten eines Programmierers gehört nicht nur, ein lauffähiges Programm fertig zu bringen, sondern auch Code gut zu strukturieren und somit eine effiziente Wartung und Erweiterung zu ermöglichen. Bei Frickelcode ist die Wahrscheinlichkeit auch viel höher, dass Fehler drin stecken, die man schwer findet (zum Beispiel undefiniertes Verhalten, das in 99% der Fälle gut geht).
-
ja, das war der punkt, wo man in c goto braucht.
Nein!
LordJaxom schrieb:
...Alles gekuenstelte Beispiele. Tja, man muss halt casten, assert und static assert sind in C++ verfuegbar und wer Arrays variabler Laenge auf dem Stack anlegt, sollte lieber Baecker werden.
-
knivil schrieb:
ja, das war der punkt, wo man in c goto braucht.
Nein!
Man kanns auch mit ner dummen tiefen if-verschachtelung machen wenn man masochist ist...
aber ich würde da lieber goto nehmen. goto ist nämlich garnicht böse...
-
Shade Of Mine schrieb:
Man kanns auch mit ner dummen tiefen if-verschachtelung machen wenn man masochist ist...
aber ich würde da lieber goto nehmen. goto ist nämlich garnicht böse...Dem stimme ich zu. Das gilt ganz besonders für goto's die im Code nach unten springen.
Ich finde die Lösung von Volkard wirklich gut. Leider habe ich sowas in den Beispielen, die MS in der Doku zur API zur Verfügung stellt, nie gefunden.Gruß
Werner