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

[Bashar]

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).

[volkard]

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. ]

[volkard]

Original erstellt von Bashar:
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).

man könnte sich evtl gut absichern, wenns noch ein neues schlüsselwort bool ispod(Type) gäbe. würde ich mir eh manchmal wünschen, um fix ein memcpy statt ner schleife zu nehmen.

[Shade Of Mine]

Original erstellt von volkard:
man könnte sich evtl gut absichern, wenns noch ein neues schlüsselwort bool ispod(Type) gäbe. würde ich mir eh manchmal wünschen, um fix ein memcpy statt ner schleife zu nehmen.

was hältst du von dem Ansatz std::copy zu auf POD-Typen zu spezialisieren und dann nur auch memcpy weiterzuleiten...

das gefällt mir recht gut, da ich mich nicht darum kümmern muss, sondern copy die aufgabe übernimmt sich selbst möglich effizient zu implementieren.

[volkard]

Original erstellt von Shade Of Mine:
was hältst du von dem Ansatz std::copy zu auf POD-Typen zu spezialisieren und dann nur auch memcpy weiterzuleiten...
das gefällt mir recht gut, da ich mich nicht darum kümmern muss, sondern copy die aufgabe übernimmt sich selbst möglich effizient zu implementieren.

klar, der ist ganz gut. hab ich auch schon verwendet.
nur leider kann ich nicht alle pod-typen auflisten.

[Gerard]

Original erstellt von volkard:
klar, der ist ganz gut. hab ich auch schon verwendet.
nur leider kann ich nicht alle pod-typen auflisten.

etwas loki::int2type<>, std::iterator_traits<Iterator>::value_type und boost::is_POD<T>::value und dan geht das schon

[ Dieser Beitrag wurde am 22.01.2003 um 11:10 Uhr von Dimah editiert. ]

[HumeSikkins]

man könnte sich evtl gut absichern, wenns noch ein neues schlüsselwort bool ispod(Type) gäbe. würde ich mir eh manchmal wünschen, um fix ein memcpy statt ner schleife zu nehmen.

Ich denke die generische Programmierung schreit sowieso noch nach ein paar Schlüsselwörtern. Klar kann man fast alles mit krassen traits und co. erledigen. Das ist aber immer super aufwendig und eigentlich soll eine Sprache einen ja auch unterstützen. OOP geht ja auch in C. In C++ geht es halt nur leichter. Ähnlich sehe ich das mit der generischen Programmierung im Zusammenhang mit dem ganzen Template-Gedöns. Ich denke, wenn sich in C++ da nicht einiges ändert, werden manche Templatetechniken nie wirklich aus ihrem Nischendasein rauskommen.

Wenn's nicht über Schlüsselwörter passiert, dann muss es halt über viele Zugaben in der Standardlib erfolgen. Aber das ich mir immer erst boost runterladen und installieren muss, nur damit ich ein paar coole Dinge machen kann, halte ich persönlich nicht für so prickelnd.

[ Dieser Beitrag wurde am 22.01.2003 um 11:18 Uhr von HumeSikkins editiert. ]

[Knuddlbaer]

aber oft kommt es mir vor wie ein verein von haar spaltern und erbsen zählern dann gäbe es keinen vernünftigen Standard sondern nur ein einziges riesiges Chaos wo jeder macht was er will.

Das nennt man heutzutage kurz "Microsoft" *sfg

[Gerard]

Original erstellt von HumeSikkins:
Ich denke die generische Programmierung schreit sowieso noch nach ein paar Schlüsselwörtern.

du kennst ja die Standard Komite Politik was neue Schlüsselwörtern angeht, ich frage mich, wieso bei den compilern nicht gleich boost & ACE und co. mitgeliefert werden

[volkard]

Original erstellt von Dimah:
etwas loki::int2type<>, std::iterator_traits<Iterator>::value_type und boost::is_POD<T>::value und dan geht das schon
[ Dieser Beitrag wurde am 22.01.2003 um 11:10 Uhr von [qb]Dimah editiert. ][/QB]

