[off topic] fallow code removal

[John Love-Jensen]

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

[John Love-Jensen]

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

[John Love-Jensen]

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

[John Love-Jensen]

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

[John Love-Jensen]

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

[John Love-Jensen]

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

[John Love-Jensen]

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

[John Love-Jensen]

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