Which ELF platforms support visibility attribute?

Which ELF platforms support visibility attribute?

[Jonathan Turkanis]

Hi all,

The 4.0.1 manual states that not all ELF targets support the visibility 
attribute. (See http://tinyurl.com/dov3l.) Does anyone know which targets do 
support the attribute?

Best Regards,
Jonathan

Problem with class operators.

[Kristian Kratzenstein]

Hi All,

I've a problem with class operators. In this case (I try to cut this down)
my class, which holds a string.
I'm working on XCode.

	bool CkString::operator == (char const* string);

	CkString::operator char*();

Now I try :

	b = (ckstring == pchar);

now I get an Error :  

	error : ISO C++ says that these are ambiguous, even the worst
conversation for the first is better than the worst conversation for the
second
	note : candidate 1: bool CkString::operator==(const char*)
	note : candidate 2: operator==(char*, char*) <built-in>

thanks for help,

Kristian

--------------------------------------------
Kristian Kratzenstein
Gettorf

Kristian.Kratzenstein@KielNET.net
--------------------------------------------

Re: Problem with class operators.

[Eljay Love-Jensen]

Hi Kristian,

When you have an ambiguous situation like that, you could try this:

b = (ckstring.operator == (pchar));

Or you could remove the implicit convenience cast (operator char*), to
something like this, like was done with std::string for the same reason:

char* CkString::c_str();

HTH,
--Eljay

Re: Problem with class operators.

[Kristian Kratzenstein]

Hi Eljay,

thanks, I thought so. I saw in MFC, that this stuff works for the CString
class (with LPSTR, what comes to char* after several "show define"). I
think great, if you like to use the object directly in functions, which
want an char*. But seem to be VS special stuff (CW couldn't handle this
too).

kind regards,

Kristian

Eljay Love-Jensen <eljay@adobe.com> on Montag, 25. Juli 2005 at 13:44
+0100 wrote:
>Hi Kristian,
>
>When you have an ambiguous situation like that, you could try this:
>
>b = (ckstring.operator == (pchar));
>
>Or you could remove the implicit convenience cast (operator char*), to
>something like this, like was done with std::string for the same reason:
>
>char* CkString::c_str();
>
>HTH,
>--Eljay
>
>
>



--------------------------------------------
Kristian Kratzenstein
Gettorf

Kristian.Kratzenstein@KielNET.net
--------------------------------------------

Re: Problem with class operators.

[Kristian Kratzenstein]

Hi all (again),

Xcode again. Seem like gcc optimize methods away, which are needed by code
in another file. This means, I get Link errors.

I ll try to discribe this as good as I could without the whole code :

File1.h
	template <class t>
	class a
	{
		...
		virtual bool isBig();
	}

File1.cpp
	template<class t>
	bool a<t>::isBig()
	{
		return false;
	}

	dummyfunctionfora()
	{
		a<char>	aA;
		bool		b;

		b = aA.isBig;
	}

File2.cpp
	#include "File1.h"

	...
	b = aA.isBig();
	...

What I did : template class a is defined in File1, and only be used by a
dummy function, which is not called. ( I try this that the compiler
generates the needed code). This runs fine with CW and VS. But with gcc
(xcode 2.1) this could lead into a link error.

How could I solve this ? Is there any smarter way to make sure the
template class is compiled for the types I want ? Is there a way to stop
gcc from optimize my methods away ? The normal (xcode for gcc) setting for
Optimizing I tried (different counts of link error, but never none).

Thanks,

Kristian Kratzenstein


--------------------------------------------
Kristian Kratzenstein
Gettorf

Kristian.Kratzenstein@KielNET.net
--------------------------------------------

Re: Problem with class operators.

[Eljay Love-Jensen]

Hi Kristian,

Non-specialized template functions and methods need to be defined in the
header file which declares them.

Otherwise they are only visible to the translation unit in which they are
defined.

HTH,
--Eljay

Re: Problem with class operators.

[corey taylor]

Kristian,

  Are you sure that is the setup that compiles?  You need to pull
those templated functions out of the source file and into a header
file.

corey

On 7/25/05, Kristian Kratzenstein <kristian.kratzenstein@kielnet.net> wrote:
> Hi all (again),
> 
> Xcode again. Seem like gcc optimize methods away, which are needed by code
> in another file. This means, I get Link errors.
> 
> I ll try to discribe this as good as I could without the whole code :
> 
> File1.h
>         template <class t>
>         class a
>         {
>                 ...
>                 virtual bool isBig();
>         }
> 
> File1.cpp
>         template<class t>
>         bool a<t>::isBig()
>         {
>                 return false;
>         }
> 
>         dummyfunctionfora()
>         {
>                 a<char> aA;
>                 bool            b;
> 
>                 b = aA.isBig;
>         }
> 
> File2.cpp
>         #include "File1.h"
> 
>         ...
>         b = aA.isBig();
>         ...
> 
> What I did : template class a is defined in File1, and only be used by a
> dummy function, which is not called. ( I try this that the compiler
> generates the needed code). This runs fine with CW and VS. But with gcc
> (xcode 2.1) this could lead into a link error.
> 
> How could I solve this ? Is there any smarter way to make sure the
> template class is compiled for the types I want ? Is there a way to stop
> gcc from optimize my methods away ? The normal (xcode for gcc) setting for
> Optimizing I tried (different counts of link error, but never none).
> 
> Thanks,
> 
> Kristian Kratzenstein
> 
> 
> --------------------------------------------
> Kristian Kratzenstein
> Gettorf
> 
> Kristian.Kratzenstein@KielNET.net
> --------------------------------------------
> 
> 
>

Re: Problem with class operators.

[Kristian Kratzenstein]

Hi Eljay,

Nearly as I thought. But : When the template method / function is used in
the related cpp file, then the Linker could link from other files to the
same function (with same type).
Therefor I use a dummyfunction.

The problem now is, that CW and VC preserve the methods during compiling.
gcc now optimize them away (small, like GetBuffer or so), so they run in
the file, but cannot be linked. 

So, is there a way to get those methods preserved, so I could link to them
?

I know, the best is : into the Headers. But I made template classes
(some), which are based on each other. Cause the size, I would like to
have them in cpp / h file. Also this looks more clean.

Kind regards

Eljay Love-Jensen <eljay@adobe.com> on Montag, 25. Juli 2005 at 17:32
+0100 wrote:
>Hi Kristian,
>
>Non-specialized template functions and methods need to be defined in the
>header file which declares them.
>
>Otherwise they are only visible to the translation unit in which they are
>defined.
>
>HTH,
>--Eljay
>
>
>



--------------------------------------------
Kristian Kratzenstein
Gettorf

Kristian.Kratzenstein@KielNET.net
--------------------------------------------

Re: Problem with class operators.

[Eljay Love-Jensen]

Hi Kristian,

> So, is there a way to get those methods preserved, so I could link to them
> ?

Not to my knowledge.  I presume that those methods ARE preserved, but that
they are internal linkage only.

HTH,
--Eljay

Re: Problem with class operators.

[corey taylor]

Kristian,

  Are you asking if there is a way for the compiler to make note of an
internal linkage and instantiation in one file and translate that to
another file?

  I think that you'll find scoping rules will limit this.  The
declaration and sometimes definition needs to be visible at the time
of instantiation.

  A basic example is section 14.7 paragraph 6 of the specification:

If an implicit instantiation of a class template specialization is
required and the template is declared but not
defined, the program is ill-formed. 

[Example:
template<class T> class X;

X<char> ch; // error: definition of X required
—end example]

Paragraph 3 gives examples for required method instantiations.

corey

On 7/25/05, Kristian Kratzenstein <kristian.kratzenstein@kielnet.net> wrote:
> Hi Eljay,
> 
> Nearly as I thought. But : When the template method / function is used in
> the related cpp file, then the Linker could link from other files to the
> same function (with same type).
> Therefor I use a dummyfunction.
> 
> The problem now is, that CW and VC preserve the methods during compiling.
> gcc now optimize them away (small, like GetBuffer or so), so they run in
> the file, but cannot be linked.
> 
> So, is there a way to get those methods preserved, so I could link to them
> ?
> 
> I know, the best is : into the Headers. But I made template classes
> (some), which are based on each other. Cause the size, I would like to
> have them in cpp / h file. Also this looks more clean.
> 
> Kind regards
> 
> Eljay Love-Jensen <eljay@adobe.com> on Montag, 25. Juli 2005 at 17:32
> +0100 wrote:
> >Hi Kristian,
> >
> >Non-specialized template functions and methods need to be defined in the
> >header file which declares them.
> >
> >Otherwise they are only visible to the translation unit in which they are
> >defined.
> >
> >HTH,
> >--Eljay
> >
> >
> >
> 
> 
> 
> --------------------------------------------
> Kristian Kratzenstein
> Gettorf
> 
> Kristian.Kratzenstein@KielNET.net
> --------------------------------------------
> 
> 
>

Re: Problem with class operators.

[Kristian Kratzenstein]

Corey, Eljay,

This kind works also with gcc, but not with small methods (CW and VC could
handle small methods too).

meanwhile : I declare the class fully

template<class T>
class x
{
public:
	x();
	~x();
....
}

before using them, so I'm allowed to use x<char> ch.

But the methods are defined in the cpp file. And now came the compiler /
linker problem.
bigger methods (4 lines or more) are fine. Gcc compile them, and I could
link to them also from other files, cause gcc doesn't use any kind of
inline to optimize them away. They are preserved. But smaller are gone,
gcc put them into the code (inline). So I could not link to them.

What is now my conclusion : put small methods into the class decleration.
But this looks dirty (sorry, but I try to hold my code clean). Is no other
way, to stop gcc to inline small methods ?

thanks,

Kristian

corey taylor <corey.taylor@gmail.com> on Montag, 25. Juli 2005 at 20:13
+0100 wrote:
>Kristian,
>
>  Are you asking if there is a way for the compiler to make note of an
>internal linkage and instantiation in one file and translate that to
>another file?
>
>  I think that you'll find scoping rules will limit this.  The
>declaration and sometimes definition needs to be visible at the time
>of instantiation.
>
>  A basic example is section 14.7 paragraph 6 of the specification:
>
>If an implicit instantiation of a class template specialization is
>required and the template is declared but not
>defined, the program is ill-formed. 
>
>[Example:
>template<class T> class X;
>
>X<char> ch; // error: definition of X required
>—end example]
>
>Paragraph 3 gives examples for required method instantiations.
>
>corey
>
>On 7/25/05, Kristian Kratzenstein <kristian.kratzenstein@kielnet.net>
>wrote:
>> Hi Eljay,
>> 
>> Nearly as I thought. But : When the template method / function is used
>in
>> the related cpp file, then the Linker could link from other files to the
>> same function (with same type).
>> Therefor I use a dummyfunction.
>> 
>> The problem now is, that CW and VC preserve the methods during
>compiling.
>> gcc now optimize them away (small, like GetBuffer or so), so they run in
>> the file, but cannot be linked.
>> 
>> So, is there a way to get those methods preserved, so I could link to
>them
>> ?
>> 
>> I know, the best is : into the Headers. But I made template classes
>> (some), which are based on each other. Cause the size, I would like to
>> have them in cpp / h file. Also this looks more clean.
>> 
>> Kind regards
>> 
>> Eljay Love-Jensen <eljay@adobe.com> on Montag, 25. Juli 2005 at 17:32
>> +0100 wrote:
>> >Hi Kristian,
>> >
>> >Non-specialized template functions and methods need to be defined in
>the
>> >header file which declares them.
>> >
>> >Otherwise they are only visible to the translation unit in which they
>are
>> >defined.
>> >
>> >HTH,
>> >--Eljay
>> >
>> >
>> >
>> 
>> 
>> 
>> --------------------------------------------
>> Kristian Kratzenstein
>> Gettorf
>> 
>> Kristian.Kratzenstein@KielNET.net
>> --------------------------------------------
>> 
>> 
>>
>>


--------------------------------------------
Kristian Kratzenstein
Gettorf

Kristian.Kratzenstein@KielNET.net
--------------------------------------------

Re: Problem with class operators.

[corey taylor]

I don't know.  I always put my templated definitions in the header
file. MSVC++ usually errors on other uses also, I'm surprised these
work.

corey

On 7/25/05, Kristian Kratzenstein <kristian.kratzenstein@kielnet.net> wrote:
> Corey, Eljay,
> 
> This kind works also with gcc, but not with small methods (CW and VC could
> handle small methods too).
> 
> meanwhile : I declare the class fully
> 
> template<class T>
> class x
> {
> public:
>         x();
>         ~x();
> ....
> }
> 
> before using them, so I'm allowed to use x<char> ch.
> 
> But the methods are defined in the cpp file. And now came the compiler /
> linker problem.
> bigger methods (4 lines or more) are fine. Gcc compile them, and I could
> link to them also from other files, cause gcc doesn't use any kind of
> inline to optimize them away. They are preserved. But smaller are gone,
> gcc put them into the code (inline). So I could not link to them.
> 
> What is now my conclusion : put small methods into the class decleration.
> But this looks dirty (sorry, but I try to hold my code clean). Is no other
> way, to stop gcc to inline small methods ?
> 
> thanks,
> 
> Kristian
> 
> corey taylor <corey.taylor@gmail.com> on Montag, 25. Juli 2005 at 20:13
> +0100 wrote:
> >Kristian,
> >
> >  Are you asking if there is a way for the compiler to make note of an
> >internal linkage and instantiation in one file and translate that to
> >another file?
> >
> >  I think that you'll find scoping rules will limit this.  The
> >declaration and sometimes definition needs to be visible at the time
> >of instantiation.
> >
> >  A basic example is section 14.7 paragraph 6 of the specification:
> >
> >If an implicit instantiation of a class template specialization is
> >required and the template is declared but not
> >defined, the program is ill-formed.
> >
> >[Example:
> >template<class T> class X;
> >
> >X<char> ch; // error: definition of X required
> >—end example]
> >
> >Paragraph 3 gives examples for required method instantiations.
> >
> >corey
> >
> >On 7/25/05, Kristian Kratzenstein <kristian.kratzenstein@kielnet.net>
> >wrote:
> >> Hi Eljay,
> >>
> >> Nearly as I thought. But : When the template method / function is used
> >in
> >> the related cpp file, then the Linker could link from other files to the
> >> same function (with same type).
> >> Therefor I use a dummyfunction.
> >>
> >> The problem now is, that CW and VC preserve the methods during
> >compiling.
> >> gcc now optimize them away (small, like GetBuffer or so), so they run in
> >> the file, but cannot be linked.
> >>
> >> So, is there a way to get those methods preserved, so I could link to
> >them
> >> ?
> >>
> >> I know, the best is : into the Headers. But I made template classes
> >> (some), which are based on each other. Cause the size, I would like to
> >> have them in cpp / h file. Also this looks more clean.
> >>
> >> Kind regards
> >>
> >> Eljay Love-Jensen <eljay@adobe.com> on Montag, 25. Juli 2005 at 17:32
> >> +0100 wrote:
> >> >Hi Kristian,
> >> >
> >> >Non-specialized template functions and methods need to be defined in
> >the
> >> >header file which declares them.
> >> >
> >> >Otherwise they are only visible to the translation unit in which they
> >are
> >> >defined.
> >> >
> >> >HTH,
> >> >--Eljay
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >> --------------------------------------------
> >> Kristian Kratzenstein
> >> Gettorf
> >>
> >> Kristian.Kratzenstein@KielNET.net
> >> --------------------------------------------
> >>
> >>
> >>
> >>
> 
> 
> --------------------------------------------
> Kristian Kratzenstein
> Gettorf
> 
> Kristian.Kratzenstein@KielNET.net
> --------------------------------------------
> 
> 
>

Re: Problem with class operators.

[Eljay Love-Jensen]

Hi Kristian,

> What is now my conclusion : put small methods into the class decleration.
> But this looks dirty (sorry, but I try to hold my code clean).

Yes, put the non-specialized template method definitions in the header file.
That is where they belong.

You are not keeping your code clean by moving the non-specialized template
methods to a .cpp file.

Although if you REALLY want to do something like that to keep those things
separated, I highly recommend putting your non-specialized template methods,
along with your (explicitly) inline functions, into a file with the
extension .inl and then include that file at the end of your .h file.

For example:

----- foo.h -----
#ifndef foo_h_once
#define foo_h_once

// blah blah blah

#include "foo.inl"
#endif
-----------------

> Is no other way, to stop gcc to inline small methods ?

q.v. these switches

-Winline                    Warn when an inlined function cannot be inlined
-finline                    Pay attention to the "inline" keyword
-finline-functions          Integrate simple functions into their callers
-finline-limit-             This switch lacks documentation
-finline-limit=<number>     Limit the size of inlined functions to <number>
-fkeep-inline-functions     Generate code for functions even if they are
                              fully inlined
-fobey-inline               Obey 'inline' keyword and always inline,
max-inline-insns-single     The maximum number of instructions in a single
max-inline-insns-auto       The maximum number of instructions when
max-inline-insns-recursive  The maximum number of instructions inline
max-inline-insns-recursive-auto The maximum number of instructions
non-inline
max-inline-recursive-depth  The maximum depth of recursive inlining for
                              inline functions
max-inline-recursive-depth-auto The maximum depth of recursive inlining for
                              non-inline functions
inline-unit-growth          how much can given compilation unit grow because
inline-call-cost            expense of call operation relative to ordinary
-fdefault-inline            Inline member functions by default
-fimplement-inlines         Export functions even if they can be inlined
-fimplicit-inline-templates Emit implicit instantiations of inline templates
-fvisibility-inlines-hidden Marks all inlined methods as having hidden
-fdefault-inline, -fdollars-in-identifiers, -felide-constructors,
-fhandle-exceptions, -fhonor-std, -fhuge-objects, -fimplement-inlines,
-fimplicit-inline-templates, -fimplicit-templates, -finput-charset=,
-fvisibility-inlines-hidden, -fvtable-gc, -fvtable-thunks, -fweak,

I produced this list via:

gcc -v --help >gcc.help 2>&1
grep inline gcc.help

HTH,
--Eljay