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

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.

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?

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.

Helium

ich hab leider den Link nicht mehr. möglicherweise hab ich was falsch verstanden. Jetzt wo ich drüber nachdenke ist es doch wirklich kein problem vorher die Größe zu pushen.

HumeSikkins

das soll nicht mehr so sein, kein template und typename um (ka wie ich es sagen soll)
*7 template-template parameter raus, stattdessen einfach

Das fände ich aber garnicht gut. Das 2-Phasen-Lookup hat doch den riesen Vorteil, dass Fehler früher erkannt werden. Nimmst du das weg, kann ein Template nur noch bei der Instanziierung überprüft werden -> Blöd.

Viel besser fände ich es, wenn der Compiler überflüssige typenames einfach ignorieren würde.

Und die Behebung des Referenz-auf-Referenz-Problems fände ich auch ziemlich dufte.

dann wünche ich mir noch ein public, private und protected das nur für eine deklaration gild so wie in Java

Nein. Bitte nicht. Das finde ich an Java ganz schrecklich. Ich gehöre schließlich noch zu den schreibfaulen Programmieren
Außerdem bin ich ein Freund der Redundanzvermeidung. Warum soll ich 12 mal etwas hinschreiben, wenn es einmal auch tut?

[ Dieser Beitrag wurde am 23.01.2003 um 21:18 Uhr von HumeSikkins editiert. ]

Gerard

Original erstellt von HumeSikkins:
Das fände ich aber garnicht gut. Das 2-Phasen-Lookup hat doch den riesen Vorteil, dass Fehler früher erkannt werden. Nimmst du das weg, kann ein Template nur noch bei der Instanziierung überprüft werden -> Blöd.

es hat mich ne zeit lang genervt, weil mein compiler kein 2-Phasen-Lookup macht und wenn ich mal ein typename vergessen habe, hat er sich auch nicht beschwert.
Jedesmal wenn ich zufälig ein fehlendes entdeckt habe, war mir das schon peinlich den ich wollte portablen code machen
also gegen ein 2-Phasen-Lookup habe ich nichts gegen, aber soll der compilier sich selber die informationen hollen
z.b.

template<typename container>
struct container_wrapper
{
    typedef container::iterator iterator; 
    // also hier sollte ein compilier erkennen können das ich
    // keine static member zum typ (oder ähnliches) machen will 
    // und sich sein typename selber denken
    // ok das macht ein 2-Phasen-Lookup umständlicher zu implementieren
    // und viele compilier bauer werden deshalb drauf verzichten
    // aber sollen sich lieber die compilier bauer einmal ansträgen
    // damit die tausende programmierer es leichter haben
};

Original erstellt von HumeSikkins:
Viel besser fände ich es, wenn der Compiler überflüssige typenames einfach ignorieren würde.

wird er wohl müssen wenn meine idee duch kommt

Original erstellt von HumeSikkins:
Und die Behebung des Referenz-auf-Referenz-Problems fände ich auch ziemlich dufte.

das dufte kein problemm sein das durch zu kriegen

Original erstellt von HumeSikkins:
**Nein. Bitte nicht. Das finde ich an Java ganz schrecklich. Ich gehöre schließlich noch zu den schreibfaulen Programmieren
Außerdem bin ich ein Freund der Redundanzvermeidung. Warum soll ich 12 mal etwas hinschreiben, wenn es einmal auch tut?
**

ne es soll ja nicht die private: und public: ersetzen es soll nur eine weiter möglichkeit sein, ab und zu ist es leichter für ein framework bestimte makros für methoden deklarationen/definitionen anzubieten damit man seine klassen im framework benutzen kann.
in c++98 muss man den leuten noch sagen ob sie das makro im public oder in private bereich benutzen müssen

[ Dieser Beitrag wurde am 24.01.2003 um 00:08 Uhr von Dimah editiert. ]

HumeSikkins

in c++98 muss man den leuten noch sagen ob sie das makro im public oder in private bereich benutzen müssen

Wieso? Du kannst dem Makro (ihhh! Makros) doch gleich noch private/protected/public-Block spendieren.

Dann packt der Nutzer das hin wo er will. Er muss halt nur nach dem Makro wieder das gewünschte Accesslevel angeben. Aber das dürfte für jemanden der Makros mag doch kein Problem sein, oder?

Allen denen das zu kompliziert ist wird einfach empfohlen das Makro als letztes in die Klassendefiniton zu schreiben.

Das Problem (wenn man dort eins sehen möchte) rechtfertigt in meinen Augen keinesfalls eine Änderung der Sprache.

HumeSikkins

aber soll der compilier sich selber die informationen hollen
z.b.

C++ ist schon so furchtbar komplex und die Grammatik so furchtbar mehrdeutig (und kontextabhängig).

Auch hier scheint mir der Vorteil gegenüber den Nachteilen zu gering zu sein. Aber irgendwas wird mit dem typename passieren, zumindest wird da was diskutiert

Gerard

Original erstellt von HumeSikkins:
Auch hier scheint mir der Vorteil gegenüber den Nachteilen zu gering zu sein. Aber irgendwas wird mit dem typename passieren, zumindest wird da was diskutiert

sehr gut,
dann kann ich das auch von meiner liste streichen

[ Dieser Beitrag wurde am 24.01.2003 um 11:05 Uhr von Dimah editiert. ]

Gerard

Original erstellt von HumeSikkins:
Wieso? Du kannst dem Makro (ihhh! Makros) doch gleich noch private/protected/public-Block spendieren.

ab und zu sind sie schon notwendig (natürlich kann man auch den user zum präprozessor machen) und wenn sie mal notwendig sind dann wäre es schon hilfreich

ok eigentlich sind die leute das gewöhnt das sie makros in einen bestimten block machen müssen, also antrag zurück gezogen

aber das mit den namespace ist mir wichtiger, aber auch schwerer durch zu setzen

[ Dieser Beitrag wurde am 24.01.2003 um 11:17 Uhr von Dimah editiert. ]