3. Infos über neuen C++-Standard? Thread Nr.2

Infos über neuen C++-Standard? Thread Nr.2

  • G

    ich würde nix implementieren ich würde nur schon vorhanden information zugänglich machen
    mir tut einfach die redundanz weh, entweder ein delete[size_t n] oder ein array_size()

    0
  • D

    ok, dann anders rum: wie ist das im moment implementiert (ein beispiel einer Implementation)?
    ok, bin schon müde, also in der nacht nicht mehr nötig! Cu!

    0
  • G
     

    void * operator new[](size_t n)
{
    void * speicher = ::operator new( n + sizeof( size_t ) );
    static_cast<size_t *>( speicher )[0] = n;
    return &static_cast<size_t *>( speicher )[1];
}

void operator delete[](void * speicher)
{
    ::operator delete( &static_cast<size_t *>( speicher )[-1], static_cast<size_t *>( speicher )[-1] );
}

size_t sizeofarray(void * array)
{
    return static_cast<size_t *>( array )[-1];
}

    bin mir aber nicht sicher ob ich das mit new und delete richtig gemacht habe

    0
  • H

    z.b. java oder c# können das auch

    C++ ist aber nicht Java oder C#. Hier gibt's Dinge wie das Zero-Cost-Principle.

    Aber warum schreibst du nicht einfach ein Proposal? Jetzt ist doch gerade die richtige Zeit dafür. Oder diskutier das ganze mit Leuten die sich wirklich damit auskennen (z.B. in comp.std.c++)

    0
  • K

    @kingruedi

    Aus der C++Builder-Hilfe

    __closure

    Mit dem Schlüsselwort __closure wird ein spezieller Zeigertyp auf eine Elementfunktion deklariert. Im Gegensatz zu einem regulären C++ Elementfunktionszeiger enthält __closure einen Objektzeiger.
    In Standard-C++ können Sie einem Basisklassenzeiger die Instanz einer abgeleiteten Klasse zuweisen. Einem Zeiger auf eine Basisklassen-Elementfunktion kann aber keine Elementfunktion einer abgeleiteten Klasse zugewiesen werden. Sehen Sie sich dazu den folgenden Programmcode an:

    class base

    {
    public:
    void func(int x);
    };

    class derived: public base

    {
    public:
    void new_func(int i);
    };

    void (base::*bptr)(int);

    bptr = &derived::new_func; // Unzulässig

    Die __closure-Spracherweiterung erlaubt dieses Vorgehen auch in C++Builder. Dabei wird ein Zeiger auf eine Elementfunktion einem Zeiger auf eine Klasseninstanz zugeordnet. Beim Aufruf der verbundenen Elementfunktion wird dann der Zeiger auf die Klasseninstanz verwendet. Eine __closure-Deklaration entspricht der Deklaration eines Funktionszeigers. Sie enthält aber vor der Definition des Bezeichners zusätzlich das Schlüsselwort __closure, z.B.:

    struct MyObject

    {
    double MemFunc(int);
    };

    double func1(MyObject *obj)

    {
    // __closure erwartet ein int-Argument und gibt ein double-Argument zurück.
    double ( __closure *myClosure )(int);

    // Closure initialisieren

    myClosure = obj -> MemFunc;

    // Die Elementfunktion aufrufen und ihr ein int-Argument übergeben.

    return myClosure(1);
    }
    **
    Obwohl in der obigen Diskussion die __closure-Spracherweiterung durch das Zuweisen von abgeleiteten Klassenmethoden demonstriert wird, können Sie beliebige Klassenmethodenzeiger zuweisen. Die __closure-Spracherweiterung ermöglicht vollständig unterschiedlichen Klassen die gemeinsame Nutzung eines Methodenzeigers.**
    Dieses Verfahren wird inC++ Builder bei Ereignissen eingesetzt.

    Sorry, die Syntax die ich oben verwendet hab, hat nicht ganz gestimmt.

    @hume
    Vielleicht hast Du ja recht, man sollte das mit Leuten diskutieren, die's verstehen - und da gehör ich echt nicht dazu - aber mein gesunder Menschenverstand sagt mir doch auch: Wenn delete[] die Größe des arrays kennt, warum kanns dann nicht ne Funktion geben, die diese Größe zurückliefert?

    [ Dieser Beitrag wurde am 20.01.2003 um 09:25 Uhr von kartoffelsack editiert. ]

    0
  • M

    Original erstellt von kingruedi:
    Marc++us:
    Typische Embedded-C++-Dialekte lassen ohnehin gleich die Masse der Stdlib weg, und in der Sprache sterben als erstes die Templates. Da gibt's sogar einen Industriestandard zu Embedded-C++, ohne Templates, demnach ohne STL. Da blutet dem ISOisten doch das Herz. http://www.research.att.com/~bs/bs_faq.html#EC++

    Äh ja, das kenne ich schon. Aber was willst Du mir damit sagen?

    😕

    Ich kenne einige Varianten davon, mir ist auch unklar wieso der Verzicht auf Namespaces und Templates (außer für die Compiler-Bauer) irgendeinen Gewinn für Embedded Systems bringt oder Programme schneller macht. Verstehen könnte ich noch eher den Verzicht auf Exceptions, sowas ist ja auf einem 8Bit-Compiler wirklich nicht nett zu implementieren. 😉

    Aber einen wirklichen EC++-Standard gibt's ohnehin nicht, da macht jeder was eigenes. Und es ist offensichtlich, daß es hier wesentlich nur um die Bequemlichkeit der Compilerbauer ging - klar, das sind oftmals kleinere Firmen, die eine Palette mit Embedded-Systemen haben und einen Compiler dafür anbieten müssen - und Knowhow für einen C++-Compiler gem. ISO-Standard auf einem japanischen 32-Bit-RISC-µController-Kern zu entwickeln ist halt bei einer Firma nicht unbedingt da, vor allem wenn deren Schwerpunkt Hardwareentwicklung und Elektronik ist.

    Aber was Du sagen wolltest verstehe ich immer noch nicht. 🙂

    0
  • G

    Original erstellt von HumeSikkins:
    Aber warum schreibst du nicht einfach ein Proposal? Jetzt ist doch gerade die richtige Zeit dafür. Oder diskutier das ganze mit Leuten die sich wirklich damit auskennen (z.B. in comp.std.c++)

    jup ich sammle noch ein oder zwei Ideen,

    mit

    std::vector<int> v;
