unverständliche C++ Codeabschnitt

[Hans_Berlin (Gast)]

Hallo Zusammen,

ich verstehe folgende Codeabschnitt nicht:

struct SQLError : public std::runtime_error {
   SQLError(const std::string& msg) 
      : std::runtime_error (std::string("SQL-Fehler: ") + msg) {
   }
};

Das es um eine struct sich handelt weiss ich schon

[The D. (thedaz)]

Was genau daran verstehst du nicht ? Structs sind Klassen, deren members 
und Methoden allesamt public sind. SQLError wird von runtime_error 
exception Klasse abgeleitet und deklariert einen Konstruktor.

[Peter II (Gast)]

Hans_Berlin schrieb:
> Das es um eine struct sich handelt weiss ich schon

und das ist nicht mal ganz richtig. struct und klasse sind in C++ das 
gleiche, bei einer Struct sind alle member public.

Es ist also eine neue Klasse die von std::runtime_error abgeleitet ist. 
Sie hat einen Konstruktor der den Konstruktor von std::runtime_error 
intern aufruft.

[Hans_Berlin (Gast)]

Peter II schrieb:
> und das ist nicht mal ganz richtig. struct und klasse sind in C++ das
> gleiche, bei einer Struct sind alle member public.
>
> Es ist also eine neue Klasse die von std::runtime_error abgeleitet ist.
> Sie hat einen Konstruktor der den Konstruktor von std::runtime_error
> intern aufruft.

Geht es das auch bei struct ?
Okay das wusste ich nicht bzw. solche Code ist sehr sehr selten zu sehen
aber danke für die Hinweise

struct kann es auch ein einen Konstruktor haben ...

[Peter II (Gast)]

Hans_Berlin schrieb:
> Geht es das auch bei struct ?

in diesem Fall ist eine Struct das gleiche wie eine klasse.

[Dr. Sommer (Gast)]

Hans_Berlin schrieb:
> Okay das wusste ich nicht bzw. solche Code ist sehr sehr selten zu sehen
Quatsch, die GNU C++ Standard Library z.B. ist voll mit sowas, weil die 
Leute zu faul sind überall "public:" zu schreiben, wenn eine Klasse 
onehin keine "private" members hat...

[Rene H. (Gast)]

Hans_Berlin schrieb:
> Peter II schrieb:
> und das ist nicht mal ganz richtig. struct und klasse sind in C++ das
> gleiche, bei einer Struct sind alle member public.
> Es ist also eine neue Klasse die von std::runtime_error abgeleitet ist.
> Sie hat einen Konstruktor der den Konstruktor von std::runtime_error
> intern aufruft.
>
> Geht es das auch bei struct ?
> Okay das wusste ich nicht bzw. solche Code ist sehr sehr selten zu sehen
> aber danke für die Hinweise
> struct kann es auch ein einen Konstruktor haben ...

Ja, das geht. Es ist aber sicher kein Stil den Du Dir zueigen machen 
solltest.

[Dr. Sommer (Gast)]

Rene H. schrieb:
> Ja, das geht. Es ist aber sicher kein Stil den Du Dir zueigen machen
> solltest.
Wieso? Wird von vielen Leuten genau so verwendet. Nur weil das in Java 
nicht geht muss man in C++ nicht drauf verzichten :P

[Rene H. (Gast)]

Dr. Sommer schrieb:
> ieso? Wird von vielen Leuten genau so verwendet. Nur weil das in Java
> nicht geht muss man in C++ nicht drauf verzichten :P

Nun, in C und C++ sind wesentlich mehr sauereien möglich. Man macht das 
aber nicht.
Nur weil man es kann, muss es nicht gut sein.

[The D. (thedaz)]

Rene H. schrieb:
> Dr. Sommer schrieb:
>> ieso? Wird von vielen Leuten genau so verwendet. Nur weil das in Java
>> nicht geht muss man in C++ nicht drauf verzichten :P
>
> Nun, in C und C++ sind wesentlich mehr sauereien möglich. Man macht das
> aber nicht.
> Nur weil man es kann, muss es nicht gut sein.

Was daran ist schlecht? Ich meine, was ist das Argument außer 'sowas tut 
man nicht'?

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Rene H. schrieb:

> Ja, das geht. Es ist aber sicher kein Stil den Du Dir zueigen machen
> solltest.

Was spricht dagegen? Ich würde das `public` vor der Basicklasse noch weg 
lassen und dem c'tor dafür ein `explicit` spendieren.

[Rene H. (Gast)]

The D. schrieb:
> Rene H. schrieb:
> Dr. Sommer schrieb:
> ieso? Wird von vielen Leuten genau so verwendet. Nur weil das in Java
> nicht geht muss man in C++ nicht drauf verzichten :P
>
> Nun, in C und C++ sind wesentlich mehr sauereien möglich. Man macht das
> aber nicht.
> Nur weil man es kann, muss es nicht gut sein.
>
> Was daran ist schlecht? Ich meine, was ist das Argument außer 'sowas tut
> man nicht'?

