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

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)

Gerard

hmm da kommt mir doch eine idee, absolut adresierbare namespace deklarionen
*1

namespace boost
{
    template<typename T>
    struct is_POD
    {
        enum { value = 0 };
    };
}

//...

namespace dimlib
{
    struct foo
    {
        int i;
    }

    // das würde normaler weise aus ein Makro kommen
    namespace ::boost
    {
        template<>
        struct is_POD<dimlib::foo>
        {
            enum { value = 1 };
        };
    }

// hier noch ein bsp
    namespace fuu
    {
        template<bool b> 
        struct bla 
        {
            enum { value = b };
        };
    }

    namespace bla
    {
        namespace ::dimlib::fuu
        {
            template<>
            struct bla<true>
            {
                enum { value = 1 };
            };
        }
    }  
}

keine neuen schlüsselwörter, keine problemme mir alten code, leichter zu schreibende makros und co.

*2
dann wünche ich mir noch ein public, private und protected das nur für eine deklaration gild so wie in Java, das würde einen das schreiben von makros erleichter
z.b.

#define NOCOPYABLE(klasse)                   \
private klasse(const klasse &);              \
private klasse & operator= (const klasse &);

*3
dan hätte ich gern das, das hier kein syntax fehler ergibt

if((std::string::size_type pos = s.find( "a" )) != string::npos)
    // bla

*4
eine impizite typelist mit allen member von einer class/structs/... damit ich dann ein is_POD schreiben kann, wo der user nicht explizit spezialiesieren muss

*5
length_of ist wieder im spiel, vielleicht wäre aber std::begin() und std::end() schöner oder auch beides

*6

Original erstellt von HumeSikkins:
**Kurz: Wann immer ein von einem Templateparameter abhängiger Name einen Typ darstellen soll (außer in einer Basisklassenaufzählung oder in einer Initialisierungsliste).

Folgendes muss also zutreffen:
Der Name
1. taucht in einem Template auf
2. ist qualifiziert (also z.B. über :: oder . bzw. -> )
3. wird nicht in einer Basisklassenaufzählung oder in einer Initialisierungsliste benutzt
4. ist abhängig von einem Templateparameter.
**

das soll nicht mehr so sein, kein template und typename um (ka wie ich es sagen soll)

*7 template-template parameter raus, stattdessen einfach

template<typename Container>
struct bla
{
    Container<int> c;
};

soll der compiler doch für uns schwitzen

[ Dieser Beitrag wurde am 23.01.2003 um 02:04 Uhr von Dimah editiert. ]

Gerard

ahja wer sich fragt wieso ich das nicht in comp.std.c++ bespreche, das hier ist die vorausscheidung für comp.std.c++

WARUM kommt den bei 3 ein Syntaxfehler?

Lars

Original erstellt von Dimah:
**
*7 template-template parameter raus, stattdessen einfach
template<typename Container>
struct bla
{
    Container<int> c;
};
soll der compiler doch für uns schwitzen

[ Dieser Beitrag wurde am 23.01.2003 um 02:04 Uhr von [qb]Dimah** editiert. ][/QB]

das wird nie gehen, weil ein template noch kein normaler typ ist.