Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > C/C++ guidelines

Reply
Thread Tools

C/C++ guidelines

 
 
Charlie Gordon
Guest
Posts: n/a
 
      09-17-2007
"Harald van D?k" <(E-Mail Removed)> a écrit dans le message de news:
fcj0kn$ul8$(E-Mail Removed)1.ov.home.nl...
> On Sun, 16 Sep 2007 03:26:58 -0700, Keith Thompson wrote:
>> Karl Heinze <nomail@invalid> writes:
>>> On Sun, 16 Sep 2007 11:23:37 +0200, "Peter J. Holzer"
>>> <(E-Mail Removed)> wrote:
>>>> There is STILL something wrong with casting malloc's return value: It
>>>> is unnecessary and clutters up the code.
>>>>
>>> Actually, I already found that habit (casting malloc's return value)
>>> described as _good coding practice_.

>>
>> What's good about it?

>
> If you would like a helper function such as:
>
> static inline int *alloc_int(void) {
> return malloc(sizeof(int));
> }
>
> but are implementing it as a macro:
>
> #define alloc_int() malloc(sizeof(int))
>
> not casting the result means you can assign it to a float * without any
> diagnostic. I will admit that this is not a very common case though.


Types allocation macros can help make code more readable, without casts, yet
detect some mismatches.:

#include <stdlib.h>
#define alloc_type(type) ((type*)malloc(sizeof(type)))
#define alloc_array(type,n) ((type*)malloc((n) * sizeof(type)))

char *p = alloc_array(char, 100);
int *p = alloc_array(int, 100);
float *p = alloc_array(int, 100); // constraint violation

--
Chqrlie.


 
Reply With Quote
 
 
 
 
Szabolcs Nagy
Guest
Posts: n/a
 
      09-17-2007

Richard Heathfield wrote:
> Keith Thompson said:
> > Sounds like we need a widely used library that depends on C99.

>
> That's a contradiction in terms.


why?

imho many people would use a well designed portable c99 lib that
covers most of the basic things (which are not so basic to be in the
stdlib) a la boost

at least it would be good for educational reasons (how to write nice
c99 code)

i don't know exactly what should be in such lib, but it sounds useful
to me

 
Reply With Quote
 
 
 
 
Chris Hills
Guest
Posts: n/a
 
      09-17-2007
In article <(E-Mail Removed). com>,
Szabolcs Nagy <(E-Mail Removed)> writes
>
>Richard Heathfield wrote:
>> Keith Thompson said:
>> > Sounds like we need a widely used library that depends on C99.

>>
>> That's a contradiction in terms.

>
>why?
>
>imho many people would use a well designed portable c99 lib


They do now. Many compiler have a lib that can do full C99 It is just
that the compilers and the market don't want C99.

> that
>covers most of the basic things (which are not so basic to be in the
>stdlib) a la boost


Covers "most of the basic things" do you want a C99 library of
something that sort of does some of it ?

>at least it would be good for educational reasons (how to write nice
>c99 code)


Pointless as no one has C99 compilers.

>i don't know exactly what should be in such lib, but it sounds useful
>to me


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



 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      09-17-2007
Charlie Gordon wrote, On 17/09/07 16:00:
> "Harald van D?k" <(E-Mail Removed)> a écrit dans le message de news:
> fcj0kn$ul8$(E-Mail Removed)1.ov.home.nl...
>> On Sun, 16 Sep 2007 03:26:58 -0700, Keith Thompson wrote:
>>> Karl Heinze <nomail@invalid> writes:
>>>> On Sun, 16 Sep 2007 11:23:37 +0200, "Peter J. Holzer"
>>>> <(E-Mail Removed)> wrote:
>>>>> There is STILL something wrong with casting malloc's return value: It
>>>>> is unnecessary and clutters up the code.
>>>>>
>>>> Actually, I already found that habit (casting malloc's return value)
>>>> described as _good coding practice_.
>>> What's good about it?

>> If you would like a helper function such as:
>>
>> static inline int *alloc_int(void) {
>> return malloc(sizeof(int));
>> }
>>
>> but are implementing it as a macro:
>>
>> #define alloc_int() malloc(sizeof(int))
>>
>> not casting the result means you can assign it to a float * without any
>> diagnostic. I will admit that this is not a very common case though.

>
> Types allocation macros can help make code more readable, without casts, yet
> detect some mismatches.:
>
> #include <stdlib.h>
> #define alloc_type(type) ((type*)malloc(sizeof(type)))
> #define alloc_array(type,n) ((type*)malloc((n) * sizeof(type)))
>
> char *p = alloc_array(char, 100);
> int *p = alloc_array(int, 100);
> float *p = alloc_array(int, 100); // constraint violation


I don't think your suggestion makes it more readable than the following:
Type *p = malloc(N * sizeof *p);

Also less to change if you want to change Type from float to double.

I can see a point to a constructor for a specific type where you are
keeping open the possibility of doing more than merely calling malloc in
the future, but not for your suggested macros.
--
Flash Gordon
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-17-2007
Army1987 <(E-Mail Removed)> writes:
> On Sun, 16 Sep 2007 17:25:52 -0700, Keith Thompson wrote:
>> Tor Rustad <(E-Mail Removed)> writes:
>>> #ifndef __STDC__
>>> #warning "Non Standard C compiler used"
>>> #endif

>>
>> You also need to check for __STDC__ being defined as something other
>> than 1. Some compilers have used __STDC__==0 to indicate partial
>> compliance.

> Usually, #ifndef __STDC__ is (was) used to check whether features
> introduced in ANSI C89 not present in K&R C (e.g. ## token-pasting
> operator) are available. A compiler which *does* define __STDC__
> but to something other than 1 is very likely to have them.


But you can't be sure *which* C89-specific features are supported.
The meaning of defining __STDC__ to anything other than 1 is not
defined by any standard; it's defined only by the documentation of a
particular implementation.

A compiler that supports *all* C89/C90 features will define __STDC__
as 1. (It must; defining __STDC__ as 1 is one of the required
features.)

(On the other hand, there's nothing to stop a perverse non-conforming
compiler from defining __STDC__ as 1; the standard coes not constrain
non-conforming implementations.)

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-17-2007
Flash Gordon <(E-Mail Removed)> writes:
> Charlie Gordon wrote, On 17/09/07 16:00:

[...]
>> Types allocation macros can help make code more readable, without
>> casts, yet detect some mismatches.:
>> #include <stdlib.h>
>> #define alloc_type(type) ((type*)malloc(sizeof(type)))
>> #define alloc_array(type,n) ((type*)malloc((n) * sizeof(type)))
>> char *p = alloc_array(char, 100);
>> int *p = alloc_array(int, 100);
>> float *p = alloc_array(int, 100); // constraint violation

>
> I don't think your suggestion makes it more readable than the following:
> Type *p = malloc(N * sizeof *p);
>
> Also less to change if you want to change Type from float to double.
>
> I can see a point to a constructor for a specific type where you are
> keeping open the possibility of doing more than merely calling malloc
> in the future, but not for your suggested macros.


I agree completely *if* we're just talking about C (as we normally do
here). But the original article in this thread asserted a requirement
to compile the same code as C and as C++. Assuming such a
requirement, using a macro to hide the ugly cast from C programmers
and the ugly use of malloc() from C++ programmers makes some sense.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      09-17-2007
On 16 Sep 2007 22:06:13 GMT, in comp.lang.c , (E-Mail Removed)
(Richard Tobin) wrote:

>*You* rely on that all the time.


I'm unclear why you' chose to emphasise the 'you' in the above
sentence. That aside, while its true you rely on QoI at all times,
there's a minor difference between relying on QoI to diagnose optional
not-technically-faults and having an implementation that doesn't
diagnose gibberish and/or constraint violations.


>The fact that your compiler doesn't
>print "Congratulations! Out of cheese!" when you write a*_=6^%7q++*;
>is thanks merely to quality of implementation.


I can assure you, I've never had an out of cheese error - for one
thing, I can spell wizzard.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      09-17-2007
On Mon, 17 Sep 2007 00:45:06 +0200, in comp.lang.c , "Peter J. Holzer"
<(E-Mail Removed)> wrote:

>On 2007-09-16 21:46, Mark McIntyre <(E-Mail Removed)> wrote:
>
>> Its a warning and (in C89 at least) no diagnosis is actually required.
>> So you're relying on Quality of Implementation.

>
>If you rely on getting a useful diagnostic for an implicit conversion
>from int to a pointer, you are also relying on Quality of
>Implementation. The standard only says that "a diagnostic" is required,


Thats the point tho - a diagnostic is *required*. Whereas it isn't
required (in C89) for no-prototype-in-scope.

>but doesn't require any useful information to be included in the
>diagnostic. "Warning: This program may contain errors" is perfectly
>acceptable as far as the standard is concerned.


So is "warning: this program may contain nuts". So what ?

>As a tiny counter example, I submit that gcc 4.1.2 without any -W*


Note that gcc doesn't claim to conform to any C standard (without the
addition of a forest of flags).

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
Reply With Quote
 
