C zu C++ - Einfacherer Übergang?

[volkard]

veritySeeker schrieb:

Const gibt es auch in C. Aber benutze enums für Konstanten. Ein "const" kann weggecastet werden. Enumerations sind wirklich konstant.

Wie kommt man nur auf so einen Unsinn?

[veritySeeker]

volkard schrieb:

veritySeeker schrieb:

Const gibt es auch in C. Aber benutze enums für Konstanten. Ein "const" kann weggecastet werden. Enumerations sind wirklich konstant.

Wie kommt man nur auf so einen Unsinn?

Welche der vier Sätze hälst Du für Unsinn?

[Dravere]

veritySeeker schrieb:

C++ ohne Klassen wäre nichts wert.

Java ohne Klassen wäre nichts wert.
C# ohne Klassen wäre nichts wert.
usw.
Was ist dass denn für eine Aussagen? Können es auch auch so machen:
C ohne Zeiger wäre nichts wert.

Klar wenn du ein zentraler Bestandteil der Sprache wegnimmst, ist sie nicht mehr so viel wert! Aber deswegen zu sagen, dass der einzige Unterschied zwischen C und C++ nur die Klassen sind, ist eine ziemlich seltsame Schlussfolgerung, welche ich überhaupt nicht nachvollziehen kann. Sonst könnten wir ja auch sagen, dass der Unterschied zwischen Java, C#, usw. und C nur die Klassen sind, da Java, C#, usw. auch nichts wert sind ohne Klassen...

Grüssli

[volkard]

veritySeeker schrieb:

volkard schrieb:

veritySeeker schrieb:

Const gibt es auch in C. Aber benutze enums für Konstanten. Ein "const" kann weggecastet werden. Enumerations sind wirklich konstant.

Wie kommt man nur auf so einen Unsinn?

Welche der vier Sätze hälst Du für Unsinn?

Alles von Dir ist Unsinn. Hier der Versuch, PI in einen enum zu stopfen. enum hat doch nicht den Zweck, const zu ersetzen. Wegcastbarkeit (mit undefiniertem Verhalten) ist auch kein Argument.

[veritySeeker]

volkard schrieb:

veritySeeker schrieb:

volkard schrieb:

veritySeeker schrieb:

Const gibt es auch in C. Aber benutze enums für Konstanten. Ein "const" kann weggecastet werden. Enumerations sind wirklich konstant.

Wie kommt man nur auf so einen Unsinn?

Welche der vier Sätze hälst Du für Unsinn?

Alles von Dir ist Unsinn. Hier der Versuch, PI in einen enum zu stopfen. enum hat doch nicht den Zweck, const zu ersetzen. Wegcastbarkeit (mit undefiniertem Verhalten) ist auch kein Argument.

Zugegeben, Pi kann nicht per enum dargestellt werden. Hier hilft tatsächlich nur noch #define. Bevor jetzt jemand mit Typsicherheit kommt: #define M_PI 3.141592653589793238462643 hat einen Typ. Der Dezimalpunkt zeichnet die Konstante eindeutig als "double" aus.

Wegcastbarkeit von "const" ist sehr wohl ein Argument (C++ unterstützt dies sogar noch durch den eigens dafür geschaffenen const_cast<...>). Ich ziehe es vor, wenn mir ein Compiler sagt, daß ich Mist baue, anstatt mich stillschweigend mit undefiniertem Verhalten zu bestrafen. Und ein #define ... Literal, oder enum, wirst Du mit allen Casts der Welt nicht beschreibbar machen können.

Wie wir sehen, hat C++ gegenüber C in puncto Konstanten keine sinnvolle Neuerung gebracht, eher im Gegenteil: C++ hat, wie so oft, ein nichtvorhandenes Problem adressiert und damit eine zusätzliche Fehlermöglichkeit eingeführt, ohne auch nur das Geringste zu verbessern.

[Shade Of Mine]

veritySeeker schrieb:

Wegcastbarkeit von "const" ist sehr wohl ein Argument (C++ unterstützt dies sogar noch durch den eigens dafür geschaffenen const_cast<...>). Ich ziehe es vor, wenn mir ein Compiler sagt, daß ich Mist baue, anstatt mich stillschweigend mit undefiniertem Verhalten zu bestrafen.

Absichtlich Mistbauen kann man immer.
Aber du kannst ein const PI nicht verändern. Darum geht es doch. caste das const halt weg und weise zu - klappt eh nicht.

Genauso ist das mit #define doof:

#define PI 3

int main() {
  cout<<PI;
#undef PI
#define PI 2
  cout<<PI;
}

auch nicht wirklich const. Oder enum?

enum { PI=3; };
int main() {
#define PI 2;
  cout<<PI;
}

