a have posted my problem a view days ago, but i think it was not well
specified.
Let me describe my problem again.
I've got a project, which i should upgrade to a namespace functionality
and to compile it under the 4.x version.

I prepared every file with namespace namespacename { ...} and with it
the problem occurs, that the compiler warns the ostream endl method.

The endl method itself is overloaded with the option to write the output
to a file and/or to screen in the project.

the compile says following error message:

(compiler error 3.4)
g++-3.4  -I./Include -DABACUS_SYS_LINUX -DABACUS_COMPILER_GCC34 -Wall
-O3   -c sources/lp.cc -o tmp/linux20-gcc34/lp.o
sources/lp.cc: In function `std::ostream&
abacus::operator<<(std::ostream&, const abacus::ABA_LP&)':
sources/lp.cc:321: warning: the address of `abacus::ABA_OSTREAM&
abacus::endl(abacus::ABA_OSTREAM&)', will always evaluate as `true'
sources/lp.cc:323: warning: the address of `abacus::ABA_OSTREAM&
abacus::endl(abacus::ABA_OSTREAM&)', will always evaluate as `true'
sources/lp.cc:325: warning: the address of `abacus::ABA_OSTREAM&
abacus::endl(abacus::ABA_OSTREAM&)', will always evaluate as `true'

..............................................

(compiler error 4.1.2 )
g++-4.1  -I./Include -DABACUS_SYS_LINUX -DABACUS_COMPILER_GCC34 -Wall
-O3   -c sources/lp.cc -o tmp/linux20-gcc41/lp.o
./Include/abacus/array.h: In member function 'const
abacus::ABA_ARRAY<Type>& abacus::ABA_ARRAY<Type>::operator=(const
abacus::ABA_BUFFER<Type>&)':
./Include/abacus/array.h:401: error: no match for 'operator<<' in
'(((abacus::ABA_ARRAY<Type>*)this)->abacus::ABA_ARRAY<Type>::glob_->.abacus::ABA_GLOBAL::er
r() << "size of ABA_ARRAY too small.") << std::endl'
./Include/abacus/ostream.h:94: note: candidates are:
abacus::ABA_OSTREAM& abacus::ABA_OSTREAM::operator<<(char)
./Include/abacus/ostream.h:95: note:
abacus::ABA_OSTREAM& abacus::ABA_OSTREAM::operator<<(unsigned char)
./Include/abacus/ostream.h:96: note:
abacus::ABA_OSTREAM& abacus::ABA_OSTREAM::operator<<(signed char)
./Include/abacus/ostream.h:97: note:
abacus::ABA_OSTREAM& abacus::ABA_OSTREAM::operator<<(short int)
./Include/abacus/ostream.h:98: note:
abacus::ABA_OSTREAM& abacus::ABA_OSTREAM::operator<<(short unsigned int)

...................................................................

It looks like every call of endl in any overloading function will be
warned by compiler V3.4.
The hint to address endl explicit with std::endl is a nasty solution in
my eyes, but leads to success under V3.4.

Under the new compiler every endl-method at any place will be marked as
error (like above error message), even with std::endl!!

For the 4.1 Version i tried ABA_OSTREAM::endl but same error- message:

error: no match for 'operator<<' in (...) << abacus::ABA_OSTREAM::endl'
./Include/abacus/ostream.h:94: note: candidates are:
abacus::ABA_OSTREAM& abacus::ABA_OSTREAM::operator<<(char)
...

I really hope, that anyone can help me

Thanks a lot.

Mark

In addition: Hear i post an excerpt of headerfile and sourcefile from my
ostream class and the corresponding array.h file.

headerfile:
......................

#ifndef ABA_OSTREAM_H
#define ABA_OSTREAM_H
#include <iostream>
#include <fstream>
using namespace std;
#include "abacus/abacusroot.h"
namespace abacus {
...
class ABA_OSTREAM;
typedef ABA_OSTREAM&(*ABA_OSTREAM_MANIP)(ABA_OSTREAM&);  

class  ABA_OSTREAM:public ostream,public ABA_ABACUSROOT{
    public:
      ABA_OSTREAM(ostream &out, const char *logStreamName = 0);

