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

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

  • G

    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

    0
  • L

    nimm den ganzen compilerspezifischen kram raus, frag mal genauer danach warum das nicht standardkonform ist und was gegen diese Syntax in einem zukünftigen Standard spricht. und probiers nochmal.

    0
  • L

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

    😕 was ist das?

    Nein. Bitte nicht. Das finde ich an Java ganz schrecklich. Ich gehöre schließlich noch zu den schreibfaulen Programmieren 🙂
    [/QB]

    Dann biste bei C++ falsch 😉

    0
  • H

    was ist das?

    Referenzen auf Referenzen sind in C++ nicht erlaubt. Man kann also nicht sowas schreiben wie:

    int&& r = ...

    Das scheint auf den ersten Blick kein Problem zu sein. In Verbindung mit Templates kommt es aber häufig zu solchen Referenz-auf-Referenz-Problemen. Bei der Verwendung der STL z.B. immer, wenn du versucht einen binder zusammen mit mem_fun_ref und einer Methode die ihren Parameter per Referenz erhält zu verbinden:

    #include <iostream>
#include <vector>
#include <algorithm>
#include <functional>
using namespace std;

// Beispiel aus Scott Meyers' Effective STL
class Widget
{
     public:
         int readStream(istream& is)
         {
             //...
             return 0;
         }
};
int main()
{
    vector<Widget*> vw;
    //...
    for_each(vw.begin(), vw.end(), bind2nd(mem_fun(&Widget::readStream), cin));
}

    Ein einfaches Beispiel ist das:

    template <class T>
void apply(T& arg, void (*Func)(T))
{
    Func(arg);
}

void FuncOk(int arg)
{}

void FuncKaputt(int& arg)
{}

int main()
{
    int x = 32;

    // Ok. T ist int
    apply(x, &FuncOk);

    // Nicht ok. T ist int&
    // Dann wäre arg aber int&& -> Referenz auf Referenz
    apply(x, &FuncKaputt);
}

    Mittlerweile gibt es einen technical corrigendum der den oberen Code erlauben würde. Hier wird dann für eine Substitution von T& mit T = int& einfach zu int&. Für const gibt es sowas schon lange.

    0
  • L

    könnt man das nicht so machen:

    template<class T>
struct gettype<T&> {
  typedef T type;
};
template<class T>
struct gettype {
  typedef T& type;
};

    [ Dieser Beitrag wurde am 26.01.2003 um 12:38 Uhr von Lars editiert. ]

    0
  • H

    könnt man das nicht so machen:

    Nein. So nicht. Wenn du das Base-Template noch vor die Spezialisierung schreibst, dann haut's hin 🙂
    Das ist aber nicht der Punkt. Workarounds gibt's schon lange (schau mal auf boost.org in die type_traits).

    Hier liegt aber eine Inkonsistenz vor (wie gesagt, ein const wird einfach ignoriert) und immer diese Workarounds schreiben zu müssen kann wohl auch nicht der Weißheits letzter Schluss sein.

    Aber jetzt wo ich weiß, dass es bereits ein technical corrigendum gibt, spielt das Thema für den nächsten Standard sowieso keine Rolle mehr.

    Also heute noch drum rum arbeiten und morgen (eher 2008) die neue Substitutionsregel begüßen 🙂

    0
  • L

    Du hast recht. SChreib das doch mal in comp.std.c++.
    Ich hab dort folgendes geschrieben:

    In comp.std.c++
In nearly every case the implementation of the operator++(int) and operator--(int) looks like that:
class Example {
  public:
    Example& operator++() {// or operator--
      //implementation
      return(*this);
    }
    const Example operator++(int) { // or operator--
      Example temp(*this);
      ++*this;
      return temp;
    }
}
Whats the sence of the possibility to overload the postfix operator?
Why is the postfix operator not auto-implemented? 
That would has the advantage that compiler could optimize postfix-uses (even it
 is a mistake of the programmer, that he used the postfix one).

    [ Dieser Beitrag wurde am 26.01.2003 um 13:35 Uhr von Lars editiert. ]

    0
  • G

    Original erstellt von Lars:
    **Whats the sence of the possibility to overload the postfix operator?
    Why is the postfix operator not auto-implemented?
    That would has the advantage that compiler could optimize postfix-uses (even it
    is a mistake of the programmer, that he used the postfix one).
    **

    ich glaube das die sich ähnliche gedanken zu c++98 gemacht haben, es gibt bestimmt gute gründe wieso man die postfix version überladen darf.
    Aber mir kann eine änderung sowieso egal sein, wie oft überlade ich den, den op++?
    und mit meiner eselsbrücke langammer postfix == häslicher int dummy kann ich mir das relativ leicht merken

    0
  • L

    Original erstellt von Dimah:
    **
    ich glaube das die sich ähnliche gedanken zu c++98 gemacht haben, es gibt bestimmt gute gründe wieso man die postfix version überladen darf.
    Aber mir kann eine änderung sowieso egal sein, wie oft überlade ich den, den op++?
    und mit meiner eselsbrücke langammer postfix == häslicher int dummy kann ich mir das relativ leicht merken**

    Es geht ja gar nicht um Lesbarkeit oder Hässlichkeit des int-dummys, sondern um Redudanz und Optimierung. Ich hab folgende Antwort erhalten:

    One could say something similar about operator + and operator += :
