Warum lassen C/C++ Compiler soviel Müll zu?

knivil

btw, mas macht C++ eigentlich bei sizeof(cpp_klasse), werden statische members mitgezählt oder nicht?

Probiere es aus! Aber da sizeof z.B. bei Speicherreservierung gebraucht wird und statische Member nicht in Objekten gespeichert werden, ... naja du kannst sicher fortsetzen Wo aber sollte man noch sizeof in reinem C++ verwenden? Auch liefert der erste Treffer bei google die Antwort, falls Logik nicht ausreicht.

vor allem - mußte man Klassenvariablen unbedingt auch mit 'static' einleiten, wo dieses Wort ja schon in C doppelt belegt ist.

Basher_ist_nicht_BashAr

u-ser_l schrieb:

vor allem - mußte man Klassenvariablen unbedingt auch mit 'static' einleiten, wo dieses Wort ja schon in C doppelt belegt ist.

ja stimmt, das ist auch doof. man könnte sich doch was mit referenzen bauen, etwa so:

int staticvar = 12;

struct test
{
  int &j;

  test() : j(staticvar)
  {
    j++;
  }
};

^^ 'j' verhält sich wie eine C++ klassenvariable, obwohl kein static davor steht, d.h. diese sonderregelung mit 'static' in der klasse usw, wäre garnicht nötig gewesen.

volkard

Basher schrieb:

u-ser_l schrieb:

vor allem - mußte man Klassenvariablen unbedingt auch mit 'static' einleiten, wo dieses Wort ja schon in C doppelt belegt ist.

ja stimmt, das ist auch doof. man könnte sich doch was mit referenzen bauen, etwa so:
int staticvar = 12;

struct test
{
  int &j;

  test() : j(staticvar)
  {
    j++;
  }
};
^^ 'j' verhält sich wie eine C++ klassenvariable, obwohl kein static davor steht, d.h. diese sonderregelung mit 'static' in der klasse usw, wäre garnicht nötig gewesen.

nö.
einfacher wirds doch durch mehr worte, nicht durch weniger. wie willste denn hier begründen, daß sizeof(test)==1?
denn bei
struct test
{
int &j;

test() : j(staticvar)
{
j++;
}
test(int& nsv) : j(nsv)
{
j++;
}
};
[/code]
wird sizeof(test)==sizeof(void*) sein.

DStefan

Basher schrieb:

u-ser_l schrieb:

vor allem - mußte man Klassenvariablen unbedingt auch mit 'static' einleiten, wo dieses Wort ja schon in C doppelt belegt ist.

ja stimmt, das ist auch doof. man könnte sich doch was mit referenzen bauen, etwa so:
int staticvar = 12;

struct test
{
  int &j;

  test() : j(staticvar)
  {
    j++;
  }
};
^^ 'j' verhält sich wie eine C++ klassenvariable, obwohl kein static davor steht, d.h. diese sonderregelung mit 'static' in der klasse usw, wäre garnicht nötig gewesen.

Ach! Dann kann ich also mit deiner "statischen" Variable problemlos das Folgende schreiben?

int main() {

   std::cout << test::j << std::endl;
   return 0;
}

Geniale Idee!

Stefan.

Basher_ist_nicht_BashAr

volkard schrieb:

wie willste denn hier begründen, daß sizeof(test)==1?

kann man das überhaupt begründen, oder isses nur willkürlich so festgelegt worden?

volkard schrieb:

denn bei

struct test
{
  int &j;

  test() : j(staticvar)
  {
    j++;
  }
  test(int& nsv) : j(nsv)
  {
    j++;
  }
};

wird sizeof(test)==sizeof(void*) sein.

naja, das könnte man so begründen, dass jedes objekt, technisch gesehen, einen zeiger auf das gemeinsam genutzte klassenobjekt haben muss. aber eigentlich hatte ich erhofft, dass ein cpp-compiler die referenz wegoptimiert.

DStefan schrieb:

