Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Good C programming style

Reply
Thread Tools

Good C programming style

 
 
Skarmander
Guest
Posts: n/a
 
      10-08-2005
Skarmander wrote:
> Sensei wrote:
>
>> On 2005-10-07 21:35:26 +0200, Skarmander <(E-Mail Removed)> said:
>>

<snip>
>> #define xge_mklink_slot(com,from,to,slotfrom,slotto) \
>> {\

<snip>
> But even so, it should only be used in a way that does not compromise
> type safety, by defining the type-safe functions:
>
> /* Unlike XGE_MKLINK_SLOT, the compiler will warn or stop if the
> argument types do not match the formal parameter types. */
> [return-type] xge_mklink_slot(xge_com* com, xge_cell from, xge_cell to,
> tkey slotfrom, tkey slotto) {
> return XGE_MKLINK_SLOT(com, from, to, slotfrom, slotto);
> }
>

This can't possibly be right because xge_mklink_slot is defined in such
a way that it cannot evaluate to an expression. Should be

[return-type] xge_mklink_slot(xge_com* com, xge_cell from, xge_cell to,
tkey slotfrom, tkey slotto) {
XGE_MKLINK_SLOT(com, from, to, slotfrom, slotto);
}

It's likely that XGE_MKLINK_SLOT contains no return statement at all,
and [return-type] is just "void".

Left as an exercise to the reader: why could this otherwise produce
warnings of unreachable code, and how should we fix this? Just another
example of why macros should be used carefully.

S.
 
Reply With Quote
 
 
 
 
Sensei
Guest
Posts: n/a
 
      10-08-2005
On 2005-10-08 12:45:05 +0200, Flash Gordon <(E-Mail Removed)> said:

>
> What you have read is correct. Modern compilers have an optimiser to do
> this for you.



Most welcome!

>
> C does not specify a stack. All it specifies is that parameters are
> passed by value (even pointers). On at least some systems parameters
> will be passed in registers.



Quite understandable.

>
> Type checking is a wonderful thing, it allows the compiler to complain
> if you do something obviously stupid. Such as passing a pointer to a
> function requiring an integer.



Yep. True.


>
>> You don't appear to understand that people could ask for informations
>> here about std-c with different knowledge

>
> We are quite used to that.
>
> I strongly suggest you work through K&R2 and read the FAQ for this
> group (which will explain what K&R2 is).



I'm already reading them

>
> Also remember that high level languages were invented to make
> programming easier, and this means you should forget about using a lot
> of the little tricks you use as an assembler programmer.



Ok.

--
Sensei <(E-Mail Removed)>

The difference between stupidity and genius is that genius has its
limits. (A. Einstein)

 
Reply With Quote
 
 
 
 
Sensei
Guest
Posts: n/a
 
      10-08-2005
On 2005-10-08 13:26:29 +0200, Skarmander <(E-Mail Removed)> said:
> Left as an exercise to the reader: why could this otherwise produce
> warnings of unreachable code, and how should we fix this? Just another
> example of why macros should be used carefully.



Thanks. I've read your post(s) and I find them very useful.

I have to learn

--
Sensei <(E-Mail Removed)>

The difference between stupidity and genius is that genius has its
limits. (A. Einstein)

 
Reply With Quote
 
Thad Smith
Guest
Posts: n/a
 
      10-08-2005
Sensei wrote:

> On 2005-10-07 21:42:37 +0200, Keith Thompson <(E-Mail Removed)> said:
>
>>
>> As for function-like macros, they're sometimes the best way to create
>> inline functions. (C99 has inline functions, but not all compilers
>> support them.) There are also things you can do in a macro that you
>> can't easily do in a function, such as using a type name as an
>> argument.

....
> Ok, so defines are used to improve performances as inline functions are
> not supported everywhere.


Yes, sometimes to a ridiculous degree. On the other hand, for embedded
systems simple function-like macros that have constant arguments can
generate very optimized code, due to the ability of the compiler to
evaluate the constant expressions at compile time.

Another use I make of function-like macros is for debugging. The
standard assert() macro is an example. Define NDEBUG and no code is
generated for the macro. I extend this concept for driving realtime
test points for embedded applications. In my case if the test pin macro
(separate from the function-like debug macro) is not defined, no code is
generated.

Thad

 
Reply With Quote
 
Chris Hills
Guest
Posts: n/a
 
      10-08-2005
In article <di6gc0$m52$(E-Mail Removed)>, Sensei <(E-Mail Removed)>
writes
>Hi!
>
>I'm thinking about a good programming style, pros and cons of some
>topics. Of course, this has nothing to do with indentation... Students
>are now java-dependent (too bad) and I need some serious motivations
>for many issues... I hope you can help me I begin with the two major
>for now, others will come for sure!
>
>- function variables: they're used to java, so no pointers. Personally
>I'd use always pointers, but why could be better to use:
> void myfun(int &i) or (int *i) or (int i)
>given that the function can and cannot (the last case of course) modify
>a parameter. I see performance issues (stack related)...
>
>- defines: why they use function and variable defines? why they shouldn't?
> #define MY_PI 3.1415
> #define fun(x) ((x) * (x))
>
>


Try MISRA-C

www.misra-c.com

It is the automotive (and now general embedded and safety critical)
coding guideline



--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ http://www.velocityreviews.com/forums/(E-Mail Removed) www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      10-08-2005
On Sat, 8 Oct 2005 09:20:17 +0000 (UTC), in comp.lang.c , Richard
Heathfield <(E-Mail Removed)> wrote:

>Gregory Pietsch said:
>
>> Sensei wrote:
>>
>>> #define MY_PI 3.1415

>>
>> You might want to extend pi a few more decimal places.

>
>Why? Observe:


(calculation showing differences in radius of earth)

On the other hand, if you're trying to fit a piston into a cylinder,
such wild inaccuracies can matter. Either it will seize in use or will
be so slack as to be useless. This might be quite important if it were
say the pump for an artificial heart or the drive piston of a swing
bridge.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-08-2005
Mark McIntyre <(E-Mail Removed)> writes:
> On Sat, 8 Oct 2005 09:20:17 +0000 (UTC), in comp.lang.c , Richard
> Heathfield <(E-Mail Removed)> wrote:
>
>>Gregory Pietsch said:
>>
>>> Sensei wrote:
>>>
>>>> #define MY_PI 3.1415
>>>
>>> You might want to extend pi a few more decimal places.

>>
>>Why? Observe:

>
> (calculation showing differences in radius of earth)
>
> On the other hand, if you're trying to fit a piston into a cylinder,
> such wild inaccuracies can matter. Either it will seize in use or will
> be so slack as to be useless. This might be quite important if it were
> say the pump for an artificial heart or the drive piston of a swing
> bridge.


And if I have a definition of PI that uses the full precision of
whatever type you're going to use (in this case, you should probably
define it with an "L" suffix and use at least as many digits as long
double supports), I don't have to *think* about whether it's good
enough. 3.1415 (or 3.1416) might be good enough for some
applications. 3.141592653589793238462643383279502884197169399375 106L
is good enough for anything you can do with long doubles (assuming
long double is no more than 50 or so digits). And you only have to
define it once.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      10-08-2005
In article <di81mh$h2g$(E-Mail Removed)> Sensei <(E-Mail Removed)> wrote:
>Ok, so [#]defines [of function-like macros] are used to improve
>performances as inline functions are not supported everywhere.


Or, sometimes, inline macros and/or functions are used to make
performance *worse*.

As a case in point, the BSD code that went into NetBSD performs
all file-system operations through what look like remote procedure
call (RPC) mechanisms, even when doing local procedure calls [%]:

#define VOP_READ(vp, uio, ioflag, cred) \
(GCC-specific code, omitted)
/* and so on for all the many vnode ops */

An RPC requires "marshalling" parameters into a data structure,
so the inline macro/function did something equivalent to:

args.desc = &vnode_read_desc;
args.vp = vp;
args.uio = uio;
args.ioflag = ioflag;
args.cred = cred;
/* find the function to call */
funcptr = inline_table_lookup(vp->filesysinfo, vnode_read_op);
return (*funcptr)(&args);

On the VAX, where this work was originally done in the 1990s,
expanding all the RPC code in-line sped things up, in part because
every subroutine call on the VAX took the equivalent of over a
dozen "regular" instruction times.

As an experiment, the NetBSD team tried "un-inlining" the code, so
that all the marshalling was in actual functions, instead of being
expanded in-line. On at least some, and I think most, of the
supported architectures, the result was a significantly smaller
*and faster* kernel.

[% I argued against this, back when Kirk McKusick was integrating
John Heidemann's changes, but I lost that argument.]
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
 
Reply With Quote
 
cs
Guest
Posts: n/a
 
      10-09-2005
On Sat, 8 Oct 2005 10:55:55 +0200, Sensei <(E-Mail Removed)> wrote:
>On 2005-10-07 21:35:26 +0200, Skarmander <(E-Mail Removed)> said:


>>> #define fun(x) ((x) * (x))


you can do something

fun(t++);

expanded in

(t++)*(t++);

??


>#define xge_mklink_slot(com,from,to,slotfrom,slotto) \
>{\
> tkey _slotfrom=(slotfrom);\
> tkey _slotto =(slotto );\


_name are reserved for compiler; i don't like thid kind of macro

>So, I was wondering why and when it's a good idea to use defines.


for me it is not a good idea for debug puorpose and ... because it is
more easy to write errors

the only macros that i like are
#define P printf
#define F for
#defile W while
#define U unsigned
#define R return

but no one seems agree in this with me ...
 
Reply With Quote
 
Malcolm
Guest
Posts: n/a
 
      10-09-2005

"Keith Thompson" <(E-Mail Removed)> wrote
>
> And if I have a definition of PI that uses the full precision of
> whatever type you're going to use (in this case, you should probably
> define it with an "L" suffix and use at least as many digits as long
> double supports), I don't have to *think* about whether it's good
> enough. 3.1415 (or 3.1416) might be good enough for some
> applications. 3.141592653589793238462643383279502884197169399375 106L
> is good enough for anything you can do with long doubles (assuming
> long double is no more than 50 or so digits). And you only have to
> define it once.
>

If you are working with graphics, it generally doesn't matter if the image
is a pixel out. However if one polygon is a pixel too low, and the adjacent
one a pixel too high, you get a hole, which does matter.
One way of checking whether your code is robust to this type of problem is
to deliberately degrade accuracy, for instance by using 3.142 for PI.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Good idea or gimmick: Go-style OO-programming in C++ ? jeti789@web.de C++ 52 04-06-2013 03:30 AM
Good programming style Astley Le Jasper Python 5 09-15-2008 02:41 PM
good style guides for python-style documentation ? Fredrik Lundh Python 4 04-07-2006 06:19 AM
Could you tell me if this is good meta programming style? Vincent Foley Ruby 2 04-29-2005 10:31 PM
Need help with Style conversion from Style object to Style key/value collection. Ken Varn ASP .Net Building Controls 0 04-26-2004 07:06 PM



Advertisments