twitter: comp.lang.c - 26 new messages in 7 topics

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* Has thought been given given to a cleaned up C? Possibly called C+. - 11
messages, 6 authors
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
* Edward Nilges' lie - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/14c6f4a4afe68f60?hl=en
* Best way/library to draw individual pixels on screen? (for fractals) - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c/t/bf4e0288d8537985?hl=en
* Initializing a character array with a string literal? - 2 messages, 2
authors
http://groups.google.com/group/comp.lang.c/t/534ed676462e64f1?hl=en
* two C "style" questions - 6 messages, 6 authors
http://groups.google.com/group/comp.lang.c/t/f72ed27fa289d30e?hl=en
* A bit resistant to disruption - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/a5ddb7c1aa07c7e5?hl=en
* Letter sent to Apress with concerns about Peter Seebach's online behavior -
1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/482b38643777da3c?hl=en

==============================================================================
TOPIC: Has thought been given given to a cleaned up C? Possibly called C+.
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
==============================================================================

== 1 of 11 ==
Date: Mon, Mar 15 2010 1:33 pm
From: Keith Thompson

Richard Delorme <abulmo@nospam.fr> writes:
> Le 05/03/2010 18:56, Casey Hawthorne a écrit :
>> Peter Van Der Linden in "Expert C Programming - Deep C Secrets" 1994
>> and I imagine others have pointed out some of C's idiosyncrasies.
>> Has thought been given given to a cleaned up C? Possibly called C+.
>
> While reading this thread, it looks that some people want to make
> additions to the language, like Jacob Navia's operator overloading &
> generic containers. To make the language simpler, or cleaner, why not
> rather remove things from it.

Any such change will break existing code.

> For example :
>
> - void can be removed from the language. So instead of declaring
> void f(void);
> we can simply write :
> f();

"f();" already has a meaning in C90; it declares f as a function
returning int and taking an unspecified but fixed number and type
of parameters. C99 dropped implicit int, but "f();" would still
be ambiguous at block scope; is it a function declaration or a
function call?

> The generic pointer type (void *), could then be replaced by (char*)
> without much harm.

Except that there would no longer be a way to distinguish between a
generic pointer and a pointer that actually points to character data.

> - auto can be removed from the language.

Ok. (Note that C++ has recycled the "auto" keyword for another purpose.)

> - register can be removed from the language. The only thing it is
> usefull is to prevent the usage of the address of a variable. If we do
> not want to use an address of a variable I think we can refrain
> ourselves from doing so, without the need of a keyword. Some compiler
> can do some better optimizations with it, but I think most of recent
> compilers don't really care of the presence of this keyword.

That's probably ok, though I'm sure some would disagree. Of course
it would break existing code, but deleting the "register" keyword
for such code would avoid that.

> - restrict can be removed. It is mostly here to facilitate some
> optimizations by the compiler by preventing aliases. I think this is
> not the duty of the programmer to facilitate optimization, but rather
> the burden of the compiler.

The restrict keyword is intended to facilitate optimization in cases
where the compiler doesn't have enough information.

> - -> operator can be replaced by the . operator.

Maybe, but I'm not sure that having two distinct meanings for
a single operator is a simplification.

> We can also get further by cleaning the names of basic types. I would
> prefer to spell char b.y.t.e., as it makes its purpose more
> obvious.

I wouldn't mind having "byte" as a fundamental type, but what about
actual character data?

> Some integer types are redundant, short/int or int/long or
> long/long long depending on the machine. I think such redundancy
> should go.

What about a system with 8-bit char, 16-bit short, 32-bit int,
64-bit long, and 128-bit long long? I don't know whether such
systems currently exist, but they easily could.

One possibility would be to drop long long and support additional
types as extended integer types, with appropriate typedefs in
<stdint.h>. But of course that would break existing code that uses
long long.

> Obviously the standard library could be improved, at least by removing
> dangerous function like gets() or stupid functions like strncpy and
> making all functions thread safe.

gets() is already being deprecated in C201X.

I wouldn't mind dropping strncpy(), but there is *some* code that uses
it. Likely most of that code really should be using something else
instead, but I'm sure some fraction of it actually needs it. Of
course it's easy enough to reimplement.

> It might also be made simpler by
> removing useless type like size_t.

Useless?? What would you use instead?

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 2 of 11 ==
Date: Mon, Mar 15 2010 2:21 pm
From: Keith Thompson

jacob navia <jacob@spamsink.net> writes:
> Richard Delorme a écrit :
[...]
>> We can also get further by cleaning the names of basic types. I
>> would prefer to spell char b.y.t.e., as it makes its purpose more
>> obvious. Some integer types are redundant, short/int or int/long or
>> long/long long depending on the machine. I think such redundancy
>> should go.
>>
>> Obviously the standard library could be improved, at least by
>> removing dangerous function like gets() or stupid functions like
>> strncpy and making all functions thread safe. It might also be made
>> simpler by removing useless type like size_t.
>>
> This is already in the future standard. Most functions of the Microsoft
> safe library proposal are accepted in the standard library.

Are they? I don't see them in N1425. N1135 is titled "Specification
for Safer, More Secure C Library Functions", and appears to contain
what you're talking about, but I'm not sure of its status; does the
committee intend to add these functions to the standard library,
or are then an optional addendum?

== 3 of 11 ==
Date: Mon, Mar 15 2010 2:22 pm
From: Keith Thompson

Richard Delorme <abulmo@nospam.fr> writes:
[...]
> Obviously the standard library could be improved, at least by removing
> dangerous function like gets() or stupid functions like strncpy and
> making all functions thread safe.
[...]

This requires defining what "thread safe" means. C201x does add
threading, but that's hardly consistent with making the standard
library smaller.

At least in some cases, it might make more sense to add thread-safe
versions of some library functions, leaving the existing thread-unsafe
versions in place. (I'm thinking that there could be a performance
impact, but I could be wrong.)

== 4 of 11 ==
Date: Mon, Mar 15 2010 2:56 pm
From: Ian Collins

On 03/16/10 10:22 AM, Keith Thompson wrote:
> Richard Delorme<abulmo@nospam.fr> writes:
> [...]
>> Obviously the standard library could be improved, at least by removing
>> dangerous function like gets() or stupid functions like strncpy and
>> making all functions thread safe.
> [...]
>
> This requires defining what "thread safe" means. C201x does add
> threading, but that's hardly consistent with making the standard
> library smaller.
>
> At least in some cases, it might make more sense to add thread-safe
> versions of some library functions, leaving the existing thread-unsafe
> versions in place. (I'm thinking that there could be a performance
> impact, but I could be wrong.)

Which is the approach adopted by Posix with the suffix "-r" for
reentrant functions.

--
Ian Collins
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 5 of 11 ==
Date: Mon, Mar 15 2010 3:44 pm
From: Richard Outerbridge

What, if any, relevance to this discussion is the
interpreted shell "ch" that can be found at :

< http://www.softintegration.com >

outer
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 6 of 11 ==
Date: Mon, Mar 15 2010 4:24 pm
From: Richard Delorme

Le 15/03/2010 21:33, Keith Thompson a écrit :
> Richard Delorme<abulmo@nospam.fr> writes:
>> Le 05/03/2010 18:56, Casey Hawthorne a écrit :
>>> Peter Van Der Linden in "Expert C Programming - Deep C Secrets" 1994
>>> and I imagine others have pointed out some of C's idiosyncrasies.
>>> Has thought been given given to a cleaned up C? Possibly called C+.
>>
>> While reading this thread, it looks that some people want to make
>> additions to the language, like Jacob Navia's operator overloading&
>> generic containers. To make the language simpler, or cleaner, why not
>> rather remove things from it.
>
> Any such change will break existing code.

I do not agree with this point of view. First, a new language version
does not mean the end of all previous versions. The same compiler can
target K&R C, C90, C99 with the right option. Secondly, it is possible
to smoothly deprecate old parts of a language before removing them. A
diagnostic message warning about the deprecated construct may be used
for a while for a still supported feature.

>> - void can be removed from the language. So instead of declaring
>> void f(void);
>> we can simply write :
>> f();
>
> "f();" already has a meaning in C90; it declares f as a function
> returning int and taking an unspecified but fixed number and type
> of parameters.

Which is a pretty useless declaration.