Ach! Dann kann ich also mit deiner "statischen" Variable problemlos das Folgende schreiben?
int main() {

   std::cout << test::j << std::endl;
   return 0;
}

hast recht, das geht so nicht. man muss ein objekt haben und dann dieses :: gegen einen punkt tauschen. aber das wäre doch nicht schlimm.

volkard

Basher schrieb:

volkard schrieb:

wie willste denn hier begründen, daß sizeof(test)==1?

kann man das überhaupt begründen, oder isses nur willkürlich so festgelegt worden?

volkard schrieb:
denn bei
struct test
{
  int &j;

  test() : j(staticvar)
  {
    j++;
  }
  test(int& nsv) : j(nsv)
  {
    j++;
  }
};
wird sizeof(test)==sizeof(void*) sein.
naja, das könnte man so begründen, dass jedes objekt, technisch gesehen, einen zeiger auf das gemeinsam genutzte klassenobjekt haben muss. aber eigentlich hatte ich erhofft, dass ein cpp-compiler die referenz wegoptimiert.

Hast Du den zweiten Konstruktor gesehen? Den, der j nicht an die gemeinsame Variable bindet.

Basher_ist_nicht_BashAr

volkard schrieb:

Hast Du den zweiten Konstruktor gesehen? Den, der j nicht an die gemeinsame Variable bindet.

ja, aber der hat doch nichts damit zu tun, dass sizeof(test) == 1 ist. mit dem konstruktor wolltest du andeuten, dass man meine methode aushebeln kann? aber das ist doch nichts ungewöhnliches für in C++, wo man schnell man unsinn produziert, wenn man sich nicht an bestimmte regeln hält.

volkard

Basher schrieb:

volkard schrieb:

Hast Du den zweiten Konstruktor gesehen? Den, der j nicht an die gemeinsame Variable bindet.

ja, aber der hat doch nichts damit zu tun, dass sizeof(test) == 1 ist.

ob 1 oder 0 ist hier egal. es geht um den unterschied zwischen 1/0 und 4. darum, daß die referenz durch den zweiten konstruktor nicht wegoptimierbar ist. darum, daß test::j dann nur überhaupt denkbar sein würde, wenn der zweite konstruktor nicht da wäre. kurzum, es wäre komplizierter als mit einem schlüsselwort, was gemeinsam benutze daten anzeigt.

mit dem konstruktor wolltest du andeuten, dass man meine methode aushebeln kann?

Nein.

aber das ist doch nichts ungewöhnliches für in C++, wo man schnell man unsinn produziert, wenn man sich nicht an bestimmte regeln hält.

Aufpassen muß man in C noch viel mehr, habe ich mir sagen lassen. Und wie man an den vielen Abstürzen und Sicherheitslücken von C-Programmen sieht, klappt es selten.

knivil

Basher schrieb:

aber das ist doch nichts ungewöhnliches für in C++, wo man schnell man unsinn produziert, wenn man sich nicht an bestimmte regeln hält.

Das ist nichts ungewoehnliches fuer die meisten Sprachen inklusive Java.

Basher_ist_nicht_BashAr

volkard schrieb:

es wäre komplizierter als mit einem schlüsselwort, was gemeinsam benutze daten anzeigt.

gut, das sehe ich ein. trotzdem finde ich das anlegen von statischen membern in C++ klassen denkbar misslungen. es wäre (für den benutzer) angenehmer, in die klassendefinition z.b. 'static int j = 12;' zu schreiben und weiter nix mehr. um den rest hat sich der compiler zu kümmern.

volkard schrieb:

Aufpassen muß man in C noch viel mehr, habe ich mir sagen lassen.

dann hat man dir quatsch erzählt. C ist schlichter als C++, daher gibt's da auch weniger mögliche fehlerquellen.

audacia

hustbaer schrieb:

audacia schrieb:

hustbaer schrieb:

warum????? schrieb:

Zeus schrieb:

Wegen der Rekursion in der Grammatik. IfStatement, WhileStatement sind Statement und hinter dem Kopf darfst du weitere Statements schreiben - recht einfach. Aber verhindert halt nicht, das schreiben vom dummen Code.