v::iterator i = v.begin();

    werde ich wohl nicht durch kommen, weil man in c++ Instanzen die gleichen Namen wie Typen geben darf, hier könnte es auch eine v klasse geben, d.h. alter Code könnte Probleme bekommen und nur für etwas mehr Komfort werden sie das nicht ändern.

    Abwärtskompatibilität, dein größter Freund wenn es darum geht neue Leute zu gewinnen, dein größter Feind wenn es darum geht etwas Neues zu Integrieren.

    Können dir das Abwärtskompatibilität Problem nicht dadurch beseitigen das sie z.b. den gcc etwas erweitern, ihn über ihren Code jagen und der sagt ihn, ändere das wenn du zum c++0x kompatibel sein willst.

    0
  • L

    sag bescheid wenn du nen topic dort aufmachst und welche newsgroup ich würd gern mitreden

    0
  • R

    @Marc++us
    ich wollte das nur zum Thema "da blutet dem ISOisten doch das Herz" abgegebn. Besonderes wollte ich nichts damit sagen. (OT. Wenn ich einen Compiler für irgend welche Embeded Systeme schreiben würde, dann würde ich einfach ein neues GCC Backend entwerfen, dann kann ich nämlich die tollen C++ Kentnisse des GCCs nehmen und hab gleichzeitig noch zich andere Sprachen, wie C, ADA ... portiert ;))

    @Lars
    würde sagen comp.std.c++

    0
  • H

    Oder diskutier das ganze mit Leuten die sich wirklich damit auskennen (z.B. in comp.std.c++)

    Aber wartet bitte noch einen Moment. Ich hab grade keinen Newsreader drauf. Oder ich machs per google?

    in comp.std.c++ gabs auch mal ne Phase (Moment hat jemand einen Duden da? wird das so geschreiben?), in der Leute vorschläge für C++0x gepostet haben. Die meisten wurden aber zunichte gemacht. Das ist jetzt aber schon über ein Jahr her.

    0
  • G

    Original erstellt von Helium:
    in comp.std.c++ gabs auch mal ne Phase (Moment hat jemand einen Duden da? wird das so geschreiben?), in der Leute vorschläge für C++0x gepostet haben. Die meisten wurden aber zunichte gemacht. Das ist jetzt aber schon über ein Jahr her.

    ich machs per google, reicht mir vollkomen und das mit den fertig machen das ist kein Phase sondern ein zustand
    meistens ist es aber berechtigt, aber oft kommt es mir vor wie ein verein von haar spaltern und erbsen zählern

    0
  • S

    Original erstellt von Dimah:
    **mit

    std::vector<int> v;
