Using C++ in GCC is OK

zwutz

http://gcc.gnu.org/ml/gcc/2010-05/msg00705.html

das wird lustig

SeppJ

Die scheinen sich ja sehr genaue Gedanken über den Umstieg zu machen, ich glaube nicht, dass das im Chaos endet. Und die Leute scheinen sehr vernünftig zu diskutieren. Der verlinkte Thread hat sogar schon ziemlich viele Beiträge ohne in einen Flamewar zu enden, das wäre hier nie möglich gewesen bei dem Thema.

Hatte ich ja schon angedeutet, das da was "seltsames" im Header abgeleitet wurde -
hatte mich nur gewundert - wird also schon begonnen mit dem Umsetzen.

Dabei ist es mir aufgefallen:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-267613-and-start-is-10.html

rüdiger

Einer der GCC-Devs hat das ja schon mal vorgeschlagen:
http://www.airs.com/ian/cxx-slides.pdf

Was ich nicht verstehe, dass die Templates nicht erlauben wollen. Das ist eines der Features was ich am meisten vermisse, wenn ich in C entwickeln muss.

Hier der Abschnitt eines 4er gcc aus dem Header stdbool.h

/** @file tr1/stdbool.h
 *  This is a TR1 C++ Library header. 
 */

#ifndef _TR1_STDBOOL_H
#define _TR1_STDBOOL_H 1

#include <tr1/cstdbool>

#endif

keine Ahnung ob es da schon mehr gibt.

MfG f.-th.

abc.w

rüdiger schrieb:

Einer der GCC-Devs hat das ja schon mal vorgeschlagen:
http://www.airs.com/ian/cxx-slides.pdf

Das nenne ich ein Argument:

Why not C++?
The FSF doesn't like it!
-> The FSF is not writing the code.

Nexus

C++ ohne Templates, Exceptions und Mehrfachvererbung? Das kommt dem "C mit Klassen" schon bedenklich nahe.

Ich verstehe nicht ganz, weshalb man als Programmierer nicht bei C bleibt oder gleich richtiges C++ (mit g++) nutzt. Warum so eine Mischung? Wenn man in C entwickelt, hat man doch meistens einen Grund, weshalb man auf C++ verzichtet, und der wird auf das halbe C++ mit gcc wahrscheinlich auch zutreffen.

habe da rausgelesen, dass es denen vor allem auch darum geht, die C-programmierer nicht zu überfordern.

man müsste also eine grenze ziehen zw. einfachen c++ templates und solchem hardcore geplempel wie boost.

Janjan

Al Koholik schrieb:

habe da rausgelesen, dass es denen vor allem auch darum geht, die C-programmierer nicht zu überfordern.

Wie niedlich. Bloß nicht die ganzen verkalkten Steinzeit-Programmierer überfordern.

Komme die Sprache hatte auch mal ihre Berechtigung und wo es keine C++ Compiler für gibt muss man halt wie die Leute von früher programmieren, dafür können die ja nix. Das OOP z.B. mit Containern auch meist schneller ist als die uralten Arrays mit Zeiger raffen die wenigsten und die sollen bitte dann auch dabei bleiben

DrGreenthumb

ich glaube nicht, dass die gcc-entwickler verkalkte steinzeitprogrammierer sind.

Hand aufs Herz, freiwillig tut sich C doch niemand mehr an es sei denn er muss.

- C ist nicht performanter als C++
- C unterstützt kein OOP, Templates
- Es ist leider sehr einfach schwere Fehler zu entwickeln
- und, und, und

Es ist also keine logische Entscheidung C zu nutzen wenn C++ verfügbar ist, sondern eine rein persönlich emotionale.

Ich versteh das nicht. Auf der einen Seite ist das Gejammer groß wenn es mal jemand wagt C mit C++ zu mischen und auf der anderen Seite entscheidet man sich zu so einem Schritt.

@naich : Zu behaupten Arrays wären langsamer als OOP-Container zeugt nicht gerade von fachlicher Kompetenz.
Auch halte ich das Argument von dir, dass man in C leichter schwere Fehler macht für unsinnig. Das hängt vom Programmdesign ab.

Mr X

Aber es ist in C++ nicht verboten, C-Arrays zu nutzen. Also ist C nicht schneller als C++, da C++ in keinem Bereich weniger Features (Und Performance sei nun ein Feature) als C hat.

In C++ macht man weniger Fehler, wenn man z.B. std::string statt char* nutzt. Dafür verliert man evtl. etwas performance.

player4245 schrieb:

Ich versteh das nicht. Auf der einen Seite ist das Gejammer groß wenn es mal jemand wagt C mit C++ zu mischen und auf der anderen Seite entscheidet man sich zu so einem Schritt.

@naich : Zu behaupten Arrays wären langsamer als OOP-Container zeugt nicht gerade von fachlicher Kompetenz.
Auch halte ich das Argument von dir, dass man in C leichter schwere Fehler macht für unsinnig. Das hängt vom Programmdesign ab.

Du Honk, ich rede von dynamischen C-Arrays vs. vector von C++. Statische Arrays sind ja wohl die reinste Platzverschwendung und somit Resourcenverschwendung, zumal man sie wenn man es denn brauch in C++ auch einsetzen kann. Beim Vergleich C zu C++ kannst du leider nicht mit reiner Geschwindigkeit punkten.

Dravere

Nexus schrieb:

C++ ohne Templates, Exceptions und Mehrfachvererbung? Das kommt dem "C mit Klassen" schon bedenklich nahe.

