3. C schneller als C++ ?

C schneller als C++ ?

  • R

    C++ gibt dem Programmierer viele Freiheiten und dazu das OOP-Modell, in C hat man diese Freiheiten nicht und auhc kein OOP-Modell.

    OOP hat ja nichts mit der Sprache zu tun, die man nutzt.

    Hier ist zB. ein kleines OO Program in ISO C

    //coop.h
#define class struct

#include <stddef.h>
#include <stdarg.h>

void *new(const void *class_,...);
void *copy(const void *class_,const void *obj);
void delete(void *class_);

typedef void (*ctor_t)(void*,va_list);
typedef void (*dtor_t)(void*);
typedef void (*cctor_t)(void*,const void*);

class object {
  size_t size;
  ctor_t ctor;
  dtor_t dtor;
  cctor_t cctor;
};

//coop.c

#include <string.h>
#include <stdlib.h>
#include "coop.h"

void *new(const void *class_,...) {
  const class object *class_m=(const class object *)class_;
  void *data=calloc(1,(class_m->size));
  if(!data)
    return NULL;
  if(class_m->ctor) {
    va_list ap;
    va_start(ap,class_);
    class_m->ctor(data,ap);
    va_end(ap);
  }
  return data;
}

void delete(void *class_) {
  class object *class_m=(class object *)class_;
  class_m->dtor(class_);
  free(class_m);
}

void *copy(const void *class_,const void *obj) {
  const class object *class_m=(const class object *)class_;
  void *data=calloc(1,(class_m->size));
  if(class_m->cctor)
    class_m->cctor(data,obj);
  else //Holzhammer Methode
    memcpy(data,obj,class_m->size);
  return data;
}

//coop.class.h
#include "coop.h"

class private_foo_impl;

class foo_ {
  size_t size;
  ctor_t ctor;
  dtor_t dtor;
  cctor_t cctor;

  int (*get)(const void*);
  void (*set)(void*,int i);
  class private_foo_impl *impl;
};

extern class foo_ foo;

//coop.class.c

#include "coop.class.h"
#include <stdlib.h>

class private_foo_impl {
  int i;
};

static int get(const void *data) {
  return ((const class foo_*)data)->impl->i;
}

static void set(void *data,int i) {
  ((const class foo_*)data)->impl->i=i;
}

static void ctor(void *data_,va_list a) {
  class foo_ *data=(class foo_ *)data_;
  data->impl=malloc(sizeof(class private_foo_impl));
  if(!data->impl) //in realit�t braucht man nat�rlich eine besser Fehlerbehandlung!
    return;
  data->impl->i=va_arg(a,int);

  data->get=get;
  data->set=set;
}

static void dtor(void *data) {
  free(((class foo_*)data)->impl);
}

static void cctor(void *data_,const void *obj) {
  class foo_ *data=(class foo_ *)data_;
  data->impl=malloc(sizeof(class private_foo_impl));
  data->impl->i=((const class foo_*)obj)->impl->i;
}

class foo_ foo={sizeof(class foo_),ctor,dtor,cctor,get,set,NULL};

//coop.main.c
#include "coop.class.h"
#include <stdio.h>