v::iterator i = v.begin();

    werde ich wohl nicht durch kommen, weil man in c++ Instanzen die gleichen Namen wie Typen geben darf, hier könnte es auch eine v klasse geben, d.h. alter Code könnte Probleme bekommen und nur für etwas mehr Komfort werden sie das nicht ändern.
    **

    Jep, zurecht wirst du damit nicht durchkommen.
    warum soll eine klasse nicht type anbieten dürfen, zB als typedef auf T?

    typeof() ist die bessere Lösung, glaub mir.
    ausserdem liest sich
    typeof(v)::iterator
    besser als
    v::iterator

    woher soll man denn auf die schnell wissen, das v eine instanz ist und keine klasse?

    das mit dem length_of(void*) wäre aber durchaus praktisch... müsste man mal näher die pros und cons beachten...

    0
  • H

    aber oft kommt es mir vor wie ein verein von haar spaltern und erbsen zählern

    Das habe ich schon oft gehört. Meine Meinung zu diesem Vorwurf: Wenn das kein Verein von Haar spaltern und Erbsen zählern wäre (sehe ich übrigens nicht so. Eher ein Verein von Gut-Auskennern und Language-Lawyern), dann gäbe es keinen vernünftigen Standard sondern nur ein einziges riesiges Chaos wo jeder macht was er will.

    0
  • J

    Original erstellt von Shade Of Mine:
    **typeof() ist die bessere Lösung, glaub mir.
    **

    Ohja, das ist eine tolle Begründung!
    (Ein typeof fände ich aber auch gut)

    Gegen das length_of spricht in meinen Augen folgendes:

    Angenommen, ich hole mir ein 27 Bytes großes Array. Dann könnte dem Compiler (dem ich gesagt hab optimier bitte auf speed) auf die Idee kommen vielleicht 32 Byte zu reservieren. Das heißt, die Größe, die delete kennt stimmt nicht mit der tatsächlichen Array-Größe überein. Ähnlich wäre es bei Klassen,wenn Alignment-Bytes eingefügt werden. Also müßte man die Länge noch mit abspeichern.
    Der Verwaltungsaufwand steigt also. Wie war das nochmal mit dem Zero-Cost-Principle?

    MfG Jester

    0
  • H

    Wie war das nochmal mit dem Zero-Cost-Principle?

    In einem Satz?

    You don't have to pay for what you don't use.

    0
  • G

    ich ziehe meine length_of antrag zurück 🙂

    0
  • B

    Jester: Ich seh nicht zu was für Problemen das führen soll, wenn length_of dann 32 zurückliefert.

    0
  • G

    Original erstellt von Bashar:
    Jester: Ich seh nicht zu was für Problemen das führen soll, wenn length_of dann 32 zurückliefert.

    wenn es aber nur 17 objekte geben soll, außerdem müssten dan 15 unötige ctor aufrufe getragen werden

    0
  • B

    wenn delete weiß, wieviele dtors aufgerufen werden müssen, kann length_of doch genau die Zahl zurückliefern ...

    ich denke es geht um POD Objekte ... bei denen isses dann IMO unerheblich, ob ich nur die ansprechen darf, die ich tatsächlich alloziert hab, oder auch die, die mir der Compiler als alloziert zusichern will (in die Richtung müßte dann auch die Semantik von length_of definiert werden).

    0
  • V

    Original erstellt von HumeSikkins:
    [quote] was ich mir noch wünche ist das nan die grösse eines dynamischen arrays rausbekommen kann

    **
    Und wozu soll das gut sein? Erstens habe ich die größe sowieso, da ich sie ja angeben muss. Und zweitens gibt's da ja auch noch sowas schönes wie Container.
    **[/QUOTE]
    performance. nullkosten sind toll.
    wenn new[] die größe speichert, dann will ich sie auch auslesen können. new[] muß die größe dann speichern, wenn die elemente nen nichttrivialen dtor haben. und genau dann wäre es nicht schrecklich, man würde mir die freiheit geben, nen schnellen vector mit _begin und _end oder nen lahmeren mit _begin und end() zu basteln.

    ps: kann ich auch so. ich bastel mir in wenigen wochen arbeit nen allokator, der so gut wie ::new ist, aber zusätzlich dieses feature hat.

    pps: kann ich doch nicht. man überlege sich nen compiler, der ein register reserviert hält für topOfHeap, meiner müßte das mit Speicher erledigen. außerdem kann der compiler sich manchmal merken, ob der user überhaupt angefragt hat und wenn nicht, das speichern sein lassen. oder sich merken, wie groß das ding war und stat abzuspeichern der anfrage hart reincompilieren.

    [ Dieser Beitrag wurde am 22.01.2003 um 04:20 Uhr von volkard editiert. ]

    0
Anmelden zum Antworten