Weil es viele nicht verstehen. Die Wartbarkeit von Code ist wichtig.
Structs und Klassen lassen sich in ihrer Funktion klar trennen. Dann 
gibt man dem Kind auch den Namen den es verdient.

Das ist wie:

A==2? B=5 : B=0;

[Andreas E. (hismastersvoice)]

Wenn das public weg ist, kommt man nicht mehr an die what() Funktion der 
Exception.
Wäre ungünstig, wenn man dann SQLError in einem Catch Block fängt und 
den Fehlergrund über what() ausgeben möchte.

[Sebastian V. (sebi_s)]

Andreas E. schrieb:
> Wenn das public weg ist, kommt man nicht mehr an die what()
> Funktion der
> Exception.
> Wäre ungünstig, wenn man dann SQLError in einem Catch Block fängt und
> den Fehlergrund über what() ausgeben möchte.

Viel wichtiger: Ohne public könnte man nichtmal eine Exception von 
diesem Typ werfen, weil der Konstruktor private ist.

Edit: Achso wir jeden von dem public beim erben...

[Markus F. (mfro)]

Rene H. schrieb:
> Weil es viele nicht verstehen.

Dann sollten sie auch nicht versuchen, C++ zu programmieren. Structs 
kommen bei Stroustrup im zweiten Kapitel vor, ihre Vererbung im dritten.

Lange bevor das Wort "class" zum ersten Mal auftaucht.

[Rene H. (Gast)]

Markus F. schrieb:
> Dann sollten sie auch nicht versuchen, C++ zu programmieren. Structs
> kommen bei Stroustrup im zweiten Kapitel vor, ihre Vererbung im dritten.

Der Gute Bjarne ist veraltet. Wie gesagt, bloss weil es die Sprache 
zulässt, ist es nicht gut.

Edit: Man kann beliebig viele sauereien in der Sprache anstellen. 
Trotzdem sind sie nicht gut oder besser, schon gar nicht schneller.
Eine Struct ist eine Struct! Eine Klasse eine Klasse.

[Sebastian V. (sebi_s)]

Rene H. schrieb:
> Edit: Man kann beliebig viele sauereien in der Sprache anstellen.
> Trotzdem sind sie nicht gut oder besser, schon gar nicht schneller.
> Eine Struct ist eine Struct! Eine Klasse eine Klasse.

In C++ gibt es nunmal keinen großen Unterschied zwischen diesen beiden. 
Oder ist bei dir ein Struct nur tatsächlich ein Struct wenn es das in C 
schon gewesen wäre?

[Rene H. (Gast)]

Sebastian V. schrieb:
> In C++ gibt es nunmal keinen großen Unterschied zwischen diesen beiden.
> Oder ist bei dir ein Struct nur tatsächlich ein Struct wenn es das in C
> schon gewesen wäre?

Ja, das ist es.

[Rene H. (Gast)]

Anderst gefragt: gibt es einen Grund nicht alle Klassen Struct zu 
nennen?

[Chris F. (chfreund)]

Rene H. schrieb:
> Anderst gefragt: gibt es einen Grund nicht alle Klassen Struct zu
> nennen?

Ja, den gibt es. Private oder geschützte Mitglieder einer Klasse sind 
nur von der Klasse selber verwendbar. Wenn Du eine API erstellst kannst 
Du so direkt zeigen welche Werte nicht "von außen" geändert werden 
dürfen. Außerdem ist es auch guter Stil wenn man Dinge die nicht zur 
Schnittstelle gehören auch nicht verfügbar macht.

