namespace/endl/ gcc 3.4 and 4.1.2

Shinja

You should remove them of the Headerfiles. Otherwise you open the namespace std for each and every file in which your header is included, which is probably not what you want.

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.

area2051

Simon2 schrieb:

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?

Swordfish

If you remove every

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

Swordfish schrieb:

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

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

area2051

Swordfish schrieb:

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

Shinja

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.

Simon2

area2051 schrieb:

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

Shinja schrieb:

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

area2051

maybe the endl overload is written the wrong way?

area2051 schrieb:

maybe the endl overload is written the wrong way?

Hi!

It _might_ be a good idea to derive from std but I'd always prefer to aggregate.
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 )

area2051

Hey Gast

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

area2051

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

camper

To be recognized as an standard basic_ostream manipulator, a funtion needs to have a specific signature, that is:

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 ); }
/* ... */
  };

Gast++

area2051 schrieb:

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?

area2051

Hello to everyone,

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

never read Stroustroup but i guess it'll look similar to this method avoiding the nasty friend functions:
http://tutorial.schornboeck.net/operatoren_ueberladung2.htm
you dont have to understand the german text, just look the code. the operator overload works nice although there is no friend function at all but .