views:

287

answers:

5

Hi,

I know that nested functions are not part of the standard C, but since they're present in gcc (and the fact that gcc is the only compiler i care about), i tend to use them quite often.

Is this a bad thing ? If so, could you show me some nasty examples ? What's the status of nested functions in gcc ? Are they going to be removed ?

thanks

+5  A: 

As you said, they are a bad thing in the sense that they are not part of the C standard, and as such are not implemented by many (any?) other C compilers.

Also keep in mind that g++ does not implement nested functions, so you will need to remove them if you ever need to take some of that code and dump it into a C++ program.

Justin Ethier
that's funny, they mention the paper Lexical closures for C++ but do not implement the extension in g++
LB
+2  A: 

I don't use them for two very simple reasons.

  1. They are not portable.
  2. They promote poor programming practices.

If you really don't find either of those reasons sufficient, then there is no reason to qualify it as a 'bad' practice. Programmers have historically made use of a particular platform's unique features. However, like #pragmas and other non-portable mechanisms the code you produce will be work you can't leverage in later projects without porting.

Amardeep
Can you please elaborate on why they promote poor practices?
Justin Ethier
Because they promote global data and tight coupling. They create pockets of functionality without a good mechanism to extend their reach. For example if someone creates a nested function whose operations are needed later in a different scope they may find it is easier to make data global rather than restructuring the function to operate on private data.
Amardeep
I don't really understand the argument, this is true for all kinds of lexical closures, right ?
LB
Let me clarify. It is not an intrinsic problem with the concept of nested functions. It is that, just like macros, global variables, arrays, and endless if-then-else-if constructs they allow a cheap and easy solution where a more robust design might pay off better in the long run. I don't use *any* of the above mentioned mechanisms in situations where they can be avoided, even at the expense of more effort.
Amardeep
@Amardeep, i understand what you mean
LB
+6  A: 

Nested functions really don't do anything that you can't do with non-nested ones (which is why neither C nor C++ provide them). You say you are not interested in other compilers - well this may be atrue at this moment, but who knows what the future will bring? I would avoid them, along with all other GCC "enhancements".

I small story to illustrate this - I used to work for a UK Polytechinc which mostly used DEC boxes - specifically a DEC-10 and some VAXen. All the engineering faculty used the many DEC extensions to FORTRAN in their code - they were certain that we would remain a DEC shop forever. And then we replaced the DEC-10 with an IBM mainframe, who's FORTRAN compiler didn't support any of the extensions. There was much wailing and gnashing of teeth on that day, I can tell you. My own FORTRAN code (an 8080 simulator) ported over to the IBM in a couple of hours (almost all taken up with learning how to drive the IBM compiler), because I had written it in bog-standard FORTRAN-77.

anon
I really understand this argument, but is there something fundamentally bad about the implementation of these nested functions ? Or does it break some kind of C philosophy ?
LB
@LB I doubt there is anything bad about the implementation - they are (like I said) simply not necessary.
anon
A: 

I wouldn't use it 'cause it's not portable to other compilers.

pcent
+1  A: 

There are times nested functions can be useful, particularly with algorithms that shuffle around lots of variables. Something like a written-out 4-way merge sort could need to keep a lot of local variables, and have a number of pieces of repeated code which use many of them. Calling those bits of repeated code as an outside helper routine would require passing a large number of parameters and/or having the helper routine access them through another level of pointer indirection.

Under such circumstances, I could imagine that nested routines might allow for more efficient program execution than other means of writing the code, at least if the compiler optimizes for the situation where there any recursion that exists is done via re-calling the outermost function; inline functions, space permitting, might be better on non-cached CPUs, but the more compact code offered by having separate routines might be helpful. If inner functions cannot call themselves or each other recursively, they can share a stack frame with the outer function and would thus be able to access its variables without the time penalty of an extra pointer dereference.

All that being said, I would avoid using any compiler-specific features except in circumstances where the immediate benefit outweighs any future cost that might result from having to rewrite the code some other way.

supercat