int main(void) {
  class foo_ *f=new(&foo,0);
  printf("%d\n",f->get(f));
  f->set(f,2);
  printf("%d\n",f->get(f));
  return 0;
}

    [ Dieser Beitrag wurde am 24.05.2003 um 12:24 Uhr von kingruedi editiert. ]

    0
  • T

    Es ist doch wohl klar, dass ich meinte, dass C++ die OOP-Sprachstrukturen gibt 🙄 nitpicker 😉

    Original erstellt von volkard:
    **naja, einen kleinen unterschied soll es noch geben. MrN muß netter sein. wenn ich so ne oberscheiße lese wie
    "C ist direkter, in C gibt es viele strenge Konventionen die einem mehr Kontrolle über das Geschehen lassen. C++ gibt dem Programmierer viele Freiheiten und dazu das OOP-Modell, in C hat man diese Freiheiten nicht und auhc kein OOP-Modell"
    , dann beschimpfe ich den autor (ja, autor schreibt man ohne h) erstmal als inkopententen depp (ohne -en, damit ihr es besser verstehen tut). und dann erst sage ich, er solle meine postings in diesem thread erstmal lesen. das darf MrN noch nicht, aber ich habe gute lust, ihn zu meinem hofbeleidiger zu ernennen.
    bitte wendet zu euren gunsten diese, der härtsesten, maßnahme ab, indem ihr MrNs und meine postings lest, bevot ihr mist antwortet.
    **

    Interessant, die einzigen beiden Kontakte die ich mit dir hatte, waren als du mich jeweils als Depp bezeichnest und meinst ich rede oberscheiße 🙄 Ich warte auf de groben fehler. C++ hat mehr Freiheiten, die in C dann mit C99 teilweise auch dazukamen (z.B. freie Variablendeklaration nicht zwingend am Anfang). Außerdem führt man mit Konstruktoren udn vor allem Destruktoren nunmal "versteckten" Code ein. Und erzähl mir nicht, die Sprache C hat direkt ein OOP-Modell, natürlich kann man OOP mit C nachbilden, aber das kann ich mit Assembelr auch. Trotzdem hat Assembelr kein OOP-Sprachmodell.

    0
  • R

    Original erstellt von TriPhoenix:
    Es ist doch wohl klar, dass ich meinte, dass C++ die OOP-Sprachstrukturen gibt 🙄 nitpicker 😉

    hmm, war mir nicht klar, aber jetzt wo du es sagt.

    0
  • T

    Wie gesagt, OOP kannst du in quasi jeder Sprache nachbilden. Das ist ja keine Besonderheit von C++, dass man damit überhuapt OOP machen kann. Nur die Konstrukte, die gibts erst in C++.

    0
  • T

    Ansonsten: bevor mich jemand zum dritten mal falsch versteht 🙄

    IMHO sind alle Sprachen gleich unsicher, sofern man nicht korrekt damit umgeht. Das gilt gleichermaßen für C und C++. Nur imho sind die Fehler, die man machen kann in C meistens sichtbarer, wenngelich man da auch fatalere machen kann, während in C++ sich ab und zu was verstecken kann. Für mich persönlich sind mehr sichtbare Fehler "sicherer" als weniger aber dafür versteckte.

    0
  • W

    Original erstellt von TriPhoenix:
    IMHO sind alle Sprachen gleich unsicher, sofern man nicht korrekt damit umgeht.

    Wie wahr! 😉

    0
  • S

    Die Sprache ist ja auch nur das Werkzeug. Eigentlich könnte man sich die Diskussionen über Sprachen sparen, denn sie sind nur Werkzeuge.

    Als ich früher am Bau gearbeitet hab, und mir wieder wer den Hammer verzogen hat, hab ich Nägel auch mim Stein in die Wand gehauen. Es hat auch funktioniert 😉

    Das einzig wichtige ist der der Hinter der Maschine sitzt. Wenn der Ahnung hat, kann er auch aus Pascal oder *würg* Basic oder anderen Sprachen ne Menge rausholen.

    Ach ja - C++ hat mit den Versteckten Sachen schon so seine Macken. Kann mich noch erinnern, warum ich dauernd Fehler bekommen habe, weil der Konstruktor nicht aufgerufen wurde.

    Der Code hierfür war einfach nur

    Irgendwas< unsigned int > eps[10]

    Wenn man da nicht mitloggt, kann einem das zum Wahnsinn Treiben, vorallem wenn es ein Compiler richtig behandelt, und der andere nicht

    0
  • J

    Original erstellt von Daniel E.:
    Klar. C ist für die Probleme von C++ schuld und die einzig ernstzunehmenden Fehlerquellen sind C-Konstrukte in C++-Quellen. Ersetzt man diese durch entsprechende C++-Konstrukte, so erhält man lauter perfekte Programme.

    ... blödsinn und das wiesst du auch. Keine SPrache schützt vor dummen Programmierern Das Probelm bei C-Programmierern die nen C++-Compiler haben ist schlicht das völlig andere Denken das durch C eingeimpft wurde.

    -junix

    0
  • M

    @volkard: Irgendwie ist mir nie bewusst, wenn ich Leute indirekt als inkompetent bezeichne... Gut, dass du mich darauf aufmerksam machst.

    @Helium: Ich zumindest verlange von dir auf keinen Fall den Respekt, den du volkard entgegenbringst. Das will ich nichtmal. Volkard hat von dir ja auch nur verlangt, mir zu glauben. (Oder habe ich mich verlesen?)

    0
  • H

    natürlich kann man OOP mit C nachbilden, aber das kann ich mit Assembelr auch

    OK, dann hätte ich ein möglichst kurzes Beispiel in Assembler bitte.

    @Mr.N: Ich glaube dir schon, da ich der selben Ansicht bin.

    0
  • D

    Original erstellt von junix:
    Das Probelm bei C-Programmierern die nen C++-Compiler haben ist schlicht das völlig andere Denken das durch C eingeimpft wurde.

    Du hast mich nicht verstanden. C++-Programme enthalten mehr Fehler als C-Programme, von Leuten die X Jahre die Sprache kennen, und das ist unabhängig davon, ob ein Programmierer vorher C, Ada, Scheme oder Spanisch gelernt hat weil es so schwer durchschaubar ist und viel Erfahrung sowie ein gutes Händchen im Raten benötigt. Das wurde hier schon mehrfach gesagt.

    Original erstellt von TriPhoenix:
    IMHO sind alle Sprachen gleich unsicher, sofern man nicht korrekt damit umgeht.

    Man kann es einem Programmierer schwerer machen inkorrekt mit der Sprache umzugehen. Das macht dem Programmierer meistens aber keinen Spaß, darum programmiert auch kaum jemand in Spark.

    0
  • V

    Ansonsten: bevor mich jemand zum dritten mal falsch versteht 🙄

    ich versuche mal, da was draus zu lesen.

    Nur imho sind die Fehler, die man machen kann in C meistens sichtbarer, wenngelich man da auch fatalere machen kann, während in C++ sich ab und zu was verstecken kann. Für mich persönlich sind mehr sichtbare Fehler "sicherer" als weniger aber dafür versteckte.

    aha. also darf ich dein argument dochj übertragen von c nach basic oder gar asm.
    die komplizierten konstrukte wie

    do
 befehl
