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

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?

Mr. N

Original erstellt von Dimah:
hmm können überhaupt VLAs auf den stack gelegt werden?

wtf sind VLAs? variable-length-arrays? klar können die das!

sub esp, ecx

HumeSikkins

Hallo,
wenn ich Bjarne Stroustrup und Randy Meyers richtig verstanden habe, wird es VLAs in C++ wohl nicht geben. Im Sinne von: Ist sehr unwahrscheinlich, da es bereits eine Library-Solution gibt und solche zur Philisophie von C++ besser passen.

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

Das ist Implementation-defined. Es gibt definitiv Implementationen die VLAs auf den Stack legen und es gibt definitiv Implementationen die VLAs auf den Heap packen.
(siehe: Bjarne Stroustrup: "C and C++: Siblings" I-III
und Randy Meyers: "Variable Length Arrays" Part 1 bis Part 3)