Simple doubt about blocks

[Kenneth Brody]

Mark McIntyre said:

[... Braces around blocks of code within a function ...]

No, it doesn't. For one thing, it doesn't have a return type. For another,
it doesn't have type names in the parameter list. For a third, it has a
semicolon in a crucial place. For a fourth, when it is properly indented
it is blindingly obvious that it's code, because C doesn't have nested
functions.

Well, some compilers do have nested functions as an extension.
Also, old-style function declarations do not need to specify a
return type, nor parameter types, as they will default to "int".
This is perfectly legal, AFAIK, at least in C90:

foo(bar,baz)
{
return bar+baz;
}

Yes, if you squiggle up your eyes just so, you can sometimes trick them
into seeing the corner of your room look as if the walls recede from the
corner, going away from you into the distance. But it's a hard illusion to
maintain, and you can't do it for very long, and in the meantime you can
lean on the wall anyway.



It seems you are easily amused.

Well, it would have some "interesting" results in a compiler that
does support nested functions. (If you "accidentally" deleted the
semicolon, that is.)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Antoninus Twink]

this is premature optimisation. There are all sorts of problems
with macros.

Yes, I know. But in the case the OP described, the macro would take no
arguments, and be nothing more than a concatenation of void function
calls. There is really no danger in using a macro in this situation.
You can call it premature optimization: I call it avoiding pointless
pessimization.

(Of course, an inline function would be a good alternative, but we all
know that C99 is anathema in this group.)

 

[Richard]

Yes, I know. But in the case the OP described, the macro would take no
arguments, and be nothing more than a concatenation of void function
calls. There is really no danger in using a macro in this situation.
You can call it premature optimization: I call it avoiding pointless
pessimization.

How is it optimization in this case?

That is another one of those old school yard tales which the clique
bandy around here. There is EVERY point in considering optimization at
an early stage in design. Because if you dont you can end with a
nightmare. Not all the time. But it can happen.

What you should NOT do is worry about a function which is called every 3
days and consumes about 10 ms too much. Clearly. But do worry about the
central process flow and the data structures used to represent that
flow.

C, in my experience, it used in places where speed and efficiency (CPU
and memory) are important commodities. It is madness not to consider
optimization as early as possible in many, many situations. But of
course optimization occurs at many different levels.

 

[Richard Tobin]

That is another one of those old school yard tales which the clique
bandy around here. There is EVERY point in considering optimization at
an early stage in design.

There's *considering* optimisation and *doing* it. When designing or
just writing a program it's useful to keep in mind how it might be
optimised, so that you avoid decisions that make optimisation hard
later. But one of the things that makes optmisations hard is other
optimisations: if you select a particular representation because it
will make some particular operation efficient, it may make it harder
to optimise something else. Often it's best to write things *simply*,
and once you're sure they're working you can measure their performance
and do the optimisation that matters.

-- Richard

 

[Richard]

There's *considering* optimisation and *doing* it. When designing or

I think thats clear to anyone.

just writing a program it's useful to keep in mind how it might be
optimised, so that you avoid decisions that make optimisation hard

Or just do it at no extra cost at the time. e.g do not call "calc md5"
every time - add it to the structure. See. Easy. And its called
optimization.

later. But one of the things that makes optmisations hard is other
optimisations: if you select a particular representation because it
will make some particular operation efficient, it may make it harder
to optimise something else. Often it's best to write things *simply*,

If you are doing it half arsed yes. Your word "often" is of course
applicable. But often is not "always" either.

and once you're sure they're working you can measure their performance
and do the optimisation that matters.

Sure. I do not disagree. And I dont think you are disagreeing with me.

I am not saying you must get the "most optimum" set up from minute 1 -
just that you SHOULD consider it. Optimization thoughts can easily
affect the program structure and flow. And NOT thinking about it earlier
enough can result, and Ive seen them, nasty big systems which waste so
much CPU and memory its not funny.

-- Richard

Some things are simply easier than others. And considering optimization
when you think out the structure is a good thing. Sure somethings can be
a problem later too. But Getting a working inefficient program and then
replumbing it is sometimes totally unnecessary.

I have written a lot of C graphics stuff and considering optimization
was a must from the let go.