while(bedingung);

    verbergen ja in wirklichkeit ein schlichtes

    marke:
befehl
if(bedingung) goto marke;

    natürlich ist unteres viel klarer. nicht zuletzt, weil mit if-goto außer do auch die verwirrenden sprachmittel wile, for, else und switch unnötig werden.
    und wer mag behaupten, er habe sich nicht schon mal bei schleifen vertan? schleifen sind einfach gefährlich und kompliziert. und wenn noch switch und continue vorkommen! continue springt in der forschleife aufs semikolon zwischen der laufbedingung und dem weiterschaltungsausdruck! wie verwirrend!

    die fehler sind in asm oder besser basicv2 einfach "sichtbarer".

    und jetzt nochmal deinen satz:

    Für mich persönlich sind mehr sichtbare Fehler "sicherer" als weniger aber dafür versteckte.

    und ich kann deine meinung einfach nicht so ganz nachvollziehen.

    übrigens verlagern sich die fehler mit der zeit.
    anfangs ist ne falsche laufbedingung ein interessanter fehler. über tippfehler redet man nicht, die passieren immer mal und sind in null komma nix weg.
    später ist ne schlechte funktionale zerlegung ein fehler, der es einem unmöglich macht, die gewünschte komplexität aufzubauen. über falsche laufbedingungen redet man nicht mehr. die passieren immer mal und sind in null komma nix weg.
    so mag es sein, daß man auch mal ne zeit hat, wo man in c keine schlimmen fehler machen würde, aber in c++ viele. das vergeht aber. wenn man vorwiegend über die design-fehler nachdenkt, die einem erst in drei monaten das knie brechen, dann ist meines erachtes nach c++ eine der ungefährlichsten sprachen (man strirbt nämlich bereits nach 2 monaten und hat nen monat gespart).

    0
  • V

    C++-Programme enthalten mehr Fehler als C-Programme, von Leuten die X Jahre die Sprache kennen, und das ist unabhängig davon, ob ein Programmierer

    das halte ich für quatsch.
    fertige c++-programme sind wesentlich wesentlich fehlerfreuer, nicht zuletzt weils typsicherheit mit templates und einfache fehlerbehandlung mit exceptions gibt.

    0
  • T

    Original erstellt von volkard:
    aha. also darf ich dein argument dochj übertragen von c nach basic oder gar asm.
    die komplizierten konstrukte wie

    do
 befehl