Es gibt übrigens auch in C++ (soweit mir bekannt bei allen üblichen 
Compilern sog. C-POD-structs, wenn nur ordinale Datentypen in einer 
struct verwendet werden, diese haben keine vTable und sind wie der Name 
sagt Plain Old Data "am Stück". So kann man Komposit-Übergabeparameter 
verwenden. Das empfiehlt auch Stroustrup für die Compilerentwicklung. 
Obendrein muss man dann auch das alignment beachten.

[Rene H. (Gast)]

Chris F. schrieb:
> Ja, den gibt es. Private oder geschützte Mitglieder einer Klasse sind
> nur von der Klasse selber verwendbar.

Meines Wissens, und mein Compiler lässt das auch zu, ist private in der 
Struct möglich.

[Sebastian V. (sebi_s)]

Chris F. schrieb:
> wenn nur ordinale Datentypen in einer
> struct verwendet werden, diese haben keine vTable

Was haben Membervariablen mit dem vtable zu tun?

Im übrigen gehen Sachen als POD durch die kein gültiges C sind:

#include <iostream>
#include <type_traits>

class foo // Diese Klasse ist ein POD
{
protected:
  int x, y;

  int bar() {
    return 1;
  }
};

int main() {
  std::cout << std::is_pod<foo>::value << std::endl;
}

[Rene H. (Gast)]

Chris F. schrieb:

> Es gibt übrigens auch in C++ (soweit mir bekannt bei allen üblichen
> Compilern sog. C-POD-structs, wenn nur ordinale Datentypen in einer
> struct verwendet werden, diese haben keine vTable und sind wie der Name
> sagt Plain Old Data "am Stück". So kann man Komposit-Übergabeparameter
> verwenden. Das empfiehlt auch Stroustrup für die Compilerentwicklung.
> Obendrein muss man dann auch das alignment beachten.

Jein. Das gilt nur wenn die Datenbus Breite nicht überschritten wird.

[Chris F. (chfreund)]

Rene H. schrieb:
> Meines Wissens, und mein Compiler lässt das auch zu, ist private in der
> Struct möglich.

Natürlich geht das. "struct" in C++ ist einach default-public.

struct
{
//Inhalt
}

entspricht

class
{
public:
//Inhalt
}

[The D. (thedaz)]

Sebastian V. schrieb:
> Chris F. schrieb:
>> wenn nur ordinale Datentypen in einer
>> struct verwendet werden, diese haben keine vTable
>
> Was haben Membervariablen mit dem vtable zu tun?
>
> ...

Exakt. Die vtable kommt mit der ersten virtuellen Methode und hat null 
mit member Variablen zu tun.

[Rene H. (Gast)]

Chris F. schrieb:
> Rene H. schrieb:
>
> Natürlich geht das. "struct" in C++ ist einach default-public.
> struct
> {
> //Inhalt
> }
>
> entspricht
>
> class
> {
> public:
> //Inhalt
> }

Kann es sein, dass man aneinander vorbei redet?

[Chris F. (chfreund)]

The D. schrieb:
> Sebastian V. schrieb:
>> Chris F. schrieb:
>>> wenn nur ordinale Datentypen in einer
>>> struct verwendet werden, diese haben keine vTable
>>
>> Was haben Membervariablen mit dem vtable zu tun?
>>
>> ...
>
> Exakt. Die vtable kommt mit der ersten virtuellen Methode und hat null
> mit member Variablen zu tun.

Die vtable steht am Anfang im RAM und sorgt dafür, dass ein C++-Objekt 
ganz sicher kein "POD" ist. Bei einer C-artigen struct mit bekanntem 
alignment kann man anhand des Quelltext die relative Adresse der Member 
genau berechnen, bei einem C++-Objekt mit vTable nicht.

[Dr. Sommer (Gast)]

Chris F. schrieb:
> Die vtable steht am Anfang im RAM
Nein, eher im Flash, da konstant. Das Objekt enthält nur einen Pointer.

Chris F. schrieb:
> und sorgt dafür, dass ein C++-Objekt
> ganz sicher kein "POD" ist.
Nur wenn das Objekt virtuelle Funktionen hat, sonst hat es keine vtable.

Chris F. schrieb:
> kann man anhand des Quelltext die relative Adresse der Member
> genau berechnen
Nur wenn man genau die Eigenheiten des Compilers + Plattform kennt.

Chris F. schrieb:
> bei einem C++-Objekt mit vTable nicht.
... und wenn man diese kennt, inkl. der Eigenheiten bzgl. vtable, kann 
man das hier auch. Allerdings verbietet C++ die Nutzung von offsetof 
u.a. bei Typen mit vtable...

[Dr. Sommer (Gast)]

Rene H. schrieb:
> Der Gute Bjarne ist veraltet.
Auch sein neues Buch über den neuesten Sprachstandard?
> Wie gesagt, bloss weil es die Sprache
> zulässt, ist es nicht gut.
Aber das Argument, dass irgendwelche Lernfaule es nicht verstehen 
könnten, zieht hier nicht. Wer C++ Code lesen will, sollte mindestens 
mal die Sprachkonstrukte kennen und mindestens das wissen, was in 
Bjarne's Buch steht. Wenn ich immer nur die Sprachmittel in meinem Code 
verwende, die jeder Depp versteht, kommt da ja nie etwas heraus. Das 
neue C++ e

> Edit: Man kann beliebig viele sauereien in der Sprache anstellen.
> Trotzdem sind sie nicht gut oder besser, schon gar nicht schneller.
> Eine Struct ist eine Struct! Eine Klasse eine Klasse.
Nein, ein struct ist das selbe wie eine Klasse. Das steht so im 
Standard, da kannst du nicht dran rütteln.

[The D. (thedaz)]

Es stimmt allerdings, das viele Entwickler es sich zur Gewohnheit 
gemacht haben, struct als simple Daten-Container ohne Methoden zu 
benutzen (wie in C) und class für alles, was darüber hinausgeht. 
Insofern kann man über best practices streiten, wenn man will. Der 
Standard macht hier keine Empfehlung.

[Chris F. (chfreund)]

Dr. Sommer schrieb:
> Chris F. schrieb:
>> Die vtable steht am Anfang im RAM
> Nein, eher im Flash, da konstant. Das Objekt enthält nur einen Pointer.
Ja, das stimmt, je nach Compiler unterscheidet sich das, aber meistens 
ist es ein Zeiger auf eine Tabelle von virtuellen Funktionen.

> Chris F. schrieb:
>> und sorgt dafür, dass ein C++-Objekt
>> ganz sicher kein "POD" ist.
> Nur wenn das Objekt virtuelle Funktionen hat, sonst hat es keine vtable.
Ah ja, gut, ich schreibe: Wenn es eine vTable hat ist es kein POD, 
Antwort darauf ist: es hat nur eine vTable wenn es virtuelle Methoden 
hat. lol ... so ein Geflame.

>
> Chris F. schrieb:
>> kann man anhand des Quelltext die relative Adresse der Member
>> genau berechnen
> Nur wenn man genau die Eigenheiten des Compilers + Plattform kennt.
Das ist leider Falsch. Bei C und bei sog. POD, mit bekanntem alignment, 
ist es eine Vorgabe, dass man genau die Speichergröße kennt und genau 
weiß wo die Member im Speicher sind. So baut man eine externe Linkage 
auf, z.B. wenn Du von Deinem Assembler oder COBOL, oder sonstwas,-Tool 
etwas übergibst oder übergeben bekommst

>
> Chris F. schrieb:
>> bei einem C++-Objekt mit vTable nicht.
> ... und wenn man diese kennt, inkl. der Eigenheiten bzgl. vtable, kann
> man das hier auch. Allerdings verbietet C++ die Nutzung von offsetof
> u.a. bei Typen mit vtable...
Damit widersprichst Du Dir ja selber. So ein whataboutism ist auch 
wieder nur Flame. Wenn man alle Spezifikationen von irgendwas kennt kann 
man das immer entgegen der Design-Rules einsetzen. Äh ja.

[Dr. Sommer (Gast)]

Chris F. schrieb:
> Das ist leider Falsch. Bei C und bei sog. POD, mit bekanntem alignment,
Und woher kennt man das Alignment? Wenn man Compiler+Plattform kennt. 
Denn das Alignment kann man ja sogar per Compiler-Option o.ä. 
einstellen. Einem Stück C-Code ohne weitere Kenntniss der Plattform kann 
man da gar nichts zum Layout sagen.

Chris F. schrieb:
> Ah ja, gut, ich schreibe: Wenn es eine vTable hat ist es kein POD,
Ich meinte nur, dass nur weil etwas ein C++ Objekt ist, es nicht 
notwendigerweise eine vtable hat. Das klang so in deinem Beitrag.

Chris F. schrieb:
> Damit widersprichst Du Dir ja selber. So ein whataboutism ist auch
> wieder nur Flame. Wenn man alle Spezifikationen von irgendwas kennt kann
> man das immer entgegen der Design-Rules einsetzen. Äh ja.
Ich sage nur dass man es genausogut ausrechnen kann wie bei POD-Typen 
(und  dass es nicht völlig unbekannt ist), nicht dass man es im Code tun 
sollte.

[Arc N. (arc)]

Dr. Sommer schrieb:
> Chris F. schrieb:
>> Das ist leider Falsch. Bei C und bei sog. POD, mit bekanntem alignment,
> Und woher kennt man das Alignment? Wenn man Compiler+Plattform kennt.
> Denn das Alignment kann man ja sogar per Compiler-Option o.ä.
> einstellen. Einem Stück C-Code ohne weitere Kenntniss der Plattform kann
> man da gar nichts zum Layout sagen.

Was auch egal wäre, da der Compiler das mit einer entsprechenden 
offsetof-Implementation auch selber könnte. Er muss es sogar wissen, um 
das ABI konstant zu halten.

Allerdings sagt der Standard bspw. auch: "The order of allocation of 
non-static data members with different access control is unspecified"

Wenn die Compiler-Schreibenden also Bock hätten, dürften sie das von 
Version zu Version ändern. Gäbe zwar ein heilloses Chaos, dafür aber ein 
völlig standardkonformes.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Rene H. schrieb:

> Weil es viele nicht verstehen. Die Wartbarkeit von Code ist wichtig.

Ja, aber wir reden hier nicht von irgend welchen obskuren, dunklen Ecken 
der Sprache. Wenn ich mit C++ mein Geld verdienen möchte, dann gibt es 
exakt überhaupt keine Ausrede, solche Basics nicht zu kennen. (Beispiel: 
http://en.cppreference.com/w/cpp/utility/pair)

Das Anfänger dann immer gleich alles als "unsauber", "den Mist hat mein 
Vorgänger verbrochen" etc. bezeichnen, nervt echt! Es kann doch nicht zu 
viel verlangt sein, sich mal mit den Werkzeugen, mit denen man arbeitet 
zu beschäftigen und mal etas offener für andere Lösungen zu sein.

> Das ist wie:
>
>

> A==2? B=5 : B=0;
>

Ja, das ist auch wieder so ein Beispiel. Der ternary operator kann sehr 
praktisch sein, man muss dem ganzen auch einfach mal eine Chance geben.

Ich empfinde code wie

std::string plural;

if ( count > 1 )
    plural = "autos";
else
    plural = "auto";

als deutlich schlechter lesbar als:

const std::string plural = count > 1
    ? "autos"
    : "auto";

Hier kann ich plural sofort als Konstante deklarieren. Der Type von 
plural braucht keinen default c'tor und plural hat keinen unnötigen 
Zwischenzustand.

> Der Gute Bjarne ist veraltet. Wie gesagt, bloss weil es die Sprache
> zulässt, ist es nicht gut.

Die 4. Auflage ist von 2014.

Andreas E. schrieb:

> Wenn das public weg ist, kommt man nicht mehr an die what() Funktion
> der Exception.

bei structs ist der default beim Erben auch `public`

mfg Torsten

[Rene H. (Gast)]

Torsten R. schrieb:
> Das Anfänger dann immer gleich alles als "unsauber", "den Mist hat mein
> Vorgänger verbrochen" etc. bezeichnen, nervt echt!

Nun, nach 27 Jahren C und C++ würde ich mich nicht als "Anfänger" 
bezeichnen. Und ja, es ist nach wie vor meine Meinung, dass dieses 
Konstrukt unsauber ist. Und das wird Dir jeder halbwegs Erfahrene C++ 
Programmierer sagen.

[Rene H. (Gast)]

Torsten R. schrieb:
> Das Anfänger dann immer gleich alles als "unsauber", "den Mist hat mein
> Vorgänger verbrochen" etc. bezeichnen, nervt echt!

Noch was, das ist ein Ehrenkodex. Ein Programmierer scheisst einem 
anderen Coder nicht in den Garten. Sowas macht man nicht.

[Dr. Sommer (Gast)]

Rene H. schrieb:
> Nun, nach 27 Jahren C und C++ würde ich mich nicht als "Anfänger"
> bezeichnen.
Haha, niedlich. Verzichtest du dann auch auf "template <typename... T>" 
weil das 95% der "C++ Programmierer (lol)" nicht verstehen?

Rene H. schrieb:
> Und das wird Dir jeder halbwegs Erfahrene C++
> Programmierer sagen.
d.h. die Programmierer der Boost Library und GNU C++ Standard Library 
sind unerfahren, weil sie so etwas ständig verwenden?

Rene H. schrieb:
> Noch was, das ist ein Ehrenkodex. Ein Programmierer scheisst einem
> anderen Coder nicht in den Garten. Sowas macht man nicht.
AHaha, so wirklich in der echten Welt scheinst du ja nicht zu leben. 
Schau mal im Linux Source Code, ob du vor lauter Scheiße überhaupt noch 
Garten siehst :3

[Rene H. (Gast)]

Dr. Sommer schrieb:
> Haha, niedlich. Verzichtest du dann auch auf "template <typename... T>"
> weil das 95% der "C++ Programmierer (lol)" nicht verstehen?

Ich verwende es wenn es Sinn macht.

Dr. Sommer schrieb:
> d.h. die Programmierer der Boost Library und GNU C++ Standard Library
> sind unerfahren, weil sie so etwas ständig verwenden?

Kann sein. Boost ist eine tolle Sache, wenn man es bewusst einsetzt. 
Bloss weil man Boost::ASIO kennt, muss man es nicht immer brauchen.

Dr. Sommer schrieb:
> AHaha, so wirklich in der echten Welt scheinst du ja nicht zu leben.
> Schau mal im Linux Source Code, ob du vor lauter Scheiße überhaupt noch
> Garten siehst :3

Es wäre mir neu, wenn es DEN Linux Source Code gibt (ausser dem Kernel).

BTW: Den Diminutiv kannst Du Dir bei dem Thema schenken.

[Dr. Sommer (Gast)]

Rene H. schrieb:
> Ich verwende es wenn es Sinn macht.
Also so wie bei struct als "class mit public".

Rene H. schrieb:
> Kann sein.
Ich glaube weniger, dass die Entwickler der besten und verbreitetsten 
C++ Library unerfahren sind.

Rene H. schrieb:
> Es wäre mir neu, wenn es DEN Linux Source Code gibt (ausser dem Kernel).
Logischerweise war mit "Linux Source Code" der Code des Kernels mit dem 
Namen "Linux" gemeint. Dein Programmierer-Ehrencodex ist ein 
Wunschtraum, es gibt unendlich viel miesen Code.

Rene H. schrieb:
> BTW: Den Diminutiv kannst Du Dir bei dem Thema schenken.
Bin ich blind? Wo soll ich den denn verwendet haben?

[Rene H. (Gast)]

Dr. Sommer schrieb:
> Also so wie bei struct als "class mit public"

Das macht nie Sinn.

Dr. Sommer schrieb:
> Ich glaube weniger, dass die Entwickler der besten und verbreitetsten
> C++ Library unerfahren sind.

Die beste Library? Unerfahren, ja sind die meisten. Es mag für den 
Alltag taugen, aber nicht wenn es um High Performance geht (ich meine 
Highperformance wo 128 Cores am werken sind).

Dr. Sommer schrieb:
> Dein Programmierer-Ehrencodex ist ein
> Wunschtraum, es gibt unendlich viel miesen Code.

Miesen Code gibt es immer.

[Dr. Sommer (Gast)]

Rene H. schrieb:
> Das macht nie Sinn.
Du hast noch nie Metaprogrammierung gemacht. Schau dir nur mal solchen 
Code aus der Boost::MPL an:
https://github.com/boostorg/mpl/blob/develop/include/boost/mpl/assert.hpp
Oder aus der GNU C++ stdlib:
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/tuple

Wenn man sowas oft macht, freut man sich über jedes gesparte "public".

Rene H. schrieb:
> Es mag für den
> Alltag taugen, aber nicht wenn es um High Performance geht (ich meine
> Highperformance wo 128 Cores am werken sind).
Und was hat das mit class/struct zu tun? Boost kann trotzdem qualitativ 
hochwertig sein. Die Boost::MPL ist geeignet für alles vom 8-Bitter bis 
zum HPC-Cluster, weil dort nur compiletime-Algorithmen drin sind..

[Rene H. (Gast)]

Dr. Sommer schrieb:
> Du hast noch nie Metaprogrammierung gemacht. Schau dir nur mal solchen
> Code aus der Boost::MPL an:

Das stimmt. Mit MPL habe ich mich bislang nicht befasst.

Dr. Sommer schrieb:
> Und was hat das mit class/struct zu tun? Boost kann trotzdem qualitativ
> hochwertig sein. Die Boost::MPL ist geeignet für alles vom 8-Bitter bis
> zum HPC-Cluster, weil dort nur compiletime-Algorithmen drin sind..

Nichts, man ist vom Thema abgekommen. Wie gesagt, Boost ist eine tolle 
Sache.

[Jodel (Gast)]

Dr. Sommer schrieb:
> Chris F. schrieb:
>> Die vtable steht am Anfang im RAM
> Nein, eher im Flash, da konstant. Das Objekt enthält nur einen Pointer.

So ein Super-Profi bist du wohl doch nicht... schau das besser nochmal 
nach.

[Jodel (Gast)]

Rene H. schrieb:
> Dr. Sommer schrieb:
>> Und was hat das mit class/struct zu tun? Boost kann trotzdem qualitativ
>> hochwertig sein. Die Boost::MPL ist geeignet für alles vom 8-Bitter bis
>> zum HPC-Cluster, weil dort nur compiletime-Algorithmen drin sind..
> Nichts, man ist vom Thema abgekommen. Wie gesagt, Boost ist eine tolle
> Sache.

Leute die MPL "oft brauchen" sollte man ganze infach meiden. Und ihren 
Code auch.

[Dr. Sommer (Gast)]

Jodel schrieb:
> Leute die MPL "oft brauchen" sollte man ganze infach meiden. Und ihren
> Code auch.

Jaja, was der Bauer nicht kennt/versteht, etc.

Jodel schrieb:
> So ein Super-Profi bist du wohl doch nicht... schau das besser nochmal
> nach.
Ja, der C++ Standard spezifiziert das nicht fix, aber viele Compiler 
machen es genau so. Kannst du gerne ausprobieren.

[Hans_Berlin (Gast)]

Hi Zusammen,


ich finde diese Diskussion hat nicht mit struct und class zu tun eher 
persönlich geworden.
Das muss nicht sein.
Lassen wir uns wie Erwachsen miteinander umgehen bzw. als Softis.

Danke

[Hans_Berlin (Gast)]

Hi Zusammen,


eine Frage zu struct bzw. class  habe ich noch.

Ich habe folgende Anwendung:
eine C-Wrapper für einen Labview Interface, die so ungefähr aussieht:
/* Headder*/
// MeasureStart ist die gewrapperte Class

.........
extern "C"__declspec (dllexport) int measureWrapper(MeasureStart *LV_ref);
.....

/*cpp*/
.....
extern "C"__declspec (dllexport) int measureWrapper(MeasureStart *LV_ref)
{
    int Error = 0;
    ErrorHandlingWrapper* errorHandlingWrapper = new ErrorHandlingWrapper() ;
    try
    {
        LV_ref->MeasureCont();
    }
    catch(QString &msg)
    {
        if(errorHandlingWrapper->IsThisError(msg))
        {
            Error = errorHandlingWrapper->IsThisError(msg);
        }
        else
        {
            Error = UnknownErrorConst;     
        }
   
    }
    DeleteAndNull(errorHandlingWrapper);
    return Error;
}
 
// Aufräumen Arbeit
template<typename T>
void DeleteAndNull(T*& pointer)
{
    if(pointer != NULL)
    {
        delete pointer;
        pointer = 0;
    }
}

class ErrorHandlingWrapper sieht ungefähr so aus:

/*Header class ErrorHandlingWrapper */
typdef enum ErrorList{
    DiodeVoltageError = 5000,
    LEDCurrentError,
    .....
 
 
}t_ErrorList;
 
class ErrorHandlingWrapper
{
 
public:
    ErrorHandlingWrapper(void);
    ~ErrorHandlingWrapper(void);
   
    int IsThisError(QString &msg);
 
};

/*cpp Teil*/

ErrorHandlingWrapper::ErrorHandlingWrapper(void)
{
}
 
ErrorHandlingWrapper::~ErrorHandlingWrapper(void)
{
}
 
int ErrorHandlingWrapper::IsThisError(QString &msg)
{
    t_ErrorList Error = static_cast<t_ErrorList>(0);
   
    if (!msg.compare(QString("ErrorVoltage/Parameter Error")))
        Error = DiodeVoltageError;
        ........
    // hier werden alle mögliche Error in dieses DLL abgefangen
    // es ist nicht schön gelöst aber auf einen Feadback wird mich freuen
    ....
}

Für die ErrorHandlingWrapper wäre nicht besser einen struct anzuwenden?
/*Ich weiss, dass es schlecht programmiert und ich werde mich sehr 
freuen für jeden Feadback */

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Hans_Berlin schrieb:

> Für die ErrorHandlingWrapper wäre nicht besser einen struct anzuwenden?

Wenn c'tor und d'tor eh leer sind, solltest Du sie auch nicht 
deklarieren. Dann landest Du plötzlich bei einer Klasse, ohne member und 
mit einer Funktion.

Dann ist es eine Funktion und dann würde ich auch eine Funktion draus 
machen.

BTW: Nie Objekt in C++ mit new erzeugen, wenn es nicht sein muss. C++ 
ist nicht Java.

[Hans_Berlin (Gast)]

Torsten R. schrieb:
> BTW: Nie, nimmer nicht eine member-Funktion über einen null-Pointer
> aufrufen!!!11

Sorry was meinst du hier?

[Dr. Sommer (Gast)]

Hans_Berlin schrieb:
> ErrorHandlingWrapper* errorHandlingWrapper = new ErrorHandlingWrapper() ;
>     ...
>     DeleteAndNull(errorHandlingWrapper);
Das geht viel einfacher:

auto errorHandlingWrapper = std::make_unique<ErrorHandlingWrapper> ();

Die Freigabe erfolgt automatisch (kein delete und DeleteAndNull mehr 
nötig) und sicher (auch wenn MeasureCont noch irgendwelche anderen 
Exceptions wirft!).

Oder warum nicht ganz einfach:

ErrorHandlingWrapper errorHandlingWrapper;

Und somit den Compiler das Aufräumen erledigen lassen?

Oder noch anders:
Wozu ist die Klasse ErrorHandlingWrapper überhaupt da? Warum nicht 
einfach eine schnöde Funktion machen:

int IsThisError(const QString &msg) {
 ...
}

Das "const" zeigt, dass du in der Funktion den String nicht ändern 
möchtest (was ich mal vermutet habe).

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Hans_Berlin schrieb:

> Sorry was meinst du hier?

Sorry, habe mich noch korrigiert.

[Jodel (Gast)]

Dr. Sommer schrieb:
> Jodel schrieb:
>> Leute die MPL "oft brauchen" sollte man ganze infach meiden. Und ihren
>> Code auch.
> Jaja, was der Bauer nicht kennt/versteht, etc.

Been there, done that. Wir haben es benutzt, weil es sich als Loesung 
aufgedraengt hat, nicht weil wir Feature-Freaks waren. Und die Meinung 
war einstimmig: Hoffentlich muss das keiner mehr anfassen. Aber ein 
Feature-Freak kann das nicht verstehen.

> Jodel schrieb:
>> So ein Super-Profi bist du wohl doch nicht... schau das besser nochmal
>> nach.
> Ja, der C++ Standard spezifiziert das nicht fix, aber viele Compiler
> machen es genau so. Kannst du gerne ausprobieren.

Been there, done that. War nicht so.

[Dr. Sommer (Gast)]

Jodel schrieb:
> Been there, done that. Wir haben es benutzt, weil es sich als Loesung
> aufgedraengt hat, nicht weil wir Feature-Freaks waren. Und die Meinung
> war einstimmig: Hoffentlich muss das keiner mehr anfassen. Aber ein
> Feature-Freak kann das nicht verstehen.
Been there, done that. Habe aus Spaß die MPL Funktionen nachgebaut. Die 
Nutzer des dabei enstandenen Frameworks, die eher Programmier-Anfänger 
waren, waren begeistert weil es so schön einfache Programmierung 
ermöglichte.
>> Jodel schrieb:
>>> So ein Super-Profi bist du wohl doch nicht... schau das besser nochmal
>>> nach.
>> Ja, der C++ Standard spezifiziert das nicht fix, aber viele Compiler
>> machen es genau so. Kannst du gerne ausprobieren.
>
> Been there, done that. War nicht so.
BTDT, z.B. beim GCC und beim MS-CL ist das so.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Dr. Sommer schrieb:
>> Been there, done that. War nicht so.
> BTDT, z.B. beim GCC und beim MS-CL ist das so.

@Jodel: Würde mich aber jetzt auch mal interessieren, welche Compiler es 
anders machen, wie sie es machen und warum?

[Rene H. (Gast)]

Torsten R. schrieb:
> @Jodel: Würde mich aber jetzt auch mal interessieren, welche Compiler es
> anders machen, wie sie es machen und warum?

Ich vermute Clang.

[Hans_Berlin (Gast)]

Noch eine Frage bitte im Bezug auf die "Labview Interface", die ich oben 
kurz genannt habe.


Es geht eigentlich um folgende:

#ifdef __cplusplus
#endif

typedef struct MeasureStart MeasureStart;

extern "C"__declspec (dllexport) MeasureStart* createMeasureWrapper(bool boPower);
extern "C"__declspec (dllexport) int destoryMeasureWrapper(MeasureStart* LV_ref);

.....

#ifdef __cplusplus
#endif
#endif

die cpp Teil sieht so aus:

extern "C"__declspec (dllexport) MeasureStart* createMeasureWrapper(bool boPower)
{
       return new MeasureStart(boPower);
}
extern "C"__declspec (dllexport) int destoryMeasureWrapper(MeasureStart* LV_ref)
{
      delete LV_ref;
      // bei der Zertörung des Objects LV_ref soll ich noch was  brücksichtigen? 
}
....

Warum ich das frage?:

Auf Labview Seite wenn ich mit dem Application fertig bin und meine MAIN 
VI schliesse das stürtze Labvien ab?
Gründe können sehr viel sein:
zb. eine verwitwete Zeiger ....

Sorry noch mal

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Hans_Berlin schrieb:

> Gründe können sehr viel sein:
> zb. eine verwitwete Zeiger ....

Genau. Ich sehe keinen Grund, in dem von Dir gezeigten Code. Hast Du es 
schon mal mit Tools wie Valgrind etc. probiert (Debug Heap etc.)?

[Jodel (Gast)]

Torsten R. schrieb:
> Dr. Sommer schrieb:
>>> Been there, done that. War nicht so.
>> BTDT, z.B. beim GCC und beim MS-CL ist das so.
> @Jodel: Würde mich aber jetzt auch mal interessieren, welche Compiler es
> anders machen, wie sie es machen und warum?

Ich weiss nicht, was der gcc auf AVR macht, aber auf Linux legt er ganz 
sicher die vtable nicht in den Flash. Und du kannst die auch problemlos 
mit ein wenig Ungeschick (oder natuerlich Absicht) zur Laufzeit aendern. 
Alles schon gesehen!

[Rolf Magnus (Gast)]

Jodel schrieb:
> Torsten R. schrieb:
>> Dr. Sommer schrieb:
>>>> Been there, done that. War nicht so.
>>> BTDT, z.B. beim GCC und beim MS-CL ist das so.
>> @Jodel: Würde mich aber jetzt auch mal interessieren, welche Compiler es
>> anders machen, wie sie es machen und warum?
>
> Ich weiss nicht, was der gcc auf AVR macht, aber auf Linux legt er ganz
> sicher die vtable nicht in den Flash. Und du kannst die auch problemlos
> mit ein wenig Ungeschick (oder natuerlich Absicht) zur Laufzeit aendern.
> Alles schon gesehen!

Eigentlich sollte doch klar sein, dass das komplett vom Zielsystem und 
vom Compiler abhängt. Deshalb ist es vollkommener Blödsinn, sich darüber 
zu streiten, wo "der Compiler" jetzt die vtable ablegt.

[Kevin (Gast)]

Auf meinem Windows-Laptop mit Visual Studio 2015 legt er die vtable ganz 
sicher nicht in den Flash!!!

Been there, done that!!! Alles schon gesehen!!!

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Ich glaube, hierfür komme ich in die Hölle ;-) :

enum struct function
{
    build_image,
    add_header
};