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

[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++

[Eselsohr]

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.

[Gerard]

Original erstellt von <Eselsohr>:
WARUM kommt den bei 3 ein Syntaxfehler?

bin ich selbt überfragt
selbst

if(string::size_type pos = s.find( "a" )) // da beschwert sich der compiler nicht
    // ...

// aber schon bei
if((string::size_type pos = s.find( "a" ))) // will er nicht mehr
    // ...  

"ComeauTest.c", line 7: error: expected a ")"
      if((std::string::size_type pos = s.find( "a" )))
                                 ^
"ComeauTest.c", line 7: error: expected an expression
      if((std::string::size_type pos = s.find( "a" )))                                                   ^

Original erstellt von Lars:
das wird nie gehen, weil ein template noch kein normaler typ ist.

sag niemals nie,

template<typename Container>
struct bla
{
    Container<int> c; // wenn der compiler so was hier sieht dann kann er
};                    // von mir aus sich intern aus template<typename Container>
                      // ein template<template<typename> class Container> 
                      // machen

das was mir an template-template parametern nicht schmeckt ist die syntax
ich fände

template<template container<typename> >
struct bal
{
};

besser, aber ich will der nähsten generation kein neues <iostream.h> antuen
nr.7 lasse ich dan mal weg,

[ Dieser Beitrag wurde am 23.01.2003 um 13:17 Uhr von Dimah editiert. ]

[Shade Of Mine]

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

also ich haette schon gerne das es hier syntax fehler gibt...

was soll es denn werden?

(int i);
geht ja auch nicht - wir sind ja keine lisper

[Gerard]

aber if(int i); geht,
und was hast du gegen?

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

z.b.

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

geht, nur das dan in pos entweder 1 oder 0 drin ist

wenn wir was von den lispern lernen können dan sollten wir das oder mir egal wie sie das lösen hauptsache ich kann
etwas equwalentes zu dem hier bekommen

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

[rüdiger]

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

Stroustrup schreib in seiner FAQ folgendes dazu http://www.research.att.com/~bs/bs_faq2.html#no-derivation . Deswegen glaube ich, dass das abgelehnt wird.

Und *4 verstehe ich nicht so ganz, meinst du soetwas:

struct x
{
  int foo(void);
};

typelist<x> a;
a[0].returntype; //gibt "int" zurück
a[0].name; //gibt "foo" zurück
a[0].param[0]; //gibt void zurück

glaub nicht, dass es so etwas geben wird, da dazu ja Laufzeit unterstützung gefragt ist oder Compilertricks.

[volkard]

Original erstellt von Dimah:
**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 &);
```**

Ich leb seit langem gut mit
#define NOCOPY NoCopy _nocopy;

[Gerard]

Original erstellt von kingruedi:
**Stroustrup schreib in seiner FAQ folgendes dazu http://www.research.att.com/~bs/bs_faq2.html#no-derivation . Deswegen glaube ich, dass das abgelehnt wird.
**

es gibt ja noch andere einsatzgebiete außer NOCOPY

Original erstellt von volkard:
Ich leb seit langem gut mit
#define NOCOPY NoCopy _nocopy;

ist doch so ein msvc only ding?

Original erstellt von kingruedi:
**Und *4 verstehe ich nicht so ganz, meinst du soetwas:

struct x
{
  int foo(void);
};

typelist<x> a;
a[0].returntype; //gibt "int" zurück
a[0].name; //gibt "foo" zurück
a[0].param[0]; //gibt void zurück

glaub nicht, dass es so etwas geben wird, da dazu ja Laufzeit unterstützung gefragt ist oder Compilertricks.**

`
ok das mit funktion ist auch gut, aber ich meine so was

class foo
{
    typedef loki::make_typelist<int, bool, std::string>::result type_of_members;
    int i;
    int bool;
    std::string s;
};

ich habe blos kein bock das selber zu machen, soll der compilier für mich die schreib arbeit machen

[ Dieser Beitrag wurde am 23.01.2003 um 15:11 Uhr von Dimah editiert. ]

[Helium]

HumeSikkins hat mir mal ein Link gegeben, warum es in C++ keine VLAs geben kann (technisch gesehen). Das ist ganz einfach: Der Compiler muss wissen, weiviele Elemente es gibt, damit er eine entsprechende Anzahl von Destruktoren aufrufen kann. Da bei VLAs die Größe erst zur Laufzeit bekannt ist, geht das nicht. (Bei new wird vor den eigentlichen Daten noch die Größe abgelegt.)

vector kann sich aber kaum auf den stack legen

Was ist mit eigenen Allokatoren?

[volkard]

Original erstellt von Helium:
**HumeSikkins hat mir mal ein Link gegeben, warum es in C++ keine VLAs geben kann (technisch gesehen). Das ist ganz einfach: Der Compiler muss wissen, weiviele Elemente es gibt, damit er eine entsprechende Anzahl von Destruktoren aufrufen kann. Da bei VLAs die Größe erst zur Laufzeit bekannt ist, geht das nicht. (Bei new wird vor den eigentlichen Daten noch die Größe abgelegt.)
**

sorry, aber du redest blech, befürchte ich.
falls man echt mal nen typen mit destruktor ablegen möchte, kann der compiler doch auch noch ne speicherzelle mehr nehmen und da die elementanzahl reinmachen, oda?

[Lars]

schließlich könnte er das bei VLAs auch speichern.