This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 08/06/2016 09:08 AM, Richard Biener wrote:
ISTM that unless the code is performance critical we should be writing code that is easy to understand and hard to get wrong.On August 6, 2016 12:15:26 PM GMT+02:00, Aldy Hernandez <aldyh@redhat.com> wrote:On 08/05/2016 04:07 PM, Richard Biener wrote:On August 5, 2016 8:15:54 PM GMT+02:00, Oleg Endo<oleg.endo@t-online.de> wrote:On Fri, 2016-08-05 at 19:55 +0200, Richard Biener wrote:Please don't use std::string. For string building you can use obstacks.Just out of curiosity ... why? I remember there was some discussion about it, what was the conclusion? Is that now a general rule ordoesit depend on the context where strings are used?Because you make a messy mix of string handling variants.Std::string is not powerful enough to capture all uses, it is vastly more expensive to embed into structs and it pulls in too much headers.(Oh, and I hate I/o streams even more)Oh, and there is prior use in ipa-chkp.c, although I suppose it could've crept in:Definitely.std::string s; /* called_as_built_in checks DECL_NAME to identify calls to builtins. We want instrumented calls to builtins to be recognized by called_as_built_in. Therefore use original DECL_NAME for cloning with no prefixes. */ s = IDENTIFIER_POINTER (DECL_NAME (fndecl)); s += ".chkp"; DECL_NAME (new_decl) = get_identifier (s.c_str ()); You can't tell me obstacks are easier on the eyes for this ;-).Even strcat is shorter and cheaper.
Thus when we have something that is non-critical and can be handled by std:: routines we should be using them.
If performance is important in a particular piece of code an obstack or explicit malloc/free seems better.
Can we agree on those as guiding principles and thus boil the argument down to whether or not a particular piece of code is performance critical?
jeff
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |