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

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

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

[Gerard]

Hi,

The message below was submitted by you to a moderator of comp.std.c++,
either by posting a message to the group, or by sending E-mail to the
group's submission address, or by sending mail to the group's
administrative address.

Your message is not appropriate for posting to comp.std.c++, because
it does not fit the charter. I suggest you try comp.lang.c++.moderated.
instead.

Charter:
comp.std.c++ is for technical announcements and discussion of the
ANSI/ISO C++ standardization process and the C++ standard, and for
discussion of the design and standardization of the C++ language and
libraries. Other discussion that is directly related to the C++
standard (not related merely to C++ programming techniques) is
also welcome. Posts should be cogent and free from personal attacks.

Questions about C++ programming techniques should instead be posted to
comp.lang.c++ or comp.lang.c++.moderated. Questions that are specific to some
particular platform should be posted to a group devoted to that platform.

comp.std.c++ is moderated by panel. A submission will be sent randomly
to one of the moderators, who will decide to post or reject it. There
is also be an alias you can use to discuss matters (either individual
posts or general policy) with all of the moderators.

Submission address: std-c++@ncar.ucar.edu
Contact address: std-c++-request@ncar.ucar.edu
List of moderators:
Matt Austern austern@apple.com
Steve Clamage stephen.clamage@sun.com
James Dennett jdennett@acm.org
Phil Edwards phil+csc@jaj.com
Fergus Henderson fjh@cs.mu.oz.au
WWW home page: http://www.jamesd.demon.co.uk/csc/policy.html

If you have any questions, don't hesitate to ask.

Thanks,
-Moderator.

============================================ Full text of your message follows
> From daemon@irje.UCAR.EDU Sat Jan 25 13:01:24 2003
> Received: from irje.UCAR.EDU (irje.ucar.edu [192.52.106.5]) by mulga.cs.mu.OZ.AU with ESMTP
> id NAA19428 for fjh@cs.mu.oz.au; Sat, 25 Jan 2003 13:01:23 +1100 (EST)
> Received: (from daemon@localhost)
> by irje.UCAR.EDU (8.9.1a/) id TAA17616
> for fjh@cs.mu.oz.au; Fri, 24 Jan 2003 19:01:21 -0700 (MST)
> Received: from mscan5.ucar.edu (mscan5.ucar.edu [128.117.64.127])
> by irje.UCAR.EDU (8.9.1a/) with ESMTP id TAA17613
> for std-c++@irje.ucar.edu; Fri, 24 Jan 2003 19:01:21 -0700 (MST)
> Received: by mscan5.ucar.edu (Postfix)
> id 68821FA878; Fri, 24 Jan 2003 19:01:21 -0700 (MST)
> Delivered-To: std-c++@ncar.ucar.edu
> Received: from localhost (localhost [127.0.0.1])
> by mscan5.ucar.edu (Postfix) with ESMTP id 3D128FA876
> for std-c++@ncar.ucar.edu; Fri, 24 Jan 2003 19:01:21 -0700 (MST)
> Received: from trinity.supernews.net (trinity.ranger.supernews.net [216.168.1.22])
> by mscan5.ucar.edu (Postfix) with ESMTP id AACDEFA878
> for std-c++@ncar.ucar.edu; Fri, 24 Jan 2003 19:01:18 -0700 (MST)
> Received: from mailout06.sul.t-online.com ([194.25.134.19])
> by trinity.supernews.net with esmtp (Exim 4.12)
> id 18cFdG-000BG9-00
> for comp-std-c++@moderators.isc.org; Sat, 25 Jan 2003 02:01:18 +0000
> Received: from imh00.t-online.com
> by mailout06.sul.t-online.com with esmtp
> id 18cFdE-0007tT-00; Sat, 25 Jan 2003 03:01:16 +0100
> Received: from news.t-online.com by imh00.t-online.com
> with esmtp id 18cFdE-0007Gu-00; Sat, 25 Jan 2003 03:01:16 +0100
> Received: from news by news.t-online.com with local
> id 18cFdE-0005nm-00; Sat, 25 Jan 2003 03:01:16 +0100
> To: comp-std-c++@moderators.isc.org
> From: Gerard Choinka choinka@web.de
> Newsgroups: comp.std.c++
> Subject: new declarations rules
> Organization: T-Online
> Message-ID: b0sr5b$lou$00$1@news.t-online.com
> Mime-Version: 1.0
> Content-Type: text/plain; charset=windows-1252; format=flowed
> Content-Transfer-Encoding: 8bit
> X-Trace: news.t-online.com 1043460075 00 22302 fCvaEecVSWA-U6 030125 02:01:15
> X-Complaints-To: abuse@t-online.com
> X-Sender: 520096648365-0001@t-dialin.net
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
> X-Accept-Language: en-us, en, de-de
> X-Spam-Status: No, hits=-1.3 required=5.0
> tests=INVALID_MSGID,NOSPAM_INC,SPAM_PHRASE_00_01,USER_AGENT,
> USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG
> version=2.41

> Hallo
> I wish me for c++0x that this kind of syntax will work:
> string s( "Hallo, World!" );
> if((string::size_type pos = s.find( "a" )) != string::npos)
> // work with pos

> Comeau(and my other compilers) says to this

> "ComeauTest.c", line 6: error: expected a ")"
> if((string::size_type pos = s.find( "a" )) != string::npos)
> ^

> "ComeauTest.c", line 6: error: expected an expression
> if((string::size_type pos = s.find( "a" )) != string::npos)
> ^

> I am use often a similar syntax with streams
> if(ifstream fin( "some.txt" ))
> // work with fin
> else
> // error

> and it works very well, the fin object is very local and don’t waste my
> resources.
> How is the feasibility?

> Gerard Choinka is thanks your for answers.

ps. ich bin mir im klaren das mein englisch misstig ist