while(bedingung);

    verbergen ja in wirklichkeit ein schlichtes

    marke:
befehl
if(bedingung) goto marke;

    natürlich ist unteres viel klarer. nicht zuletzt, weil mit if-goto außer do auch die verwirrenden sprachmittel wile, for, else und switch unnötig werden.
    und wer mag behaupten, er habe sich nicht schon mal bei schleifen vertan? schleifen sind einfach gefährlich und kompliziert. und wenn noch switch und continue vorkommen! continue springt in der forschleife aufs semikolon zwischen der laufbedingung und dem weiterschaltungsausdruck! wie verwirrend!

    nein, so kann man das nicht ansehen. Was ich meine sind dinge wie z.B. Implizite Destruktorenaufrufe. Sowas ist versteckt, denn sie haben kein Äquivalent im Programmtext ( } zählt hier nun wirklich nicht). Destruktoren sind definitiv eine praktische Sache, man muss sich nur seines Schrittes bewusst sein und an solche Sachen denken. Eine Übersetzung von deinem C-Beispiel in Basic oder Assembler ändert nur die Schreibweise der Instruktionen, da ist nichst dran versteckt.

    übrigens verlagern sich die fehler mit der zeit.
    anfangs ist ne falsche laufbedingung ein interessanter fehler. über tippfehler redet man nicht, die passieren immer mal und sind in null komma nix weg.
    später ist ne schlechte funktionale zerlegung ein fehler, der es einem unmöglich macht, die gewünschte komplexität aufzubauen. über falsche laufbedingungen redet man nicht mehr. die passieren immer mal und sind in null komma nix weg.
    so mag es sein, daß man auch mal ne zeit hat, wo man in c keine schlimmen fehler machen würde, aber in c++ viele. das vergeht aber. wenn man vorwiegend über die design-fehler nachdenkt, die einem erst in drei monaten das knie brechen, dann ist meines erachtes nach c++ eine der ungefährlichsten sprachen (man strirbt nämlich bereits nach 2 monaten und hat nen monat gespart).

    Hm, da istd ie Frage ob Designfehler noch mit Sicherheit zu tun haben. Denn Designfehler sieht man wenigstens, meistens rennt man früher oder später mitm Kopf dagegen 🙂
    Aber Anyway, ich denke man kann sowohl in C, als auch in C++ genauso gut "versteckte" Designfehler aufbauen. Ich programmiere zwar größeres in Java aber man nutzt in beiden (Java/C++) ja mehr oder weniger das OOP-Prinzip und man kann genauso gut in OOP einen Designfehler machen. Den schleppt man dann genauso wie einen C-Designfehler durch und durch und biegt immer mehr hier und da zurecht bis es ienfach nicht mehr geht. Aber ich denke das macht in C keinen Unterschied, solange man dort ebenso strukturiert bleibt wie in C++ (sprich: Funktionen nach Funktionalität in Dateien gruppieren z.B.). Wenn man natürlich alles kunterbunt durcheinander wirft, ists klar, aber wenn man es Strukturiert macht, sehe ich da keinen Unterschied.

    [ Dieser Beitrag wurde am 24.05.2003 um 16:28 Uhr von TriPhoenix editiert. ]

    [ Dieser Beitrag wurde am 24.05.2003 um 16:29 Uhr von TriPhoenix editiert. ]

    0
Anmelden zum Antworten