Aber warum braucht C++ Code dann soviel länger zum Compilieren als Java Code, der eigentlich viel eingeschränkter ist?

weil C++ viel komplizierter zu compilieren ist als Java.

argument dependent lookup, implizite konvertierungen, templates, overload resolution -> in kombination ist das viel arbeit für einen compiler

Das machts alles nicht aus; ein guter C++-Compiler kann durchaus die Geschwindigkeit eines Delphi-/Java-/C#-/Whatever-Compilers erreichen. Ausschlaggebend ist primär die Menge.

Wenn man kaum templates verwendet mag das zutreffen.

Die Standardbibliotheken sind prall gefüllt mit Template-Code. Du hast zwar insofern Recht, als daß sich die intensive Nutzung von Templates deutlich in den Übersetzungszeiten niederschlägt, aber selbst dann ist der Unterschied der zu übersetzenden Zeilen zwischen einem C++- und vergleichbaren Java-, C#- oder Delphi-Programmen derart deutlich (Faktor 10000?), daß der zusätzliche Aufwand für Templates auch nicht mehr viel ausmacht.

Die Zeilenzahlexplosion kann man recht gut mit PCHs in den Griff bekommen; wenn der Compiler in der Lage ist, uninstantiierte Templates zu parsen, ebenso das Template-Problem. Allerdings trifft das, glaube ich, gerade mal aufs EDG-Frontend zu (das überall sonst fehlende Two phase name lookup läßt das jedenfalls vermuten).

knivil schrieb:

Wo aber sollte man noch sizeof in reinem C++ verwenden?

Bei Variadic Templates, um die Anzahl der Argumente herauszufinden.

Basher schrieb:

trotzdem finde ich das anlegen von statischen membern in C++ klassen denkbar misslungen. es wäre (für den benutzer) angenehmer, in die klassendefinition z.b. 'static int j = 12;' zu schreiben und weiter nix mehr. um den rest hat sich der compiler zu kümmern.

War, glaube ich, für C++ 0x geplant.

DStefan

Basher schrieb:

C ist schlichter als C++, daher gibt's da auch weniger mögliche fehlerquellen.

Entschuldige, aber manchmal habe ich den Eindruck, als wenn du nicht wirklich darüber nachdenkst, was du so schreibst. Folgt aus einer "schlichteren" Programmiersprache wirklich, dass es weniger mögliche Fehlerquellen gibt, wenn man sie verwendet? Wohl kaum!

Ich habe jahrelang fast ausschließlich in C programmiert, bevor ich mich C++ zugewendet habe. Und tatsächlich hatte ich die Gelegenheit, dasselbe Projekt zuerst in C und dann in C++ zu programmieren. Das C++-Projekt hat das C-Projekt in Sachen Qualität um Längen geschlagen. Das wirft doch wohl erhebliche Zweifel am Wahrheitsgehalt deiner Aussage auf, meinst du nicht? Allein OOP und Exceptions sind Meilensteine in der Software-Entwicklung. Gerade im Hinblick auf Software-Qualität.

Mag sein, dass eine Sprache wie C++ schwerer zu erlernen ist als C. Darüber möchte ich nicht streiten. Aber "Schlichtheit" als a priori Garantie für Fehlerarmut ist einfach dummes Zeug.

Stefan.

volkard

Basher schrieb:

trotzdem finde ich das anlegen von statischen membern in C++ klassen denkbar misslungen. es wäre (für den benutzer) angenehmer, in die klassendefinition z.b. 'static int j = 12;' zu schreiben und weiter nix mehr. um den rest hat sich der compiler zu kümmern.

Das ist doch Quatsch! Mit 'static int j = 12;' wird doch nur eine Variable deklariert. Im Header, der bekanntlich von mehreren Übersetzungseinheiten inkludiert wird, wird kein Speicherplatz besorgt. Genau wie in C. Deswegen meinte ich ja, daß Du das schnell kapiertst.
Allerdings, eine Konstante, 'static int const j = 12;' in einer Klassendefinition wäre etwas ganz anderes.

