where to declare a friend operator >> (as well as >>)... in .h or.cpp file

[puzzlecracker]

Say we have this structure:

Struct Foo{
....
friend ostream& operator << (ostream& s, Foo & m);
.....
};

friend ostream& operator << (ostream& s, Foo & m){

//access and print
}
I had a multiple inclusion issue when I placed the definition of
operator << in .h file despite include guards. So, I eventually moved
it to Foo.cpp class.

What is the suggested design ?
Thanks

[puzzlecracker]

If you place a function definition in a header file use the word 'inline',
unless it's defined within a class definition.

Umm, why inline is necessary in my case?

I only defined once in only one .h file, which obviously has include
guards. However, I have many other files, in the same project, that
include this .h file.

[puzzlecracker]

On Sep 7, 7:18 pm, "Alf P. Steinbach" <[e-mail]:

* puzzlecracker:

If you place a function definition in a header file use the word 'inline',
unless it's defined within a class definition.

Umm, why inline is necessary in my case?

I only defined once in only one .h file, which obviously has include
guards. However, I have many other files, in the same project, that
include this .h file.

The include guard only prevents multiple includes in each compilation unit.

When you have multiple compilation units you have one (effective) include in each.

Thus one definition in each.

And when you have multiple definitions you need 'inline'.

Argh, got it, I like this subtle

Except if it's a template.

What is the rule with template in regard to putting the template
function in .h file.

Another question: what is the best design for opereraton<< design?

ty

[mqrk]

On Sep 7, 4:42 pm, puzzlecracker <[e-mail]:

What is the rule with template in regard to putting the template
function in .h file?

I think you have to put a template function in a .h file if you plan
to use it in multiple compilation units. I've never heard of a system
that could handle template instantiation at link-time, though I heard
that Microsoft handles inline functions at link-time now, so maybe
template functions too? On the other hand, such code wouldn't be
portable so you probably don't want to use the feature even if it does
exist.

Another question: what is the best design for opereraton<< design?

I don't know. Here's what I do:

class A
{
public:
virtual std::ostream& operator>>(std::ostream& o) const { return o <<
"A's data";}
};
 
std::ostream& operator<<( std::ostream& o, const A& a)
{
return a > o;
}
 

[James Kanze]

On Sep 8, 6:16 am, mqrk <[e-mail]:

On Sep 7, 4:42 pm, puzzlecracker <[e-mail]>
wrote:What is the rule with template in regard to putting
the template

function in .h file?

I think you have to put a template function in a .h file if
you plan to use it in multiple compilation units. I've never
heard of a system that could handle template instantiation at
link-time,

Sun CC. Comeau C++.

Probably most Unix compilers, for that matter, except g++.
Traditionally, templates were instantiated at link time, and
most Unix vendor compilers try to support this, for reasons of
backwards compatibility, if for nothing else.

What is special is that you *can* put template and inline
functions in a header file, without incuring an error.

though I heard that Microsoft handles inline functions at
link-time now, so maybe template functions too? On the other
hand, such code wouldn't be portable so you probably don't
want to use the feature even if it does exist.

Another question: what is the best design for opereraton<< design?

I don't know. Here's what I do:

class A
{
public:
virtual std::ostream& operator>>(std::ostream& o) const { return o <<
"A's data";}
};

 
        
                std::ostream& operator<<( std::ostream& o, const A& a)
{
return a > o;}
 
 
 
        
 
 
 
 

Help. That's really confusing. I usually provide a normal,
named member function print, and derive from a template class
using the Barton and Nackman trick to provide the operators, but
otherwise, there's no problem with using a friend, as long as
you define it in a normal source file, and not in the header.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[puzzlecracker]

I usually provide a normal,

named member function print, and derive from a template class
using the Barton and Nackman trick to provide the operators, but

Please elaborate on this:the Barton and Nackman trick

[James Kanze]

On Sep 8, 3:26 pm, puzzlecracker <[e-mail]:

I usually provide a normal,

named member function print, and derive from a template
class using the Barton and Nackman trick to provide the
operators, but

Please elaborate on this:the Barton and Nackman trick

It's pretty straight-forward, really. The base class contains
an inline definition of the operator---declared as friend,
because that's the only way you can provide an implementation
inline in a class for a non-member function. It's not really
something fundamentally necessary for operator<< and >>; it's
more useful for things like an operator+ (based on +=), etc.
Anyway, you define a base class template along the lines of:

template< typename T >
class Operators
{
friend T operator+( T const& lhs, T const& rhs )
{
T result( lhs ) ;
result += rhs ;
return result ;
}
// ...
friend std::ostream& operator<<(
std::ostream const& dest,
T const& obj )
{
obj.print( dest ) ;
return dest ;
}
// ...
} ;

Then, whenever you need the operators, just derive from the
class:

class Whatever : public Operators< Whatever >
{
public :
// ...
Whatever& operator+=( Whatever const& other ) ;
// ...
void print( std::ostream& dest ) const ;
// ...
} ;

I actually have several different template base classes for
this: ArithmeticOperators, MixedArithmeticOperators (with two
template parameters, for mixed type arithmetic),
STLIteratorOpertors (converts a "normal" iterator into STL), and
IOStreamOperators.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]