      ~ABA_OSTREAM();
      ABA_OSTREAM&operator<<(char o);
      ABA_OSTREAM&operator<<(const ABA_LPVARSTAT &o);
      ABA_OSTREAM&operator<<(const ABA_CSENSE &o);
      ABA_OSTREAM&operator<<(const ABA_LP &o);
 //here comes more.............
      ofstream* log() const;
      friend ABA_OSTREAM& flush(ABA_OSTREAM &o);
      friend ABA_OSTREAM& endl(ABA_OSTREAM &o);

    private:

      ostream  &out_;

      bool      on_;
      bool      logOn_;
      ofstream *log_;
  };

} // End of Namespace
#endif // ABA_OSTREAM_H

sourcefile:
.................................
#include "abacus/ostream.h"
#include "abacus/string.h"
#include "abacus/history.h"
...

namespace abacus{
..
  ABA_OSTREAM& flush(ABA_OSTREAM &o)
  {
    if (o.on_) o.out_ << flush;
    if(o.logOn_) *(o.log_) << flush;
    return o;
  }

  ABA_OSTREAM& endl(ABA_OSTREAM &o)
  {
    o << '\n';
    if (o.on_) o.out_ << flush;
    if(o.logOn_) *(o.log_) << flush;
    return o;
  }

} // End of Namespace

array.h
............

#ifndef ABA_ARRAY_H
#define ABA_ARRAY_H
#include <iostream>
using namespace std;

#include "abacus/global.h"
#include "abacus/buffer.h"

namespace abacus {

#ifdef ABACUS_NEW_TEMPLATE_SYNTAX
template<class Type> 
class  ABA_ARRAY;
template<class Type> 
ostream& operator<< (ostream& out, const ABA_ARRAY<Type> &array);
#endif

  template <class Type> class  ABA_ARRAY : public ABA_ABACUSROOT  {
    public:

      ABA_ARRAY(ABA_GLOBAL *glob, int size);
      ABA_ARRAY(ABA_GLOBAL *glob, int size, Type init);
      ABA_ARRAY(ABA_GLOBAL *glob, const ABA_BUFFER<Type> &buf);

      ABA_ARRAY(const ABA_ARRAY<Type> &rhs);

      ~ABA_ARRAY();
      const ABA_ARRAY<Type>& operator=(const ABA_ARRAY<Type>& rhs);
      const ABA_ARRAY<Type>& operator=(const ABA_BUFFER<Type>& rhs);

      friend ostream& operator<< (ostream& out, const ABA_ARRAY<Type>
&array);

      Type& operator[](int i);

      const Type& operator[](int i) const;
...
    private:

      ABA_GLOBAL *glob_;
      int         n_;
...
  };

template <class Type> 
  inline ABA_ARRAY<Type>::ABA_ARRAY(ABA_GLOBAL *glob, int size)
    : 
    glob_(glob),  
    n_(size)
  {
#ifdef ABACUSSAFE
    if (size < 0) {
      glob_->err() << "ABA_ARRAY::ABA_ARRAY(): cannot construct array
with negative size" << endl;
      exit(Fatal);
    }
#endif  
    a_ = new Type[size];
}

..
 template <class Type>
 const ABA_ARRAY<Type>& ABA_ARRAY<Type>::operator=(const
ABA_ARRAY<Type>& rhs)
 {
 if (this == &rhs) return *this;
  if (n_ != rhs.n_) {
     glob_->err() << "ABA_ARRAY::operator= : dimensions of left and
right hand side ";
     glob_->err() << "are different (" << n_ << " != " << rhs.n_ << ")"
<< endl;
     exit(Fatal);
     }

 glob_ = rhs.glob_;
 n_    = rhs.n_;

 for (int i = 0; i < n_; i++) a_[i] = rhs[i];

 return *this;
 }

template <class Type>
  const ABA_ARRAY<Type>& ABA_ARRAY<Type>::operator=(const
ABA_BUFFER<Type>& rhs)
  {
    if (n_ < rhs.size()) {
      glob_->err() << "ABA_ARRAY::operator=(const
ABA_BUFFER&):"<<endl; //OR ????-> ABA_OSTREAM::endl;
      glob_->err() << "size of ABA_ARRAY too small."<<endl;
      exit(Fatal);
    }