Tachyon

Basher schrieb:

volkard schrieb:

Aufpassen muß man in C noch viel mehr, habe ich mir sagen lassen.

dann hat man dir quatsch erzählt. C ist schlichter als C++, daher gibt's da auch weniger mögliche fehlerquellen.

Komisch. Ada ist noch deutlich komplizierter als C++. Trotzdem macht man darin komischerweise meist weniger Fehler.

volkard

DStefan schrieb:

Aber "Schlichtheit" als a priori Garantie für Fehlerarmut ist einfach dummes Zeug.

Logisch.
Siehe Brainfuck.

"Auszug aus einem größeren Programm"
>+++[->++++<]>[-<++++>]<[-<+>]<.[-]<

DStefan

volkard schrieb:

DStefan schrieb:

Aber "Schlichtheit" als a priori Garantie für Fehlerarmut ist einfach dummes Zeug.

Logisch.
Siehe Brainfuck.
"Auszug aus einem größeren Programm"
>+++[->++++<]>[-<++++>]<[-<+>]<.[-]<

Hübsch -- Wie der Name schon sagt

volkard schrieb:

DStefan schrieb:

Aber "Schlichtheit" als a priori Garantie für Fehlerarmut ist einfach dummes Zeug.

Logisch.
Siehe Brainfuck.
"Auszug aus einem größeren Programm"
>+++[->++++<]>[-<++++>]<[-<+>]<.[-]<

Ob es Zufall ist, dass man mit der Brainfuck Syntax einen Fisch zeichnen kann?

volkard

Troll-Liebhaber schrieb:

volkard schrieb:
DStefan schrieb:

Aber "Schlichtheit" als a priori Garantie für Fehlerarmut ist einfach dummes Zeug.

Logisch.
Siehe Brainfuck.
"Auszug aus einem größeren Programm"
>+++[->++++<]>[-<++++>]<[-<+>]<.[-]<
Ob es Zufall ist, dass man mit der Brainfuck Syntax einen Fisch zeichnen kann?

Kann man mit C auch.

int O;

O++<              // <-
                  //      warum lassen compiler so einen müll zu? 
1;                // <-

Aber der Name "C++" sieht sogar schon ein wenig wie ein Fisch aus.

Basher_ist_nicht_BashAr

DStefan schrieb:

Folgt aus einer "schlichteren" Programmiersprache wirklich, dass es weniger mögliche Fehlerquellen gibt, wenn man sie verwendet? Wohl kaum!

aber ja. gerade C und C++ sind die besten beispiele dafür. weil C eine teilmenge von C++ ist, kannst du in C++ alle fehler machen, die auch in C möglich sind. umgekehrt aber nicht: du kannst in C keine C++ fehler machen.

DStefan schrieb:

Ich habe jahrelang fast ausschließlich in C programmiert, bevor ich mich C++ zugewendet habe. Und tatsächlich hatte ich die Gelegenheit, dasselbe Projekt zuerst in C und dann in C++ zu programmieren. Das C++-Projekt hat das C-Projekt in Sachen Qualität um Längen geschlagen.

dazu müssteste erstmal erzählen, was du mit qualität meinst. aber wenn dein erstes C++-projekt wirklich gleich so ein erfolg war: hut ab, du musst ein abolut programmiererisches ausnahmetalent sein.

DStefan schrieb:

Aber "Schlichtheit" als a priori Garantie für Fehlerarmut ist einfach dummes Zeug.

nö, das ist eine tatsache: wo wenig ist, kann wenig schief laufen. leider kann man mit 'wenig' auch wenig machen, deshalb muss ein guter kompromiss her.

Ada ist noch deutlich komplizierter als C++. Trotzdem macht man darin komischerweise meist weniger Fehler.

vielleicht kommt's dir nur so vor, weil du mit C++ mehr vertraut bist.