[off topic] fallow code removal
Hi everyone, My apologies for posting off topic. I'm desperate. One of my project's general on-going tasks is to eliminate dead code. Sort of following the Extreme Programming principle. Does anyone know of any tool that can help identify fallow routines? Can GCC itself help facilitate finding fallow routines that would be candidates for removal? Note: there are hundreds of SSO's and DSO's involved, all written in C or C++. Which makes finding fallow routines that much more difficult. Any suggestions, pointers or recommendations for tools, tips and/or techniques would be appreciated. The "intimate knowledge of your code base" works in the small, but fails in the large. Doesn't scale. Sincerely, --Eljay
doh
Sorry, I didnĀ¹t mean to cross post my off-topic post to this forum. I meant it to go to gcc-help only. Mea culpa, --Eljay
Re: How to make a file which is both shared library and executable
Hi Durga, Please do not cross-post to both gcc and gcc-help lists. Here is an example to do what you want: http://gcc.gnu.org/ml/gcc-help/2003-07/msg00232.html HTH, --Eljay
Re: STL slist/map containers concurrent/thread-safe access
Hi Kalaky, #1. Please do not cross post to GCC-help and GCC lists. #2. GCC@gcc.gnu.org is not an appropriate forum for your question. #3. [EMAIL PROTECTED] is not an appropriate forum for your question. #4. Your question is a general C++ question, not a GCC question. > Given that removing/inserting elements from a map/slist/whatever does > not invalidate iterators to list elements, it is safe to use the > element that the iterator "points" to ? The rules for iterator invalidation are tightly dependent on the container involved. I recommend reading the ISO 14882 standard very carefully about what STL containers guarantee about their iterators. (I always have to look them up myself -- I tend to pessimistically over-assume that my iterators are invalidated more often then they really are in actuality.) I'm pretty sure that removing an element from a container will cause any iterator pointing to that element to become invalidated, for all containers. How do you have an iterator to an element in a container, when that element hasn't been inserted into the container yet? *AFTER* an element is inserted into a container, and then you acquire an iterator to that element, I presume that iterator properly refers to that element. I recommend you use a "Safe STL" for your development. It will help you discover problematic STL usage in your code. Here are some "safe STL" implementations: http://www.horstmann.com/safestl.html http://www.stlport.org/ http://gcc.gnu.org/onlinedocs/libstdc++/debug.html Good luck! --Eljay
Re: No effect of -fshort-enums..is it a bug
Hi Gaurav, >Please confirm which of the two outputs is correct and why is there a difference in the output of two versions of compiler? Both outputs are "correct". (Neither output is compliant to the standard, of course, as -fshort-enums is a deviation from the standard.) Sincerely, --Eljay
Re: No effect of -fshort-enums..is it a bug
Hi Dave, Daniel, and Gaurav, For C99, I stand corrected. For C89 or C++98, I think my statement is applicable. (But until I double-check by reading those standards, take that with a grain of salt.) For all three, having enum be an int (signed or unsigned) is legit of course. For all three, having enum be a long is (at best) a compiler extension, at worst (-pedantic ?) not supported. If I'm reading the specs correctly. NOTE: not germane to Gaurav's question, just talking out loud. Sincerely, --Eljay
Re: No effect of -fshort-enums..is it a bug
Hi Gaby, Dave, Daniel, and Gaurav, >This is incorrect and misleading. I concur. I retract my previous statement, and direct seekers-of-clarification to the previous posts that answered this issue. My apologies for my confusion. Sincerely, --Eljay
Re: No effect of -fshort-enums..is it a bug
Hi Gaurav, You could do this... q = 4294967295U Or you could use -std=iso9899:1999 (perhaps with -pedantic) for the compiler to produce an error. Assuming you are using GCC 4.x. Or if you *want* to allow that, you could do this... -std=gnu99 I'm guessing as to which version of GCC you are using, and what command line options you used to compile with, and your platform's architecture. HTH, --Eljay