Das ist ein NULL Argument. Denn gegen boshaftigkeit kann man sich nicht schützen...

[Dravere]

veritySeeker schrieb:

Wegcastbarkeit von "const" ist sehr wohl ein Argument (C++ unterstützt dies sogar noch durch den eigens dafür geschaffenen const_cast<...>). Ich ziehe es vor, wenn mir ein Compiler sagt, daß ich Mist baue, anstatt mich stillschweigend mit undefiniertem Verhalten zu bestrafen. Und ein #define ... Literal, oder enum, wirst Du mit allen Casts der Welt nicht beschreibbar machen können.

Wie wir sehen, hat C++ gegenüber C in puncto Konstanten keine sinnvolle Neuerung gebracht, eher im Gegenteil: C++ hat, wie so oft, ein nichtvorhandenes Problem adressiert und damit eine zusätzliche Fehlermöglichkeit eingeführt, ohne auch nur das Geringste zu verbessern.

Wenn du schon die C++ Casts nennst, dann sollte dir klar sein, dass C++ durchaus sinnvolle Neuerungen gebracht hat, indem es einen separaten const_cast eingeführt hat.

int const CONSTANT = 10;

static_cast<int&>(CONSTANT) = 10; // FEHLER
*reinterpret_cast<int*>(&CONSTANT) = 10; // FEHLER
*((int*)&CONSTANT) = 10; // Tjaja, C halt.
*const_cast<int*>(&CONSTANT) = 10; // Und nur so geht es mit C++ Casts. const_cast wird aber so gut wie nie verwendet.

Wenn du also die C++ Casts verwendest, läufst du keine Gefahr eine Konstante zu beschreiben. Von wegen keine Neuerungen, eher keine Ahnung.

Grüssli

[SpanischesDorf1]

Dravere schrieb:

#define MY_CONSTANT 200
// statt
int const MY_CONSTANT = 200;

Wer meint, dass es geschickter ist, Folgendes:

#define MY_CONSTANT 200