    const int rhsNumber = rhs.number();

    for (int i = 0; i < rhsNumber; i++) a_[i] = rhs[i];

    return *this;

  }

  template <class Type>
  ostream& operator<<(ostream &out, const ABA_ARRAY<Type> &array)
  {
    const int s = array.size();

    for (int i = 0; i < s; i++) out << i << ": " << array[i] << endl;
    return out;
  }

} // End of Namespace
#endif  // !ABA_ARRAY_H

area2051 schrieb:

......

headerfile:
...
using namespace std;
...

array.h
...
using namespace std;
...

This ist a bad idea !
Especially when you want to redefine std-Symbols in your own namespace.

Greetz,

Simon2.

Probably not the solution, but my first observation:

area2051 schrieb:

......

headerfile:
...
using namespace std;
...

array.h
...
using namespace std;
...

This ist a bad idea !
Especially when you want to redefine std-Symbols in your own namespace.

Greetz,

Simon2.

Hello Simon,

first of all thank's for your post.
I already thougth about namespace std.
But there are many files at this project using this phrase and including other files which use using std itself again, and an removing all of them wasn't still successful at the end. :-((

Greets

Mark

you obviously got stuck in this "namespace solution hell" (hence this thread)... and this "using namespace std in header files" pulls the heat throttle to maximum.

I don't suggest to remove all of the using-clauses - but those in the header. I thought, you wanted to implement an alternative to the std-features ... why force anybody that uses YOUR versions to also "see" the std-Versions ?
That increases the risk of ambiguity errors significantly - imagine, your user uses

using namespace abacus;

Greetz,

Simon2.

Hi,

you obviously got stuck in this "namespace solution hell" (hence this thread)... and this "using namespace std in header files" pulls the heat throttle to maximum.

I don't suggest to remove all of the using-clauses - but those in the header. I thought, you wanted to implement an alternative to the std-features ... why force anybody that uses YOUR versions to also "see" the std-Versions ?
That increases the risk of ambiguity errors significantly - imagine, your user uses

using namespace abacus;

Greetz,

Simon2.

hey everyone,

thanks for comments again.
I tried it out, wrote a one-liner that comment out every using namespace std.
But now it's clear, that endl is not recognized by default "endl".
But with ABA_OSTREAM::endl:

g++-3.4  -I./Include -DABACUS_SYS_LINUX -DABACUS_COMPILER_GCC34 -Wall   -O3   -c sources/lp.cc -o tmp/linux20-gcc34/lp.o
In file included from ./Include/abacus/global.h:61,
                 from ./Include/abacus/master.h:55,
                 from sources/lp.cc:38:
./Include/abacus/hash.h: In function `std::ostream& abacus::operator<<(std::ostream&, const abacus::ABA_HASH<KeyType, ItemType>&)':
./Include/abacus/hash.h:461: error: no match for 'operator<<' in 'out << abacus::ABA_OSTREAM::endl'
/usr/include/c++/3.4/bits/ostream.tcc:63: note: candidates are: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ostream<_CharT, _Traits>&(*)(std::basic_ostre
am<_CharT, _Traits>&)) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/include/c++/3.4/bits/ostream.tcc:74: note:                 std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ios<_CharT, _Traits>&(*)(std::basic_ios<_Char
T, _Traits>&)) [with _CharT = char, _Traits = std::char_traits<char>]

same procedure as last E-message

any other ideas?

using namespace std;

from your header files, you'll also have to prepend every single symbol out of the standard namespace in the header with "std::".

e.g.

former foo.h:

using namespace std;

string bar;

new foo.h:
std::string bar;

greetz, Swordfish

former foo.h:

using namespace std;

string bar;

new foo.h:
std::string bar;

greetz, Swordfish

Even when i overload the endl method?
Like the code posted above there exists an endl in ostream.h ! ??

when i explicit write std::endl - which endl does the compiler use? my overload endl, or the really std::endl?

Greets

Mark

greetz, Swordfish

If you want to use the Standard endl, use 'std::endl' if you use your own or one contained by a library you're using, you have to know if it is a global symbol or part of a spezific namespace.

greetz, Swordfish

Hey Swordfish,

i think - that is the origin of my problem.
but how can use my own endl in an specific (same) namespace?
e.g. i'v got a class like

namespace abacus {

template<class KeyType,class ItemType> class ABA_HASH;
template <class KeyType, class ItemType>
std::ostream &operator<< (std::ostream &out, const ABA_HASH<KeyType, ItemType> &hash);

 template <class KeyType, class ItemType>
  class  ABA_HASH :  public ABA_ABACUSROOT  { 
    public:
      ABA_HASH(ABA_GLOBAL *glob, int size);
      ~ABA_HASH();
      friend std::ostream &operator<< (std::ostream &out, 
                                     const ABA_HASH<KeyType, ItemType> &hash);
        };

template <class KeyType, class ItemType>
  std::ostream &operator<<(std::ostream &out, const ABA_HASH<KeyType, ItemType> &hash)
  {

    //DO SOMETHING 
        out << endl;
      }  
    }  
    return out;
  }
} // End of Namespace

and the endl should be the abacus::endl;

Greets
Mark

...
but how can use my own endl in an specific (same) namespace?...

Just say it:

area2051 schrieb:

...

...
template <class KeyType, class ItemType>
  std::ostream &operator<<(std::ostream &out, const ABA_HASH<KeyType, ItemType> &hash)
  {

    //DO SOMETHING 
        out << abacus::endl;
      }  
    }  
    return out;
  }
} // End of Namespace

Bye,

Simon2.

Sorry, I seem to be a little blind now, but where do you declare the abacus::endl, I can't see it anywhere in your code.

i feel the same, but it's written in the middle part.
Here again:

sourcefile:
.................................
#include "abacus/ostream.h"
#include "abacus/string.h"
#include "abacus/history.h"
...

namespace abacus{
..
  ABA_OSTREAM& flush(ABA_OSTREAM &o)
  {
    if (o.on_) o.out_ << flush;
    if(o.logOn_) *(o.log_) << flush;
    return o;
  }

  ABA_OSTREAM& endl(ABA_OSTREAM &o)
  {
    o << '\n';
    if (o.on_) o.out_ << flush;
    if(o.logOn_) *(o.log_) << flush;
    return o;
  }

} // End of Namespace

maybe the endl overload is written the wrong way?

Hi!

1. It _might_ be a good idea to derive from std but I'd always prefer to aggregate.
2. There are a lot of assuptions in this thread about the namespace of a certain expression. On th eother hand you _are_ deploying namespaces.
   So what's the point in _not_ decriminating exactly by using

std::endl

?
Often ( e.g in CORBA Implementaiotns or in the the STL itself ) namepsaces beak up the normal "flow" of reading code.
But here these 5(!) characters 'std::' just make things clearer and more easy to read.

The actual error is quite a simple one:
This is waht gcc conplaints \1:

out << abacus::ABA_OSTREAM::endl

Thst means, there's no
(*)

abacus::ABA_OSTREAM::endl(std::ostream&)

And there _is_ none,instead a

friend ABA_OSTREAM& endl(ABA_OSTREAM &o);

which he cannot use. ( Btw the "friend" keyword is obsolete. )
The compiler can _downcast_ to an ancestor but never _upcast_ to a descendent!

Regards

Gast++

*( Why and how this comes is tricky !
Pls read
Bjarne Stroustroup
"The C++ Programmiersprache"
4.Auflage Addison Wesley 2000

§21.4.6 )

Gast++ schrieb:

The actual error is quite a simple one:
This is waht gcc conplaints \1:

out << abacus::ABA_OSTREAM::endl

Thst means, there's no
(*)

abacus::ABA_OSTREAM::endl(std::ostream&)

And there _is_ none,instead a

friend ABA_OSTREAM& endl(ABA_OSTREAM &o);

which he cannot use. ( Btw the "friend" keyword is obsolete. )

and what do you thing, the correct phrase should be ?

Gast++ schrieb:

The compiler can _downcast_ to an ancestor but never _upcast_ to a descendent!

so i think it's still a downcast, isn't it?

as time goes by, i'm really getting sick

Mark

Greets
Mark

basic_ostream<charT,traits>& ()(basic_ostream<charT,traits>&) // or
basic_ios<charT,traits>& ()(basic_ios<charT,traits>&) // or
ios_base& ()(ios_base&)

your function

ABA_OSTREAM& endl(ABA_OSTREAM &o)

doesn't match either signature and thus requires its own overload of operator<<
In addition, since you have declared your own overloads of << within your class, all overloads inherited from basic_ostream are being hidden (not those declared as free function though - and this mess is one of the reasons to stick with one method of overloading) - so even using std::endl will not find a suitable overload of operator << to call. You could use a using declaration to make those overloads visible, but it might interfere with the overloads you already have.
Either way, probably the best solution is to introduce proper overloads of << for stream manipulators. like

class  ABA_OSTREAM:public ostream,public ABA_ABACUSROOT{
/* ... */
    ABA_OSTREAM& operator<<(ostream& (*pf)(ostream&)) { pf( *this ); return *this; }
    ABA_OSTREAM& operator<<(ios& (*pf)(ios&)) { pf( *this ); return *this; }
    ABA_OSTREAM& operator<<(ios_base& (*pf)(ios&)) { pf( *this ); return *this; }
    ABA_OSTREAM& operator<<(ABA_OSTREAM& (*pf)(ABA_OSTREAM&)) { return pf( *this ); }
/* ... */
  };

By the way,
i think, the problem is independent from namespace!
Because when i compile it without namespace, the same error -mesage occurs.

Greets
Mark

I don't intend to enter a C++-style discussion with you.
Not really; it seems you don't even know the basics.

Many postings told you to be careful about namespaces, Stroustoup tells us so na dou are yet still stuck with your problem but refuse to improve code readabillity...

It's your problem if you can't read y<ou own code, not mine, you're aware of that? The compiler van read even the worst code, that's no measure.

Best Regards

Gast++

P.S.: I told you where the probelm actually is, and camper showed you a soulution - do you really think it's appropriate to start coding a fundamental library this way?

Gast++ schrieb:

I don't intend to enter a C++-style discussion with you.
Not really; it seems you don't even know the basics.

I think you are right. I don't know these "basics", this was my first big project, in which i was thrown in. And my backround is indeed not so clear as you may think.

Gast++ schrieb:

It's your problem if you can't read y<ou own code, not mine, you're aware of that? The compiler van read even the worst code, that's no measure.

It's really hard to understand if it's ironic or not, but i was always been friendly and your aren't liable to my problem.

Gast++ schrieb:

P.S.: I told you where the probelm actually is, and camper showed you a soulution - do you really think it's appropriate to start coding a fundamental library this way?

so i worked this mornig at these problem and a really have to say thankyou to you (gast++) and to camper. In my eyes i think it's a little bit difficulter to do deal with that kind of problem on a project, i've taken over, as to write an own prog and maintain itself, isn't it?

So i'm really glad that I found some big helper.

greetings
Mark