> C99 dropped implicit int, but "f();" would still
> be ambiguous at block scope; is it a function declaration or a
> function call?

Forward function declaration should be added to my list of things to remove.

>> The generic pointer type (void *), could then be replaced by (char*)
>> without much harm.
>
> Except that there would no longer be a way to distinguish between a
> generic pointer and a pointer that actually points to character data.

Right. Is this really a problem ? Maybe a byte type instead of the char
type will make things easier.

>> - restrict can be removed. It is mostly here to facilitate some
>> optimizations by the compiler by preventing aliases. I think this is
>> not the duty of the programmer to facilitate optimization, but rather
>> the burden of the compiler.
>
> The restrict keyword is intended to facilitate optimization in cases
> where the compiler doesn't have enough information.

Or when the compiler is not clever enough. But I am not sure a typical C
programmer will be able to provide this information better than a compiler.

>> - -> operator can be replaced by the . operator.
>
> Maybe, but I'm not sure that having two distinct meanings for
> a single operator is a simplification.

Nor I am. But are the two meanings so distinct? An advantage of using a
single operator is in case of refactoring some code, replacing object
type with pointer to object will then be much easier.

>> We can also get further by cleaning the names of basic types. I would
>> prefer to spell char b.y.t.e., as it makes its purpose more
>> obvious.
>
> I wouldn't mind having "byte" as a fundamental type, but what about
> actual character data?

Having a byte type will free the char type to actually represent
characters, and only characters.

>> Some integer types are redundant, short/int or int/long or
>> long/long long depending on the machine. I think such redundancy
>> should go.
>
> What about a system with 8-bit char, 16-bit short, 32-bit int,
> 64-bit long, and 128-bit long long? I don't know whether such
> systems currently exist, but they easily could.

In such a system, there is no redundancy, so I have no objection here. I
was writing about the other cases.

>> It might also be made simpler by
>> removing useless type like size_t.
>
> Useless?? What would you use instead?

The type it is typedef from.

--
Richard
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 7 of 11 ==
Date: Mon, Mar 15 2010 4:24 pm
From: Richard Delorme

Le 15/03/2010 22:22, Keith Thompson a écrit :
> Richard Delorme<abulmo@nospam.fr> writes:
> [...]
>> Obviously the standard library could be improved, at least by removing
>> dangerous function like gets() or stupid functions like strncpy and
>> making all functions thread safe.
> [...]
>
> This requires defining what "thread safe" means.

Sorry, I meant reentrant. Reentrancy problems, although exacerbated in
multi-threaded programs, can arise on single-threaded programs. For
example the POSIX function strtok_r is a reentrant version of of strtok.

== 8 of 11 ==
Date: Mon, Mar 15 2010 4:25 pm
From: Bart

On Mar 15, 8:33 pm, Keith Thompson <ks...@mib.org> wrote:
> Richard Delorme <abu...@nospam.fr> writes:

> > - auto can be removed from the language.

> > - register can be removed from the language. The only thing it is

> > - restrict can be removed. It is mostly here to facilitate some

> The restrict keyword is intended to facilitate optimization in cases
> where the compiler doesn't have enough information.

All these keywords are very worthy but they do clutter things up.

> > We can also get further by cleaning the names of basic types. I would
> > prefer to spell char b.y.t.e., as it makes its purpose more
> > obvious.
>
> I wouldn't mind having "byte" as a fundamental type, but what about
> actual character data?

What about both? A char type (always unsigned), and a signed/unsigned
byte for integer values.

>
> > Some integer types are redundant, short/int or int/long or
> > long/long long depending on the machine. I think such redundancy
> > should go.
>
> What about a system with 8-bit char, 16-bit short, 32-bit int,
> 64-bit long, and 128-bit long long? I don't know whether such
> systems currently exist, but they easily could.

C#'s type system, based exactly on 8,16,32 and 64-bit values, seems
wonderfully clear and concise. You always know exactly what width you
will get.

But C# doesn't have to run on weird hardware so C can't really join in
the fun, it's stuck with it's snazzy looking int_least32_t and
friends.

--
Bartc
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 9 of 11 ==
Date: Mon, Mar 15 2010 4:25 pm
From: Keith Thompson

