declaring a function in a function - C programming

tuxdev · 05-26-2010, 08:32 AM

Quote:

As far as I know, closures are being considered for part of the new C++ standard.

Only a blunder on the level of "export templates" would make closures not standard.

Quote:

Either way, that's even more reason to avoid using them - then, you would be able to compile the same code with (1) a C compiler that treats the function definition as a normal function definition that captures nothing about the lexical environment and (2) a C++ compiler that captures the lexical environment.

One of my strongest pet peeves is that C and C++ are separate languages and "C/C++" is an abomination. They require absolutely different mindsets. Also, source compatibility for anything except special small examples hasn't existed since ever.

Quote:

Not only will they both compile as if nothing were wrong, but a C or C++ programmer (especially one that's not been exposed to functions as first-class objects, lexical closures and such) will have a very, very hard time tracking down the bugs that introduce, which will probably be many, colourful and varied.

Which means the programmer needs to catch up, not that the language should be held back. Closures are an extremely useful abstraction, and all but necessary to tackle some hard problems. Of course, with what I just said below, this implies that you probably shouldn't be tackling those kind of hard problems in C.

Quote:

I'm sorry, but I feel compelled to point out that this post makes you come across as both pompous and dismissive.

It's hard not to be pompous and dismissive against someone who has repeatedly shown themselves to not know what they're talking about at all and has a habit of injecting pointless flamebait one-liners into threads.

Quote:

Closures in "C" make it much more potent and closer to C++ from the point of view of functionality.

Quote:

I know what closures are and even if C had closures, I'd think putting a function in a function is still a bad idea (indeed, a much worse idea than I already do), partly because it's so utterly against the philosophy of the rest of the language.

Yeah, exactly. I'm not objecting to closures in C because closures themselves are bad, but they just don't belong in *C*. Closures are a far too much a high-level concept to introduce to a language that's supposed to be the lowest-level portable language possible. They do fit in C++, but that's because C++ is intended to both have the abstraction power of a high-level language and the bare-metal power of a low-level language.

Sergei Steshenko · 05-26-2010, 10:35 AM

Quote:

Originally Posted by tuxdev

...I'm not objecting to closures in C because closures themselves are bad, but they just don't belong in *C*. Closures are a far too much a high-level concept to introduce to a language that's supposed to be the lowest-level portable language possible.
...

And how does introduction of closures affect low-levelness of "C" ? If you don't want, you do not use them.

And how does introduction of closures affect portability of "C" ? Perl works on almost anything and has closures on every platform it works on.

tuxdev · 05-26-2010, 10:42 AM

Quote:

And how does introduction of closures affect low-levelness of "C" ? If you don't want, you do not use them.

Doesn't matter if you use them or not. Closures are a high-level construct.

Incidentally, "don't pay for what you don't use" is a C++ idea, not a C one. C is really well described as "portable assembly", and that's an important role.

Quote:

And how does introduction of closures affect portability of "C" ? Perl works on almost anything and has closures on every platform it works on.

Nothing, but that's not the point. Closures are a high-level construct.

Sergei Steshenko · 05-26-2010, 10:49 AM

Quote:

Originally Posted by tuxdev

Doesn't matter if you use them or not. Closures are a high-level construct.

Incidentally, "don't pay for what you don't use" is a C++ idea, not a C one. C is really well described as "portable assembly", and that's an important role.

Nothing, but that's not the point. Closures are a high-level construct.

So what ?

To me "C" with closures looks a much more logical and reasonable choice than C++ in any shape or form.

joel2001k · 05-29-2010, 02:47 AM

I read your posts and due this I was able to find an article the keyword I was looking for is auto.

Code:

void
ags_channel_recursive_play_init(AgsChannel *channel)
{
  AgsAudio *audio;
  AgsRecycling *first_recycling, *last_recycling;
  GList *child;
  guint group_id;
  auto void ags_channel_recursive_play_init_down(AgsChannel *output, guint parent_group_id, guint group_id);
...

ArthurSittler · 06-02-2010, 10:14 AM

I am surprised if a function can be declared auto in C. Auto applies to variables and other data objects.

C is intentionally a very simple language. K & R 2ed. maintains the original scoping rules for function from the first edition verbatim. One can only limit the scope of a function to be local to the file that contains the function, by declaring it static. By default functions have external linkage and are visible to the linker. Dividing a program into many smaller files is not a bad practice.

If you use some sequence of code more than once in a function with the same type parameters and the same meaning, then it will make the program more readable and more likely to be correct if you pull that code sequence out into its own function. I have heard many programmers claim that this programming rule is wasteful because of the overhead of function calls and returns. However, I have seen too many program bugs introduced by "copy and paste" replication of code to give that objection any recognition. C++ recognizes the efficiency advantage of avoiding function calls and the hazards of "copy and paste" replications by providing the inline keyword.

(EDIT by poster: inline IS now standard in C! Please refer to posting below by posixculprit!)
Some C compilers might permit using the inline keyword in C, but that keyword is not part of standard C and is not portable.

Pascal, Modula, and C++ have more complicated scoping rules for functions and include functions local to functions, in Pascal and Modula, and local to classes, in C++.

posixculprit · 06-02-2010, 10:30 AM

Quote:

Originally Posted by ArthurSittler

the inline keyword. Some C compilers might permit using the inline keyword in C, but that keyword is not part of standard C and is not portable.

Really? Have you actually read the C standard? ISO/IEC 9899, 6.7.4 "Function specifiers":

Code:

Syntax
        function-specifier:
                inline

ArthurSittler · 06-02-2010, 11:38 AM

Thank you, posixculprit. I was using outdated proposed standard in K & R 2ed. with corrections. I am glad to be wrong about the inline keyword, even though I end up with foot-in-mouth disease, again.

posixculprit · 06-02-2010, 03:10 PM

Sure thing (trust me, there are many aspects of the C programming language that I am not familiar with). Although I consider K&R (2nd edition) to be an unusually good book (it remains my favorite programming books of all time), it was published in late 80s. As such, it should not come as a surprise that the C standard published in the late 90s contains information not present in K&R.