Naja, über die Mehrfachvererbung und auch Exceptions könnte man vielleicht noch streiten. Wobei ich mich schon ein wenig frage, was denn so schwer an den Exceptions sein soll.
Bei den Templates fürchte ich fast, dass da ein Missverständnis vorliegt. Wahrscheinlich wollen sie keine grossen Templatemetaprogrammierungs-Tricks. Die Container aus der Standardbibliothek möchten sie schliesslich zulassen, also wieso auch nicht Templates für eigene Container zulassen?

Nexus schrieb:

Ich verstehe nicht ganz, weshalb man als Programmierer nicht bei C bleibt oder gleich richtiges C++ (mit g++) nutzt. Warum so eine Mischung? Wenn man in C entwickelt, hat man doch meistens einen Grund, weshalb man auf C++ verzichtet, und der wird auf das halbe C++ mit gcc wahrscheinlich auch zutreffen.

Stimme ich dir zu. Vor allem verstehe ich auch nicht, wieso man die C Programmierer C++ programmieren lassen möchte. Als wenn man die Lokführer dazu bewegt ein Flugzeug zu fliegen. Wo ist da der Sinn?

Grüssli

Dravere schrieb:

Nexus schrieb:

C++ ohne Templates, Exceptions und Mehrfachvererbung? Das kommt dem "C mit Klassen" schon bedenklich nahe.

Naja, über die Mehrfachvererbung und auch Exceptions könnte man vielleicht noch streiten. Wobei ich mich schon ein wenig frage, was denn so schwer an den Exceptions sein soll.
Bei den Templates fürchte ich fast, dass da ein Missverständnis vorliegt. Wahrscheinlich wollen sie keine grossen Templatemetaprogrammierungs-Tricks. Die Container aus der Standardbibliothek möchten sie schliesslich zulassen, also wieso auch nicht Templates für eigene Container zulassen?

Eigene templates sind nicht erlaubt, STL in vollem Umfang dagegen schon.
Die eigentlichen Guidelines werden AFAIK aber noch ausgearbeitet.

trojalinde schrieb:

player4245 schrieb:

Ich versteh das nicht. Auf der einen Seite ist das Gejammer groß wenn es mal jemand wagt C mit C++ zu mischen und auf der anderen Seite entscheidet man sich zu so einem Schritt.

@naich : Zu behaupten Arrays wären langsamer als OOP-Container zeugt nicht gerade von fachlicher Kompetenz.
Auch halte ich das Argument von dir, dass man in C leichter schwere Fehler macht für unsinnig. Das hängt vom Programmdesign ab.

Du Honk, ich rede von dynamischen C-Arrays vs. vector von C++. Statische Arrays sind ja wohl die reinste Platzverschwendung und somit Resourcenverschwendung, zumal man sie wenn man es denn brauch in C++ auch einsetzen kann. Beim Vergleich C zu C++ kannst du leider nicht mit reiner Geschwindigkeit punkten.

Mal ganz davon abgesehen, dass dich schon plumpe Beleidigungen aus einer fachlichen Disskusion disqualifizieren, ist ein dynamisch in C angelegtes Array trotzdem schneller.
Es kommt natürlich auch darauf an was man vor hat.
Aber du kannst mir gerne Messwerte präsentieren die deine Aussagen belegen. Ich glaube allerdings nicht das man von einem C-Bashing-Troll so etwas (unparteiisch) verlangen kann.

Zu deinem restlichen Beitrag kann ich nur folgendes sagen:

try
{
Statische Arrays sind ja wohl die reinste Platzverschwendung und somit
Resourcenverschwendung, zumal man sie wenn man es denn brauch in C++ auch einsetzen kann. Beim Vergleich C zu C++ kannst du leider nicht mit reiner Geschwindigkeit punkten.
}
catch (NullArgumentException e)
{
  e.printStackTrace();
}

C-Array und std::vector sind gleich schnell. Der Vector ist dabei aber nicht so fehleranfällig. Klarer Sieger Vector in Sachen Komfort und da er im Speed dem CArray in nix nachsteht stellt sich die Frage nicht was man einsetzen sollte.

Hier ist ein Vergleich des erzeugten Assemblercodes wo man sieht das die Zugriffe gleich schnell sind.

// Assembly code was generated by gcc 4.1.0 invoked with  g++ -O3 -S  on a x86_64-suse-linux machine.

#include <vector>

struct S
{
  int padding;

  std::vector<int> v;
  int * p;
  std::vector<int>::iterator i;
};

int pointer_index (S & s) { return s.p[3]; }
  // movq    32(%rdi), %rax
  // movl    12(%rax), %eax
  // ret

int vector_index (S & s) { return s.v[3]; }
  // movq    8(%rdi), %rax
  // movl    12(%rax), %eax
  // ret

// Conclusion: Indexing a vector is the same damn thing as indexing a pointer.

int pointer_deref (S & s) { return *s.p; }
  // movq    32(%rdi), %rax
  // movl    (%rax), %eax
  // ret

int iterator_deref (S & s) { return *s.i; }
  // movq    40(%rdi), %rax
  // movl    (%rax), %eax
  // ret

// Conclusion: Dereferencing a vector iterator is the same damn thing as dereferencing a pointer.

void pointer_increment (S & s) { ++s.p; }
  // addq    $4, 32(%rdi)
  // ret

void iterator_increment (S & s) { ++s.i; }
  // addq    $4, 40(%rdi)
  // ret

// Conclusion: Incrementing a vector iterator is the same damn thing as incrementing a pointer.

@player4245: Schade da habe ich wohl nicht ganz recht gehabt, du scheinst aber auch nicht gerade der Überflieger in Sachen C zu sein wenn du nicht weisst das carray und vector gleich schnell sind. Also bis dann Honky Monky und nicht ärgern wenn andere mehr wissen, so ist das nunmal im Leben Kleiner.