Ian Collins <ian-news@hotmail.com> writes:
> On 03/16/10 10:22 AM, Keith Thompson wrote:
[...]
>> At least in some cases, it might make more sense to add thread-safe
>> versions of some library functions, leaving the existing thread-unsafe
>> versions in place. (I'm thinking that there could be a performance
>> impact, but I could be wrong.)
>
> Which is the approach adopted by Posix with the suffix "-r" for
> reentrant functions.

You mean "_r", yes?

== 10 of 11 ==
Date: Mon, Mar 15 2010 4:43 pm
From: Ben Bacarisse

Lew Pitcher <lpitcher@teksavvy.com> writes:

> On March 15, 2010 13:25, in comp.lang.c, abulmo@nospam.fr wrote:
> [snip]
>> - -> operator can be replaced by the . operator.
>
> This suggestion seems contrary to the pattern you establish with your other
> suggestions. While your other suggestions address language simplification
> for the programmer's benefit, this one complicates a programer's work
>
> For me, it is simpler to write
> a->b
> than it is to write
> (*a).b
> K&R even refers to the -> notation as a "convenient shorthand".

I think the proposal is to use . in place of ->. The compiler can
always tell whether the LHS is a pointer or a struct, so it always
know what to do with E1.E2.

<snip>
--
Ben.
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 11 of 11 ==
Date: Mon, Mar 15 2010 4:44 pm
From: Ian Collins

On 03/16/10 12:24 PM, Richard Delorme wrote:
> Le 15/03/2010 21:33, Keith Thompson a écrit :
>> Richard Delorme<abulmo@nospam.fr> writes:
>
>>> It might also be made simpler by removing useless type like size_t.
>>
>> Useless?? What would you use instead?
>
> The type it is typedef from.

Well that depends on the environment (32/64 bit etc.), so there would
have to be a typedef.

So what do you propose changing? Going from a standard typedef to an
arbitrary one?

==============================================================================
TOPIC: Edward Nilges' lie
http://groups.google.com/group/comp.lang.c/t/14c6f4a4afe68f60?hl=en
==============================================================================

== 1 of 4 ==
Date: Mon, Mar 15 2010 1:34 pm
From: Sjouke Burry

spinoza1111 wrote:

Cut

Why are yo so desperately trying to proof you are a troll??

== 2 of 4 ==
Date: Mon, Mar 15 2010 2:07 pm
From: Keith Thompson

Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> writes:
> spinoza1111 wrote:
>
> Cut
>
>
> Why are yo so desperately trying to proof you are a troll??