'kurzerhand und unter allen Umständen' durch
[code|
const int MY_CONSTANT = 200;
[/code]
zu ersetzen,

... der moege einmal versuchen, mittels ...

int main(){
float A[MY_CONSTANT] = {0.0f};
/* ... */

ein elementares statisches Array in seinem Programm zu verwenden.
Der Compiler wird die Version, in der MY_CONSTANT als const int vereinbart wurde, nicht kompilieren (Mit dem Argument, dass der Ausdruck zwischen den Klammern konstant sein muss).
Mit #define MY_CONSTANT hingegen schon.

Wir lernen daraus: echte Konstanten (die auch aus der Sicht des Kompilers Konstanten sind!) erzeugt man mittels #define.
const-Konstanten hingegen sind gar keine 'echten' Konstanten (zumindest nicht aus der Sicht des Compilers!).

mfg

[...]

Der Compiler wird die Version, in der MY_CONSTANT als const int vereinbart wurde, nicht kompilieren.

Dann hast du aber einen seltsamen Compiler. Meiner kompiliert das ohne Probleme.

...

[Janjan]

SpanischesDorf1 schrieb:

Dravere schrieb:

#define MY_CONSTANT 200
// statt
int const MY_CONSTANT = 200;

Wer meint, dass es geschickter ist, Folgendes:

#define MY_CONSTANT 200

'kurzerhand und unter allen Umständen' durch
[code|
const int MY_CONSTANT = 200;
[/code]
zu ersetzen,

... der moege einmal versuchen, mittels ...

int main(){
float A[MY_CONSTANT] = {0.0f};
/* ... */

ein elementares statisches Array in seinem Programm zu verwenden.
Der Compiler wird die Version, in der MY_CONSTANT als const int vereinbart wurde, nicht kompilieren (Mit dem Argument, dass der Ausdruck zwischen den Klammern konstant sein muss).
Mit #define MY_CONSTANT hingegen schon.

Wir lernen daraus: echte Konstanten (die auch aus der Sicht des Kompilers Konstanten sind!) erzeugt man mittels #define.
const-Konstanten hingegen sind gar keine 'echten' Konstanten (zumindest nicht aus der Sicht des Compilers!).

mfg

Wie war das nochmal, von C++ keine Ahnung aber trotzdem groß rumposaunen?

#include <iostream>
using namespace std;

int main()
{
  const int c = 20;
  char arr[c];
  cout << sizeof(arr);
}

Ausgabe:

20

Wie erwartet.

[namespace invader]

Nexus schrieb:

Bibliotheken wie wxWidgets, die nur sehr eingeschränktes C++ verwenden, ist gut anzusehen, wie sowas herauskommt.

Und wieso macht wxWidgets das? Und nicht nur wxWidgets; kaum eine größere Bibliothek macht Gebrauch von allen Möglichkeiten von C++. Natürlich kann man argumentieren, dass die Bibliotheken schon älter sind, aber wenn es stimmt, dass "C mit Klassen" so eine Krankheit ist und alles so viel besser wird, wenn man Exceptions bloß keine Macros und Zeiger usw. verwendet, sollte ja wohl nichts dagegen sprechen, das beim nächsten größeren Versionssprung zu ändern (AFAIK gab es solche Versuche bei wxWidgets und FLTK auch, die aber mehr oder weniger gescheitert sind).

"C mit Klassen" ist einfach alles, was man wirklich braucht. Die Leute benutzen C++, weil sie Klassen brauchen und die in C etwas mühsam nachzubauen sind. Ein paar Sachen wie Templates sind vielleicht noch nützlich, wenn man vorsichtig ist, aber alles darüber hinaus ist eher was für Esoteriker und bringt nicht wirklich was, sondern sorgt nur für neue Probleme und macht alles unnötig kompliziert. C++ verdankt seine Popularität dem Hype zu einer Zeit, in der C++ wirklich weitestgehend als "C mit Klassen" betrachtet wurde. Es wäre für alle Beteiligten das beste gewesen, wenn C++ dabei belassen worden und so wie bei C nur ein paar Detailverbesserungen gemacht worden wären. Wenn Bjarne Stroustrup in den 80ern mit dem C++ so wie es heute ist angekommen wäre, hätten alle einen großen Bogen darum gemacht und lieber Objective C benutzt.

[Jockelx]

... schrieb:

Der Compiler wird die Version, in der MY_CONSTANT als const int vereinbart wurde, nicht kompilieren.

Dann hast du aber einen seltsamen Compiler. Meiner kompiliert das ohne Probleme.

Er wollte wohl auf den sog. 'Enum-Hack' hinweisen, der ja tatsächlich wohl häufig angewendet wird (oder wurde?) und C++ (bzw. die Compilerhersteller) auch wirklich nicht gut aussehen lässt.

[Tachyon]

namespace invader schrieb:

[...]

Wie wäre es, wenn Du einfach mal Fakten zu Deinen Aussagen aufführst? Du argumentierst ja nichteinmal richtig. Du schreibst einfach nur Deine persönliche Meinung hin. Hilfreich für den Fragensteller ist das ganz gewiss nicht.

Die einzige Quelle die Du angeführt hast ist die zu "Defective C++". Eine Quelle die sich ausschließlich selbst referenziert. Was man von Quellen die sich selbst referenzieren zu halten hat, sollte jedem, der einmal eine wissenschaftliche Arbeit geschrieben hat, wohl klar sein.

[Shade Of Mine]

namespace invader schrieb:

Und wieso macht wxWidgets das? Und nicht nur wxWidgets;

Weil sie zu alt sind um es besser zu wissen.

"C mit Klassen" ist einfach alles, was man wirklich braucht. Die Leute benutzen C++, weil sie Klassen brauchen und die in C etwas mühsam nachzubauen sind.

Schau dir Code von Heute an und von vor 15 Jahren.
C++ hat sich weiterentwickelt, einige Entwickler dagegen nicht.
channel9 bietet ab und zu einblick hinter die kulissen bei microsoft. da sieht man zB was sich so tut.

leider sind viele entwickler auf dem niveau von 1998 geblieben. In C++ hat man in den letzten Jahren eben an der Sprache gebaut - das ist zB einer der Gründe warum die C++ Library so mager ist.

Alleine deine Kritikpunkte sind doch ein super Beispiel warum C mit Klassen eben keine gute Idee ist. Denn deine Kritikpunkte gelten ja nur für C mit Klassen aber nicht für richtiges C++.

Das ist diese doppel Moral die du nicht einsehen willst

[namespace invader]

... schrieb:

Dann hast du aber einen seltsamen Compiler. Meiner kompiliert das ohne Probleme.

Das hier kompiliert mein Compiler nicht:

template<typename T> 
T max(T const& lhs, T const& rhs) 
{ 
  return lhs > rhs ? lhs : rhs; 
}

int const MY_CONSTANT = max(10, 20); 

int a[MY_CONSTANT];

Ist er kaputt?

[Shade Of Mine]

namespace invader schrieb:

Ist er kaputt?

geht mit enum ja auch nicht.
wenn max kein konstanter ausdruck ist, kann die davon abhängige konstate nicht konstant sein.

einfacht constexpr verwenden und gut ist. oder eben nicht max sondern einen konstanten ausdruck verwenden.

willst du echt auf so ein niveau hinaus...?

[Tachyon]

Shade Of Mine schrieb:

willst du echt auf so ein niveau hinaus...?

Die Frage ist inzwischen ziemlich redundant.

[otze]

Jockelx schrieb:

Er wollte wohl auf den sog. 'Enum-Hack' hinweisen, der ja tatsächlich wohl häufig angewendet wird (oder wurde?) und C++ (bzw. die Compilerhersteller) auch wirklich nicht gut aussehen lässt.

Das ist eine andere Baustelle. Den Enumhack brauchst du für statische Konstanten innerhalb einer Klasse. "const int bla" ist nicht wirklich eine Konstante innerhalb einer Klasse, weil jede Instanz sie selbst im Konstruktor nach gusto initialisieren kann. Man braucht also static damit die Variable zwischend en Instanzen geteilt wird. Aber normale "static"-Variablen sind nicht Compilezeitkonstant sondern belegen *irgendwoanders* Speicherplatz. Dieses Verhalten als Compilezeit-Konstante die keinen eigenen Speicherplatz belegt gilt also nur in Verbindung mit const als "static const int bla" und das wurde von einigen Compilern nicht unterstützt weil es lange Zeit nur als esoterischer Randfall angesehen wurde, bis die Leute das auf einmal _wirklich_ verwendet haben.

"const int bla" im globalen Namensraum war schon immer compilezeit-konstant weil es eben auch als Ersatz für die defines vorgesehen war. Dies haben die meisten Compiler also schon recht früh gekonnt.

@namespace invader
Das beispiel hinkt, weil maxkein compilezeit-konstanter Ausdruck ist. In dem Fall kann der Compiler zur Compielezeit nicht herauskriegen welchen Wert die Variable haben soll und kann sie deswegen nicht als compilezeit-konstant klassifizieren. Das wäre dir aber auch sicherlich selbst aufgefallen wenn du nicht hättest trollen wollen

[Jockelx]

@Otze: Okay, danke für die Erklärung.
Ich hab's auch selber noch nie benötigt, sondern hatte es nur im Hinterkopf, da ich dann -falls ich mal komische Kompilermeldungen diesbzgl. kriege- ich weiss, wonach ich googeln muss

[krümelkacker]

veritySeeker schrieb:

Wegcastbarkeit von "const" ist sehr wohl ein Argument (C++ unterstützt dies sogar noch durch den eigens dafür geschaffenen const_cast<...>). Ich ziehe es vor, wenn mir ein Compiler sagt, daß ich Mist baue, anstatt mich stillschweigend mit undefiniertem Verhalten zu bestrafen.

Was ist denn an der Nutzung von const_cast "stillschweigend"? Warum sollte man const_cast überhaupt auf Konstanten anwenden wollen? Die Zahl der const_cast s sollten auch bei einem größeren Projekt in der Nähe von 0 liegen. Hauptsächlich ist es dazu dar, Funktionen aufrufen zu können, von denen man genau weiß, dass sie Daten nicht verändern, aber deren Author es nicht für nötig gehalten hat, const zu benutzen, und man keine Möglichkeit hat, die Schnittstellen zu ändern. Das ist extrem unschön, ja. Aber in solchen Fällen geht es nicht anders. Da ist mir ein const_cast aber lieber als ein C-style Cast; denn dem C-style cast sieht man das nicht so leicht an, was der eigentlich genau macht.

veritySeeker schrieb:

Und ein #define ... Literal, oder enum, wirst Du mit allen Casts der Welt nicht beschreibbar machen können.

Ich finde das Argument nicht besonders überzeugend. Das ist für mich kein Grund, die Finger von "konstanten Variablen" zu lassen. Ich kann mir keinen Fall vorstellen, in dem man versehentlich ein const_cast auf eine Konstante anwendet und anschließend den Wert zu ändern versucht.

veritySeeker schrieb:

Wie wir sehen, hat C++ gegenüber C in puncto Konstanten keine sinnvolle Neuerung gebracht, eher im Gegenteil: C++ hat, wie so oft, ein nichtvorhandenes Problem adressiert und damit eine zusätzliche Fehlermöglichkeit eingeführt, ohne auch nur das Geringste zu verbessern.

Das Problem, was addressiert wurde, war: "Makros sind unschön". Für #include, #if und co sind Makros geblieben. Für Konstanten und inline-Funktionen braucht man sie jetzt nicht mehr. Bei Konstanten ist es relativ egal, was Du benutzt. Inline-Funktionen gefallen mir aber besser als "Funktions-Makros". Gut, inline gibt's in C99 auch. Aber ich meine mich zu erinnern, dass das inline relativ restriktiv in C99 was die ODR (one defnition rule) und Linkage angeht.

btw: Ich fand "The Design and Evolution of C++" erhellend. Das Buch beschreibt, warum die Sprache so ist, wie sie ist. Auch nachdem ich das durch hatte, war ich keineswegs von C++ enttäuscht.