also ich nehme immer
struct foo
{
int x;
};
und mein kollege nimmt nur
struct bar
{
signed x;
};
wie macht boost::is_POD es, foo und bar zu erkennen?

[Gerard]

habe die boost::type_traits überschetzt

als workaround kann ich anbieten

#define BOOST_ISPOD(Type)       \
namespace boost                 \
{                               \
    template<>                  \
    struct is_POD<Type>         \
    {                           \
        enum { value = 1 };     \
    };                          \
}  

struct foo
{
    int x;
};
BOOST_ISPOD(foo)
struct bar
{
    signed x;
};
BOOST_ISPOD(bar)

ist aber nicht wirklich toll, stat dessen würde ich mir eine implizite typelist mit den typen der members wünschen, dann könnte man dazu ein richtiges is_POD schreiben

[volkard]

Original erstellt von Dimah:
habe die boost::type_traits überschetzt
als workaround kann ich anbieten
...
ist aber nicht wirklich toll, stat dessen würde ich mir eine implizite typelist mit den typen der members wünschen, dann könnte man dazu ein richtiges is_POD schreiben

Toll genug. Ich tu mir nicht weh, diese Zeile unter die paar Pods zu schreiben, die ich schnell kopiert haben mag. Und Deine Lösung ist fein einfach und durchschaubar, was ich besonders schätze.

[Gerard]

Original erstellt von volkard:
Toll genug. Ich tu mir nicht weh, diese Zeile unter die paar Pods zu schreiben

nun ja
z.b

namespace dim
{
    struct foo
    {
        int x;
    };

    struct bar
    {
        signed x;
    };
}
BOOST_ISPOD(dim::foo) 
BOOST_ISPOD(dim::bar)

ok das kann man noch tragen, aber eine buldin unterstützung wäre viel schöner

[rüdiger]

was ich gut fänd

void f(size_t n)
{
  char s[n];
}

C99 kann das ja schon.

[Bashar]

Ich frage mich, ob die Idee, sizeof nicht mehr strikt zur Compilezeit auszuwerten, so toll war ...

[Gerard]

Original erstellt von kingruedi:
**was ich gut fänd

void f(size_t n)
{
  char s[n];
}

C99 kann das ja schon.**

in c kann ich sowas verstehen aber in c++ gibts std::vector und co.
ist ja eigentlich blos wie ein boost::scoped_array + new nur hinter einer buldin schnittstelle, sehe jetzt nur vorteile für anfänger

eine meiner kleinen sorgen ist das c++ programme im durchschnitt langsammer werden weil alle VLA benutzen statt sich mal gedanken zu machen wie man das auch mit ein stack array lösen könnte
oder unnötig große Arrays machen statt std::list usw.

[ Dieser Beitrag wurde am 22.01.2003 um 18:59 Uhr von Dimah editiert. ]

[Mr. N]

Original erstellt von Dimah:
in c kann ich sowas verstehen aber in c++ gibts std::vector und co.

vector kann sich aber kaum auf den stack legen.

[rüdiger]

@Dimah

in c kann ich sowas verstehen aber in c++ gibts std::vector und co.

Und wo reserviert vector seinen Speicher?

eine meiner kleinen sorgen ist das c++ programme im durchschnitt langsammer werden weil alle VLA benutzen statt sich mal gedanken zu machen wie man das auch mit ein stack array lösen könnte

Ich dachte reservieren von Speicher auf dem Heap, wär so teuer.

naja ansonsten wär ich auch mit einer Art alloca zufrieden

[Bashar]

Ich fänd alloca auch besser, da dann sizeof garantiert compiletime ist. Hm weiß nicht, vielleicht isses auch egal, ist nur so'n Gefühl, dass sie da eine Art Fundament rausgerissen haben ...

[Gerard]

hmm können überhaupt VLAs auf den stack gelegt werden?