Right, if the first 2615 complaints haven't had any effect, surely
the 2616th complaint will make him see reason and reform his
trollish ways. (For those who don't recognize it, that was sarcasm.)

I realized some time ago that complaining to spinoza1111 is a
waste of time and bandwidth. I'm now coming to the conclusion that
complaining to the people who continue to provoke him is equally
a waste. (Yeah, I know, what took me so long?)

== 3 of 4 ==
Date: Mon, Mar 15 2010 3:49 pm
From: raltbos@xs4all.nl (Richard Bos)

Squeamizh <squeamz@hotmail.com> wrote:

> On Mar 15, 10:57=A0am, Tim Streater <timstrea...@waitrose.com> wrote:
> > On 15/03/2010 12:08, spinoza1111 wrote:
>
> Are you you idiots seriously going to respond to the latest wave of
> nonsensical ramblings from this lunatic?

Yes, they are.

> There is really no excuse for continuing to add this kind of noise.

Of course not, but there _is_ an explanation. And it isn't pretty.

Richard

== 4 of 4 ==
Date: Mon, Mar 15 2010 4:12 pm
From: Seebs

On 2010-03-15, Richard Bos <raltbos@xs4all.nl> wrote:
> Of course not, but there _is_ an explanation. And it isn't pretty.

Every so often I toy with the idea of correcting one or two of the many
errors in a Nilges post. However:

1. I've corrected him on a few of his claims about me in the past, and
he keeps making the obviously false claims.
2. Even though I suspect some of it is technically defamatory per se,
it's not as though anyone's going to believe anything so obviously kooky.

If this were a more chatty forum, I'd probably interact with him for
the lulz, but Usenet tends to favor staying more focused on actual
technical discussion. He gives every impression of being just shy of
completely ineducable, and I don't really see much reason to pursue
things further. People can read my code and make their own decisions
about its quality. :P

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

==============================================================================
TOPIC: Best way/library to draw individual pixels on screen? (for fractals)
http://groups.google.com/group/comp.lang.c/t/bf4e0288d8537985?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Mar 15 2010 1:43 pm
From: Sjouke Burry

Wolfnoliir wrote:
> Hello,
> I would like to know what library and method you would recommend for
> displaying individual pixels on the screen in the scope of producing
> representations of fractals based on complex iteration (e.g. Mandelbrot
> or Julia). So it is important that the method be speed efficient.
> I would also be interested in knowing (very briefly) how one would go
> about making a video player inside a GTK application.
>
> I have some knowledge of SDL and OpenGL already.
I once wrote a wildcard bmp viewer for Dos, showing how the
structure is implemented.
It shows 2/4/4rle/8/8rle/and 24 bit rgb decoding and the diffs
between OS2 and M$ .
If you want the sourcecode, ask here or try to de-louse
my email adress.

==============================================================================
TOPIC: Initializing a character array with a string literal?
http://groups.google.com/group/comp.lang.c/t/534ed676462e64f1?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Mar 15 2010 1:55 pm
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <20100315215436.26@gmail.com>, Kaz Kylheku <kkylheku@gmail.com> writes:
> On 2010-03-15, Ersek, Laszlo <lacos@ludens.elte.hu> wrote:
>> If your execution character set is ASCII-based, the above will amount to
>>
>> char unsigned str[5] = { 0x68u, 0x65u, 0x6Cu, 0x6Cu, 0x6Fu };
>
> If your execution character set is ASCII based, it means that
> you haven't yet managed to install Linux on that old IBM junker you
> got at the swap meet.
>
> Writing { 0x68u, 0x65u, 0x6Cu, 0x6Cu, 0x6Fu } instead of "hello", in the
> name of portability to EBCDIC is egregiously moronic, and a disservice
> to whoever is signing your paycheck.

Not to debate your point any further, but I'd like to add the following:

1. In C99, __STDC_ISO_10646__ defined by the implementation implies,
AFAICT, that "hello" will in fact translate to { 0x68u, 0x65u, 0x6Cu,
0x6Cu, 0x6Fu } (and possibly a trailing \0 if space allows). I think
this can be derived from 6.10.8p2, 6.4.5p3, 6.4.4.4p11 and 5.2.1.2p1:

char unsigned s[5] = "hello";
= { 'h', 'e', 'l', 'l', 'o' };
= { L'h', L'e', L'l', L'l', L'o' };
= { 0x68u, 0x65u, 0x6Cu, 0x6Cu, 0x6Fu };

2. It seems to me that all four versions of the SUS published till now
were explicitly written with EBCDIC in mind.

v1:
System Interface Definitions
Issue 4, Version 2
4.4 Character Set Description File
paragraph 7

----v----
The charmap file was introduced to resolve problems with the portability
of, especially, /localedef/ sources. This document set assumes that the
portable character set is constant across all locales, but does not
prohibit implementations from supporting two incompatible codings, such
as both ASCII and EBCDIC. Such dual-support implementations should have
all charmaps and /localedef/ sources encoded using one portable character
set, in effect cross-compiling for the other environment. [...]
----^----

v2:
http://www.opengroup.org/onlinepubs/007908775/xbd/charset.html#tag_001_004

v3:
http://www.opengroup.org/onlinepubs/000095399/xrat/xbd_chap06.html#tag_01_06_01

v4:
http://www.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap06.html#tag_21_06_01

v4 is POSIX:2008 too, thus not very old. Citing the linked-to passage of
the v4 rationale:

----v----
A.6.1 Portable Character Set

The portable character set is listed in full so there is no dependency
on the ISO/IEC 646:1991 standard (or historically ASCII) encoded
character set, although the set is identical to the characters defined
in the International Reference version of the ISO/IEC 646:1991 standard.

[...]

The statement about invariance in codesets for the portable character
set is worded to avoid precluding implementations where multiple
incompatible codesets are available (for instance, ASCII and EBCDIC).
[...]
----^----

I hoarded all this stuff together because your post made me ponder
whether these standards I care about do require ASCII-based encodings
from a conforming implementation. They seem not to.

I'm not obsessed with EBCDIC per se. I generally care that my
assumptions about the environment -- not guaranteed by relevant
standards -- are *conscious*.

lacos

== 2 of 2 ==
Date: Mon, Mar 15 2010 2:17 pm
From: Jef Driesen

On 15/03/10 13:51, Tom St Denis wrote:
> On Mar 15, 8:24 am, Jef Driesen<jefdrie...@hotmail.com.invalid>
> wrote:
>> The code is actually written in C. But it uses a number of C99 features
>> (such as variable declaration that are not at the top of a block) that
>> are not supported by the msvc C compiler, so I compile it as C++ code.
>>
>> Thus adjusting my sizeof's is a less ugly solution in my case.
>
> Maybe the solution is to refactor your code so you can declare your
> local variables at the top of block scope? Just saying...

Those declarations are not the only C99 feature I'm using. Refactoring
is an option, but there are a lot more urgent items on my todo list if
you know what I mean.

For now, knowing that there is a difference between C and C++, using a
null terminated string works in both cases and is not that ugly to deal
with.

==============================================================================
TOPIC: two C "style" questions
http://groups.google.com/group/comp.lang.c/t/f72ed27fa289d30e?hl=en
==============================================================================

== 1 of 6 ==
Date: Mon, Mar 15 2010 2:03 pm
From: sandeep

Hello friends

Two questions for you...

1| Is it considered best practise to use the full C names for Composite
Types (ie long int, short int, unsinged long long int), or to use the
short Java-style names (ie long, short, unsigned long long).

2| If a function has to receive multiple parameters, on what conditions
is it recommended to have a container struct for the parameters instead
of passing them individually.

Thanks...

== 2 of 6 ==
Date: Mon, Mar 15 2010 2:07 pm
From: Hamiral

sandeep wrote:
> Hello friends
>
> Two questions for you...
>
> 1| Is it considered best practise to use the full C names for Composite
> Types (ie long int, short int, unsinged long long int), or to use the
> short Java-style names (ie long, short, unsigned long long).

It's more explicit to use full names for the types, but any C programmer
would (should) understand the "short" versions.

> 2| If a function has to receive multiple parameters, on what conditions
> is it recommended to have a container struct for the parameters instead
> of passing them individually.

Structs should be used to group data that relate to each other. Or you
will end up writing structs for each functions...

just my 0.02€ ;)

