------- Comment #4 from marc dot glisse at normalesup dot org 2006-04-28 20:43 ------- (In reply to comment #3) > Well, I think Andrew has a point: suppose we rename all those functions to > _M_cos and co. Then, later, we discover that a third libc (not Solaris, not > GNU) conflicts with those names too... The point is that there is no *robust* > concept of less-conflict prone name:
I thought about a name that contains gcc or glibcxx or something like that, but now I understand Andrew's point, thank you. > if such conflicts happen then something is > wrong in the design, something profound is wrong, somewhere. So something is wrong in the design. If the wrong thing is in that the libc and compiler are separate entities, there is little we can do about it. So what can be done? Should all those private classes and functions be declared in some specific namespace std::glibcxx_private to have a single point of failure? The current names (__cos and similar) do conflict, and unless a better solution is proposed, renaming (and re-renaming if there still are problems) seems like the easy way to fix it. > We already > discussed this issue in another context (header guards names), and, not having > looked very closely into this specific issue, I'm pretty convinced. Convinced of what? (sorry about my slow understanding of these conversations, I am quite new to gcc, and I guess the style needs some time to sink in) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27340
