* Which ELF platforms support visibility attribute? @ 2005-07-25 7:50 Jonathan Turkanis 2005-07-25 8:26 ` Problem with class operators Kristian Kratzenstein 0 siblings, 1 reply; 13+ messages in thread From: Jonathan Turkanis @ 2005-07-25 7:50 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Problem with class operators. 2005-07-25 7:50 Which ELF platforms support visibility attribute? Jonathan Turkanis @ 2005-07-25 8:26 ` Kristian Kratzenstein 2005-07-25 11:44 ` Eljay Love-Jensen 0 siblings, 1 reply; 13+ messages in thread From: Kristian Kratzenstein @ 2005-07-25 8:26 UTC (permalink / raw) To: gcc-help 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 -------------------------------------------- ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with class operators. 2005-07-25 8:26 ` Problem with class operators Kristian Kratzenstein @ 2005-07-25 11:44 ` Eljay Love-Jensen 2005-07-25 12:06 ` Kristian Kratzenstein 2005-07-25 15:17 ` Kristian Kratzenstein 0 siblings, 2 replies; 13+ messages in thread From: Eljay Love-Jensen @ 2005-07-25 11:44 UTC (permalink / raw) To: Kristian Kratzenstein, gcc-help 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with class operators. 2005-07-25 11:44 ` Eljay Love-Jensen @ 2005-07-25 12:06 ` Kristian Kratzenstein 2005-07-25 15:17 ` Kristian Kratzenstein 1 sibling, 0 replies; 13+ messages in thread From: Kristian Kratzenstein @ 2005-07-25 12:06 UTC (permalink / raw) To: gcc-help 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 -------------------------------------------- ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with class operators. 2005-07-25 11:44 ` Eljay Love-Jensen 2005-07-25 12:06 ` Kristian Kratzenstein @ 2005-07-25 15:17 ` Kristian Kratzenstein 2005-07-25 15:32 ` Eljay Love-Jensen 2005-07-25 15:49 ` corey taylor 1 sibling, 2 replies; 13+ messages in thread From: Kristian Kratzenstein @ 2005-07-25 15:17 UTC (permalink / raw) To: gcc-help 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 -------------------------------------------- ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with class operators. 2005-07-25 15:17 ` Kristian Kratzenstein @ 2005-07-25 15:32 ` Eljay Love-Jensen 2005-07-25 17:47 ` Kristian Kratzenstein 2005-07-25 15:49 ` corey taylor 1 sibling, 1 reply; 13+ messages in thread From: Eljay Love-Jensen @ 2005-07-25 15:32 UTC (permalink / raw) To: Kristian Kratzenstein, gcc-help 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with class operators. 2005-07-25 15:32 ` Eljay Love-Jensen @ 2005-07-25 17:47 ` Kristian Kratzenstein 2005-07-25 18:00 ` Eljay Love-Jensen 2005-07-25 18:13 ` corey taylor 0 siblings, 2 replies; 13+ messages in thread From: Kristian Kratzenstein @ 2005-07-25 17:47 UTC (permalink / raw) To: gcc-help 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 -------------------------------------------- ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with class operators. 2005-07-25 17:47 ` Kristian Kratzenstein @ 2005-07-25 18:00 ` Eljay Love-Jensen 2005-07-25 18:13 ` corey taylor 1 sibling, 0 replies; 13+ messages in thread From: Eljay Love-Jensen @ 2005-07-25 18:00 UTC (permalink / raw) To: Kristian Kratzenstein, gcc-help 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with class operators. 2005-07-25 17:47 ` Kristian Kratzenstein 2005-07-25 18:00 ` Eljay Love-Jensen @ 2005-07-25 18:13 ` corey taylor 2005-07-25 19:02 ` Kristian Kratzenstein 1 sibling, 1 reply; 13+ messages in thread From: corey taylor @ 2005-07-25 18:13 UTC (permalink / raw) To: Kristian Kratzenstein; +Cc: gcc-help 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 > -------------------------------------------- > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with class operators. 2005-07-25 18:13 ` corey taylor @ 2005-07-25 19:02 ` Kristian Kratzenstein 2005-07-25 19:07 ` corey taylor 2005-07-25 19:32 ` Eljay Love-Jensen 0 siblings, 2 replies; 13+ messages in thread From: Kristian Kratzenstein @ 2005-07-25 19:02 UTC (permalink / raw) To: gcc-help 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 -------------------------------------------- ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with class operators. 2005-07-25 19:02 ` Kristian Kratzenstein @ 2005-07-25 19:07 ` corey taylor 2005-07-25 19:32 ` Eljay Love-Jensen 1 sibling, 0 replies; 13+ messages in thread From: corey taylor @ 2005-07-25 19:07 UTC (permalink / raw) To: Kristian Kratzenstein; +Cc: gcc-help 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 > -------------------------------------------- > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with class operators. 2005-07-25 19:02 ` Kristian Kratzenstein 2005-07-25 19:07 ` corey taylor @ 2005-07-25 19:32 ` Eljay Love-Jensen 1 sibling, 0 replies; 13+ messages in thread From: Eljay Love-Jensen @ 2005-07-25 19:32 UTC (permalink / raw) To: Kristian Kratzenstein, gcc-help 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with class operators. 2005-07-25 15:17 ` Kristian Kratzenstein 2005-07-25 15:32 ` Eljay Love-Jensen @ 2005-07-25 15:49 ` corey taylor 1 sibling, 0 replies; 13+ messages in thread From: corey taylor @ 2005-07-25 15:49 UTC (permalink / raw) To: Kristian Kratzenstein; +Cc: gcc-help 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 > -------------------------------------------- > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2005-07-25 19:32 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-07-25 7:50 Which ELF platforms support visibility attribute? Jonathan Turkanis 2005-07-25 8:26 ` Problem with class operators Kristian Kratzenstein 2005-07-25 11:44 ` Eljay Love-Jensen 2005-07-25 12:06 ` Kristian Kratzenstein 2005-07-25 15:17 ` Kristian Kratzenstein 2005-07-25 15:32 ` Eljay Love-Jensen 2005-07-25 17:47 ` Kristian Kratzenstein 2005-07-25 18:00 ` Eljay Love-Jensen 2005-07-25 18:13 ` corey taylor 2005-07-25 19:02 ` Kristian Kratzenstein 2005-07-25 19:07 ` corey taylor 2005-07-25 19:32 ` Eljay Love-Jensen 2005-07-25 15:49 ` corey taylor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).