Ham

== 3 of 6 ==
Date: Mon, Mar 15 2010 2:22 pm
From: Seebs

On 2010-03-15, sandeep <nospam@nospam.com> wrote:
> 1| Is it considered best practise to use the full C names for Composite
> Types (ie long int, short int, unsinged long long int), or to use the
> short Java-style names (ie long, short, unsigned long long).

I don't know, but I personally write "int" only when something is not
a short, long, or long long.

> 2| If a function has to receive multiple parameters, on what conditions
> is it recommended to have a container struct for the parameters instead
> of passing them individually.

When it makes sense.

Seriously, not kidding. If the parameters are logically a single thing,
they should be passed in as a single thing. If they're separate things,
they should be passed in separately.

== 4 of 6 ==
Date: Mon, Mar 15 2010 2:25 pm
From: Andrew Poelstra

On 2010-03-15, sandeep <nospam@nospam.com> wrote:
> Hello friends
>
> Two questions for you...
>
> 1| Is it considered best practise to use the full C names for Composite
> Types (ie long int, short int, unsinged long long int), or to use the
> short Java-style names (ie long, short, unsigned long long).
>

It makes no difference. Most people read them quickly enough
not to even notice whether 'int' appears. So it's up to you.
I prefer brevity.

> 2| If a function has to receive multiple parameters, on what conditions
> is it recommended to have a container struct for the parameters instead
> of passing them individually.
>

If your parameters relate to each other, you can group them into
structs. Like, if you had a function

double distance_4D(w1, x1, y1, z1, w2, x2, y2, z2);

probably you would benefit from some sort of 4D point structure.