=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0Fk?=
Guest
Posts: n/a
 
      09-17-2007
On Mon, 17 Sep 2007 13:47:01 -0700, Keith Thompson wrote:
> (On the other hand, there's nothing to stop a perverse non-conforming
> compiler from defining __STDC__ as 1; the standard coes not constrain
> non-conforming implementations.)


Worse yet, there's nothing preventing nonconforming implementations from
changing the value of __STDC__ in the middle of preprocessing. GCC does
this on some platforms (but not all!).
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      09-17-2007
Charlie Gordon wrote:
>

.... snip ...
>
> Types allocation macros can help make code more readable, without
> casts, yet detect some mismatches.:
>
> #include <stdlib.h>
> #define alloc_type(type) ((type*)malloc(sizeof(type)))
> #define alloc_array(type,n) ((type*)malloc((n) * sizeof(type)))
>
> char *p = alloc_array(char, 100);
> int *p = alloc_array(int, 100);
> float *p = alloc_array(int, 100); // constraint violation


But you need none of that gubris. The following is correct and
adequate (no defines):

#include <stdlib.h>
char *p = malloc(100 * sizeof *p);
int *q = malloc(100 * sizeof *q);
float *r = malloc(100 * sizeof *r); /* no violation */

You may notice a slight consistency in the code. You can pick up
the malloc statement unchanged and insert it whereever you wish.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

 
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
Case Gallery rules and Guidelines Silverstrand Case Modding 0 06-20-2005 11:38 PM
Portable Coding Guidelines? Roger VHDL 0 12-17-2004 07:33 PM
Code Guidelines JIT ASP .Net 2 11-02-2004 06:57 AM
Is WPS compatible with Smart client as defined in WISPr guidelines nsmurthy Wireless Networking 0 08-13-2004 10:23 AM
VHDL Coding Guidelines Francisco Camarero VHDL 1 07-08-2003 08:17 PM



Advertisments