lyonya <leonews@optonline.net> wrote:
> why not simply predefine boolean DoShow/DoNotShow?

> struct Foo{
>     static bool DoShow;
>     static bool DoNotShow;
>     void operator() (bool);
> };

why not integral constant expressions?

struct Foo {
  static const bool DoShow = true;
  static const bool DoNotShow = false;
  void operator() (bool);
};

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:

I believe the poster was replying on the thread "boolean function parameters",
but neglected to supply a subject or context. -sdc


===================================== END OF MODERATOR'S COMMENT
* lyonya:
> why not simply predefine boolean DoShow/DoNotShow?

What's this got to do with the C++ language?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

why not simply predefine boolean DoShow/DoNotShow?

struct Foo{
    static bool DoShow;
    static bool DoNotShow;
    void operator() (bool);
};

bool Foo::DoShow = true;
bool Foo::DoNotShow = false;
.
Foo(DoShow);
Foo(DoNotShow);

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"lyonya" <leonews@optonline.net> wrote in message
news:%wWqe.6520$S62.4657@fe11.lga...
> why not simply predefine boolean DoShow/DoNotShow?
>
> struct Foo{
>     static bool DoShow;
>     static bool DoNotShow;
>     void operator() (bool);
> };
>
> bool Foo::DoShow = true;
> bool Foo::DoNotShow = false;
> .
> Foo(DoShow);
> Foo(DoNotShow);
>

To Show or not to Show is not a concern in C++. Why modify a language that
would predefine members that are only relevent in a non-C++ extension? In
fact, why predefine any members at all? Why predefine members if the creator
of the class can do so himself? Why modify a language in order to make it
weaker?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marco Manfredini (marco@no-taris-spam.de) wrote:
> In fact, GNU C++ already has such an extension to the language, which
> doesn't need a new assignment operator. In an extra clause, you can define
> the name of a return value:
>
> Foo f(void) return r; // yes with ';'
>  {
>     r.var1=0;
>  }

I always found this annoying.

I believe the same effect could be reached if there was a special
variable name that could be handled with extra care by the optimizer.

Let's say, the special variable name is 'result', so one would write

 Foo f(void)
  {
     Foo result;
     result.var1=0;
     return result;
  }

*as usual*. The compiler could check, whether result and the return
type of f are the same, whether result is returned and whether nothing
else is return. If any of these tests fail, it's business as usual.
Otherwise, the variable could be removed by the optimizer.

This way one would get the best of both worlds: No extension to the
languange _and_ optimal code.

I wonder why the gcc people have opted for the extension.
Anybody out there who can shed some light on this?

Andre'

--
It'll take a long time to eat 63.000 peanuts.
Andr    P   nitz ......................... poenitz@mathematik.tu-chemnitz.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andre Poenitz <poenitz@mathematik.tu-chemnitz.de> schrieb in im Newsbeitrag:
8l16gk$kd9$1@narses.hrz.tu-chemnitz.de...
> Marco Manfredini (marco@no-taris-spam.de) wrote:
> > In fact, GNU C++ already has such an extension to the language, which
> > doesn't need a new assignment operator. In an extra clause, you can
define
> > the name of a return value:
> >
> > Foo f(void) return r; // yes with ';'
> >  {
> >     r.var1=0;
> >  }
>
> I always found this annoying.
>
> I believe the same effect could be reached if there was a special
> variable name that could be handled with extra care by the optimizer.
>
> Let's say, the special variable name is 'result', so one would write
>
>  Foo f(void)
>   {
>      Foo result;
>      result.var1=0;
>      return result;
>   }
>
> *as usual*. The compiler could check, whether result and the return
> type of f are the same, whether result is returned and whether nothing
> else is return. If any of these tests fail, it's business as usual.
> Otherwise, the variable could be removed by the optimizer.
>
> This way one would get the best of both worlds: No extension to the
> languange _and_ optimal code.
>

> I wonder why the gcc people have opted for the extension.
> Anybody out there who can shed some light on this?
>

The optimization with an 'return' or 'result' value requires the caller to
pass *something*, where the return value should be assigned to. This needs
to be denoted in the -declaration- of the function, since that is what the
compiler sees, when he is compiling the caller.