I've never had a case where I needed a struct just for the sake of
making a function declaration short, though.

--
Andrew Poelstra
http://www.wpsoftware.net/andrew

== 5 of 6 ==
Date: Mon, Mar 15 2010 3:40 pm
From: John Bode

On Mar 15, 4:03 pm, sandeep <nos...@nospam.com> wrote:
> Hello friends
>
> Two questions for you...
>
> 1| Is it considered best practise to use the full C names for Composite
> Types (ie long int, short int, unsinged long long int), or to use the
> short Java-style names (ie long, short, unsigned long long).
>

I don't know if there's any agreed-upon convention; we don't have
anything that specific in our coding standards where I work. For
myself, I tend to use the short forms.

> 2| If a function has to receive multiple parameters, on what conditions
> is it recommended to have a container struct for the parameters instead
> of passing them individually.
>

The only reason to create a composite data type is if the elements of
the type are logically related to each other and describe a larger
entity. Under normal circumstances, you would *not* create a
composite data type *just* to bundle otherwise unrelated function
parameters together (there may be specific and unusual cases where
it's necessary to meet a performance requirement or address an
architectual quirk, but these should be very rare).

== 6 of 6 ==
Date: Mon, Mar 15 2010 3:50 pm
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <slrnhpt97p.9eh.apoelstra@localhost.localdomain>,
Andrew Poelstra <apoelstra@localhost.localdomain> writes:

> I've never had a case where I needed a struct just for the sake of
> making a function declaration short, though.

"generic callback functions" sometimes take a pointer-to-void, or a
union of two members, a pointer-to-void and some integer. The
pointer-to-void allows you to pass arbitrary parameters to the callback,
packed in an "artificial" struct. Example from N1425:

----v----
7.24.5.1 The thrd_create function

Synopsis

int thrd_create(thrd_t *thr, thrd_start_t func,
void *arg);

Description

The thrd_create function creates a new thread executing func(arg). [...]
----^----

Granted, this is not done for the brevity but the uniformity of the
interface.

lacos

==============================================================================
TOPIC: A bit resistant to disruption
http://groups.google.com/group/comp.lang.c/t/a5ddb7c1aa07c7e5?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Mar 15 2010 3:39 pm
From: Moi

On Sun, 14 Mar 2010 21:23:38 -0700, Thad Smith wrote:

> Thad Smith wrote:
>> Moi wrote:

>> What is the recovery path for 0000, the initial state?
>
> It would be best to specify the recovery path for all possible startup
> states. How about startup in 0, 1, 2, 4, 5, 8, a, f, interpreting bit
> combination as hexadecimal?
>
> I assume that resting states are 3, 6, c, 9, where 3, 6 are global off,
> while c and 9 are global on. Is this correct?

It is in the code. The comment at the top of the
file only describes the normal flow of state.

**********/

int restart(void)
{
unsigned state;

while (1) {
state = getbits();
fprintf(stderr, "Restart state = %s Rawbits=%02x %02x %02x %02x\n"
, states[state]
, bits[3], bits[2], bits[1], bits[0] );
switch (state) {
case COMBINE4(0,0,0,0): /* before initialization */
bit_clr(2);
bit_clr(1);
bit_clr(0);
bit_set(0);
bit_set(1);
bit_clr(3);
return getstate();
case COMBINE4(0,0,1,1):/* ..11 [Off] */

/*************

et cetera.

AvK

==============================================================================
TOPIC: Letter sent to Apress with concerns about Peter Seebach's online
behavior
http://groups.google.com/group/comp.lang.c/t/482b38643777da3c?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Mar 15 2010 3:47 pm
From: raltbos@xs4all.nl (Richard Bos)

Lubow <dynamitemike@hotmail.com> wrote:

> On Mar 14, 1:38=A0am, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
> >. The far more valid inference is that
> > you're too much of a loser to work with other than a bunch of fucking
> > assholes.
>
> Spinoza, it did not take you too long to recognize what Mr. Reid is
> all about.
>
> Congratulations. For most of us, it took about 48 hours to figure out
> Reid. I think you broke the record.

You are, however, not doing as well on spinoza!!!!.

Richard

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Monday, March 15, 2010

comp.lang.c - 26 new messages in 7 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts