Aber ich frage mich, warum du kenie C++ Mittel verwendest. Die sind ja um einiges bequemer und freundlicher in der Handhabung, als die Sachen in 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::vector einsetzen.

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.

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.

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)

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

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

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

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.

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?

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.

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 };

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?

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.

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.

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".

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.

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...

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

goto ist nämlich garnicht böse...

Nur wenn man vorsichtig ist und nicht wilde kreuz- und quer-Sprünge macht, die die Wartung zur Hölle machen und dafür sorgen, dass die Herrschaften von der Qualitätssicherung verfrüht ihre Rente beantragen müssen. Das selbe gilt aber auch für viele andere Dinge, die allgemein als "böse" bezeichnet werden, z.B. C-Style Pointercasts. Das Feature an sich ist nicht böse. Die Benutzung durch jemanden, der genau weiß was er tut und das auch mitteilen kann ist auch nicht böse. Solch ein Feature jemandem in die Hand zu drücken, der es dann exzessiv missbraucht und dadurch Horror-Code produziert, das ist das Böse daran.

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.

m$ verwendet für sowas __try/__finally, ein spezielles feature ihres compilers.

Die Benutzung durch jemanden, der genau weiß was er tut und das auch mitteilen kann ist auch nicht böse. Solch ein Feature jemandem in die Hand zu drücken, der es dann exzessiv missbraucht und dadurch Horror-Code produziert, das ist das Böse daran.

Das mag zwar auf der einen Seite stimmen, aber gerade was C-Casts angeht habe ich mehrere Gründe die C++ Casts vorzuziehen: Man kann leichter im Code suchen, falls man doch mal was ändern muss, oder über ein Problem stolpert.

Es stimmt das einige Feature - nötige Kenntnisse vorausgesetzt - nicht so böse sind wie gerne gesagt, manchmal gibt es aber mehr als einen Grund warum man sie dennoch meidet...