class Example
{
public:
   Example& operator += (const Example& other)
   {  // implementation
      return *this;
   }

   Example operator + (const Example& other) const
   {
      Example temp(*this);
      temp+=other;
      return temp;
   }
};

and perhaps more examples; if you allow me, let me generalize your
proposition by using some directive to let the compiler know : "I want
this method: auto-implement it", for example with the already existent
'auto' keyword.

An 'auto-implementation' table should be standarized (i.e. saying:
method    auto-implemented using
------    ----------------------------
++(int)   ++()
+         +=
...       ...

and a standard auto-implementation for each one (left column).

Your example would look like:

class Example
{
public:
   Example& operator += (const Example& other)
   {  // implementation
      return *this;
   }

   auto Example operator + (const Example& other) const;

   Example& operator ++ ()
   {  /* your example */ }

   auto Example operator ++(int);
};

I think this is important in terms of optimization and readability (as
far as the client 'see' that some operator is auto-implemented).

 Daniel.

    genau das halt ich auch für sinnvoll

    0
  • H

    Hallo,
    hat jetzt eigentlich schon jemand ein Vorschlag für ein foreach ohne typeof gemacht?

    Wenn nein, hier meiner:

    struct ForEachHelper
{
    void* cur_;
    template <class T, class U>
    bool assign (T& r, U& c)
    {
        typedef typename U::iterator iter;
        if (*static_cast<iter*>(cur_) != c.end())
        {
            r = **static_cast<iter*>(cur_);
            ++*static_cast<iter*>(cur_);
            return true;
        }
        delete static_cast<iter*>(cur_);
        return false;
    }
    template <class U>
    ForEachHelper(U& cont)
    {
        typedef typename U::iterator iter;
        cur_ = (void*)new  iter(cont.begin());
    }
};

#define FOREACH(var, cont) for (ForEachHelper b(cont) ; b.assign(var,cont);)

    Anwendung:

    vector<int> vec;
vec.push_back(6);
vec.push_back(5);
vec.push_back(4);
int n;
FOREACH(n, vec)
{
    cout << n << endl;
}
set<string> s;
s.insert("abc");
s.insert("cde");
s.insert("efg");
string str;
FOREACH(str, s)
{
    cout << str << endl;
}
    0
  • B

    lol, da hätte man eigentlich früher drauf kommen können. Statt den deklarierten Typ zu parametrisieren, einfach bei jeder Anwendung davon einen parametrisierten Cast benutzen

    nice 🙂

    0
  • ?

    cur_ = (void*)new iter(cont.begin());

    Warum nimmst Du nen C-Style-Cast hier?
    Dass man seinen Iterator auf den Heap legen muss is performance-mäßig auch ein bisschen traurig.

    Aber ziehmlich cool eigentlich. Werd ich mal verwenden und mich vielleicht sogar dran gewöhnen 🙂

    0
  • H

    Warum nimmst Du nen C-Style-Cast hier?

    Um etwas Inkonsistenz reinzubringen und damit den Leser wach zu halten 😃

    Dass man seinen Iterator auf den Heap legen muss is performance-mäßig auch ein bisschen traurig

    Richtig. Das ist ein echter Nachteil. Allerdings lässt sich dieser zur Not auch umgehen. Man muss ja nur new passend überladen.

    0
  • ?

    Was wird der nächste Standard beinhalten? Templatetypedefs?

    0
  • O

    *** schrieb:

    Was wird der nächste Standard beinhalten? Templatetypedefs?

    das wär mal was 👍

    //edit wow is der thread schon alt 😮

    0
  • M

    Wie wärs mal mit nem neuen Thread. Auf den ersten kann man leider schon nicht mehr zugreifen 😞

    Wie stehts eigentlich im Moment um C++0x? Welche Änderungen gibts? Ach, ich mach jetzt einfach nen neuen auf.

    0
  • ?

    was beudetet eigentlich C++0x?

    0
  • M

    0x steht für das Erscheinungsjahr.

    0
  • N

    *** schrieb:

    Was wird der nächste Standard beinhalten?

    Template-Parameter als friends deklarieren zu können

    0
  • ?

    ness schrieb:

    *** schrieb:

    Was wird der nächste Standard beinhalten?

    Template-Parameter als friends deklarieren zu können

    auch sowas wie Hummes dirstream?

    0
Anmelden zum Antworten