One would need at least a kind of 'calling convention' clause, to specify
such a call.




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andre Poenitz wrote:
>
> Marco Manfredini (marco@no-taris-spam.de) wrote:
> > In fact, GNU C++ already has such an extension to the language, which
> > doesn't need a new assignment operator. In an extra clause, you can define
> > the name of a return value:
> >
> > Foo f(void) return r; // yes with ';'
> >  {
> >     r.var1=0;
> >  }
>
> I always found this annoying.
>
> I believe the same effect could be reached if there was a special
> variable name that could be handled with extra care by the optimizer.
>
> Let's say, the special variable name is 'result', so one would write
>
>  Foo f(void)
>   {
>      Foo result;
>      result.var1=0;
>      return result;
>   }
>
> *as usual*. The compiler could check, whether result and the return
> type of f are the same, whether result is returned and whether nothing
> else is return. If any of these tests fail, it's business as usual.
> Otherwise, the variable could be removed by the optimizer.
>
> This way one would get the best of both worlds: No extension to the
> languange _and_ optimal code.

Indeed, the standard chose an even better option:
The compiler may optimize the above as stated _independent_
from the variable name. The rational is easy: If the compiler
can do the required checks if the variable is called result,
it can do them if it's called foo either.
This mechanism is called "named return value optimisation" (NRVO)
(note that g++'s extension was given the same name, since
it was invented before the standard used the name - a classic
naming conflict ;-))

I don't know which compilers implement the std::NRVO
(maybe even g++ supports std::NRVO besides gcc::NRVO now).


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

The purpose of this note is to propose an augmentation to the C++
syntax that would allow the efficient passing of return values
out of a called function or method.

The problem to be addressed is illustrated in the following example:

class Foo;
Foo f( void );

Foo x;
x = f();

The last statement probably involves the function f() constructing
a temporary Foo object, invoking the assigment operator and then
destructing the temporaty Foo object.  Naturally, the "heavier" the
Foo type, the more costly this is at run-time.

As a solution, I propose a Pascal-type option:

x := f();

The new ":=" token tells the compiler to make (the address of) x
accessible to the implementation of f().  I haven't found a definitive
way of doig this, so below I discuss an approach, which I do not
particularly endorse.

For example, inside the implementation of f(), a new keyword
"retval" can be a reference to an object of type Foo (in Pascal,
the function name, f, serves this purpose):

Foo f( void )
{
  retval.var1 = 0;
}

The assignment operator and temporary are elliminated.  The "return"
statement is not required.

This is like having an overloaded function

void f( Foo& retval )
{
  retval.var1 = 0;
}

which is a reasonable thing for a compiler to do, just as "this" is
passed as a hidden parameter to a non-static member function of a
class.  The value of the statement "x := f()" is the same as the value
of the statement "x = f()".

The same issue exists for initialization:

Foo x = f();

and probably involves the construction of a temporary object of
type Foo, copying of data vlues during the copy constructor, and
destruction of the temporary Foo object.

In this case,

Foo x := f();

again makes x available to the implementation of f(), but is
equiavalent to the two statemensts

Foo x;    // Default constructor
x := f(); // Assignment

first the default constructor will have been called on x,
in order not to pass raw memory to f().

Notes
-----

1. The advantage to using notation such as "x := y*z" instead
of product(x,y,z) is for the sake of readability.

2. If the programmer uses the statement

x = f();  // Rather than the := notation.

the compiler can replace this with:

Foo temp := f();
x = temp;

in order to maintain the semantics.  Perhaps issue a warning.

3. If the programmer writes

Foo temp := g();

but g() has not been defined using the "retval" syntax,
the compiler can replace this with:

Foo temp = g();

and issue a warning.

4. How is a compiler to know that the implementation of f() makes
use of the "retval" keyword?  It would be wrong to require this of
all functions.  The declaration of f() can be

retval Foo f( void );

which tells the compiler that the return value of f() must
be treated as a hidden (reference) parameter.

5. If the solution in 4, above, is used, then there is no need for
introducing the new token ':='; the usual '=' can be used.  However,
this would change the semantics of assignment and initialization when
"retval" functions are used, by avoiding the use of temporaries.  This
seems like a good idea, though.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <39730F79.C786FAF8@istar.ca>, Norman Goldstein
<normvcr@istar.ca> writes
>class Foo;
>Foo f( void );
>
>Foo x;
>x = f();
>
>The last statement probably involves the function f() constructing
>a temporary Foo object, invoking the assigment operator and then
>destructing the temporaty Foo object.  Naturally, the "heavier" the
>Foo type, the more costly this is at run-time.

The problem with this approach is if the ctor fails. Under current
circumstances the partially constructed object is destroyed, your
mechanism does not do this.  Some of us take great care to write copy
assignments so as to allow commit or rollback semantics.  Now in cases
such as the above, why do you not write:

Foo x(f());

Which I believe the compiler is at liberty to maximally optimise.



Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In fact, GNU C++ already has such an extension to the language, which
doesn't need a new assignment operator. In an extra clause, you can define
the name of a return value:

Foo f(void) return r; // yes with ';'
 {
    r.var1=0;
 }

no extra return statement neccesary, since it is implicit.
On invocation, r is an hidden parameter, that holds a reference to the place
that shall receive the return value.

The 'named return value' is of advantage, if
*) the default constructor is cheap
*) copying expensive

On the other hand, the constructor of your return value is called -before-
the function start - this could also be a drawback.

---
Marco



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Two previous postings, one about implementing copy construction
in terms of copy assignment, the other about virtual function calls
made from a constructor, got me thinking.

First, it was pointed out that one may implement copy assignment
in terms of copy construction (rather than vice-versa):

        X& X::operator=( const X& x ) {
          return swap( X(x) );
        }

where swap(x) exchanges the representation of *this with that of x
(I am deliberately avoiding templates for now).  This elegant idea
reuses two pieces of code (a constructor and destructor) compared
the more obvious approach.

In fact, one has only to rely on the assumption that the copy
constructor and the destructor _do the right thing_ and it is easy
to see that the compiler can always generate a copy-assignment
this way when the copy constructor and destructor are accessible.
If either is declared private we are out of luck but there was
presumably a good reason to prevent a copy and it makes sense,
therefore, to prohibit an assignment.

Unfortunately the method breaks down in other cases, particularly
when the class is abstract, due either to the fact that its
copy constructor might be protected or to the presence of pure
virtual functions:

        class X {
        public:
          virtual void f() = 0;
          ...
        };

One may use the following hijack device to get around the problem:

        struct X_ : public X {
          X_() { }
          X_( const X& x ) : X(x) { }
          void f();
        };

        void X::f() { }

        X& X::operator=( const X& x ) {
          return swap( X_(x) );
        }

Which (finally) brings me to my points:

[Apologies in advance if these ideas have been discusses before]

1. Maybe it should be allowed to instantiate temporaries
   of abstract classes, so that we wouldn't need the
   otherwise useless hijack class, and

2. This would provide a good reason to avoid calling a
   pure virtual from a constructor without explicit
   qualification.

--
John D. Hickin      Nortel Technology, Montreal, Quebec
(514) 765-7924   hickin@nortel.ca
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Some current compilers allocate memory for heap objects from inside
the constructor code.  This isn't great when exceptions can be thrown
and indeed generated code from compilers that support exception handling
seems to abandon the idea.

Does the standard say anything about how memory should be allocated?
My question is motivated by the following simple program which exhibits
different behavior when exception handling is enabled compared to when
it isn't.  Would such behavior be accptable inder the provisions of the
standard?

// -----------------------------------------------------------------

#include <stddef.h>

struct Y
{
  Y() {}
  void* allocate() { return 0; }
};

struct X
{
   X() {}
   void* operator new( size_t ) { return (void*)42; }
   void* operator new( size_t , Y& alloc ) { return alloc.allocate(); }
   void  operator delete( void* ) {}
   //void operator delete( size_t , Y& ); // not yet supported by my compiler
};


#include <iostream.h>

main()
{
  Y y;
  X* ptr = new(y) X;
  cout << "ptr == " << (int)ptr << "\n";
}

The output is 0 when exception handling is enabled and 42 when it isn't.


--
John Hickin      Bell-Northern Research, Montreal, Quebec
(514) 765-7924   hickin@bnr.ca
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

I wanted to implement the following:
  typedef coord3d<dword> cd3d;

and use it in a class with:
class yeah
{
  cd3d lv;
  ...
}
But g++ says:
  tst.cc:119: field `lv' has incomplete type

- if i use:
  #define cd3d coord3d<dword>

everything works fine. I only tested this with g++ 2.6.3.

What's up there? What means incomplete type?

Thx. for help.
Peter Breitling
--       ___________________   _____________________________________
        /                  /  /                                     \
        \  Peter Breitling \_/  breitlip@informatik.tu-muenchen.de  /
         \_____   http://www.informatik.tu-muenchen.de/  ->    ____/
              /    ->  cgi-bin/nph-gateway/hphalle8/~breitlip/ \
              \________________________________________________/

Hi,

I'm looking for a class library which provides classes for sequences,
collections, trees and so on.

Does anybody have an idea, where to get a library with that capabilities?

Ingo