a CPAN for C

[bartc]

bartc wrote:


Why? There are perfectly good tools to locate declarations in source code.
The days are long gone when it was necessary to do these things manually.

Tools are fine, but the code should stand by itself too.

(And why doesn't the tool, presumably part of the editor, just relocate a
declaration where it belongs, ie. near the top of the block, or (for those
of us who are old-fashioned), near the top of the function.)

 

[bartc]

[and to what]. I prefer code like

{
declarations;

initializations;

code;
}

How nOObish!

I'm ok with things like

if (blah) {
int x;
x = some_struct->member;
// blah...
}

But I think declaring variables wherever is messy and shows a lack of
forethought/design [e.g. you're just making up variables mid thought
as opposed to fully thinking through your algorithm first].

Local declaration is THE way to do it since no namepsaces are unduly
polluted.

Functions already have a local namespace.

How big are your functions that you need to have multiple namespaces inside
them!

(I believe C allows you at least 1e50 distinct identifiers within one
namespace, and that's without even making use of case sensitivity.)

If you dont agree then I suspect your code is like something from the
ark.

for(int i=0; i<LIMIT;i++){}

Perfect, clean, readable.

Presumably you can also do this:

for(int i=0; i<LIMIT1;i++)
for(int i=0; i<LIMIT2;i++)
for(int i=0; i<LIMIT3;i++) int a=i+i+i;

Very neat.

 

[Willem]

bartc wrote:
) (And why doesn't the tool, presumably part of the editor, just relocate a
) declaration where it belongs, ie. near the top of the block, or (for those
) of us who are old-fashioned), near the top of the function.)

Because then it would be a fascist tool which enforces a particular coding
style which many consider to be bad. Whereas a tool which aids in finding
declarations does no enforcing whatsoever. Most programmers value freedom


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Keith Thompson]

bartc wrote:
) (And why doesn't the tool, presumably part of the editor, just relocate a
) declaration where it belongs, ie. near the top of the block, or (for those
) of us who are old-fashioned), near the top of the function.)

Because then it would be a fascist tool which enforces a particular coding
style which many consider to be bad. Whereas a tool which aids in finding
declarations does no enforcing whatsoever. Most programmers value freedom

I'd call such a tool fascist only if it forced that behavior on me,
any more than "indent" is fascist for enforcing brace layout. A tool
that rearranges code like that might be quite useful. If nothing
else, the analysis it would have to perform would likely catch a
number of errors.

But yes, I certainly wouldn't use an editor that forcibly moved
declarations around. Apparently bartc would. (That's not a
criticism, just an observation.)

 

[Flash Gordon]

Flash Gordon a écrit :

But... you are not forced to use that.
Agreed.

It is for people that want to
use linked lists without bothering to reinvent the wheel again.

They already don't need to... however if yours turns out to be good
enough it could supersede others. You certainly seem to be putting in
the amount of effort needed to make it good enough.

OK. Then go onusing your lists.

Well, it was written by someone else and just improved by me... others
though were written by me.

I mean, what I want is that newcomers
(and oldtimers) that do NOT feel like reimplementing a binary search
tree, or a double linked list from scratch can use a standard package
that is immediately usable, comes with source code, and can be adapted
at will.

<snip>

Plenty of those around. Having similar interfaces for a whole range of
types of contain could be useful, less to learn, so you might have an
advantage there.

Actually, I've only written linked lists two or three times, and each
time in a different language (once in assembler for a DSP, highly
optimised for the specific application as I did not have a cycle or byte
to spare).

 

[Flash Gordon]

I think you are missing the point. There were scores of container
libraries for C++ when the STL came along. Those who had their own
carried on using them, most of those who didn't, picked the STL. That's
how libraries become "standard": they exist and people start using them.

I'm aware of that. You've miss-understood my point below...

I don't know whether Jacob will achieve this (within the bounds of
standard C), but being generic is one of the reasons behind the C++ STL.
The beauty of the STL design is most users never see the complexity
behind this, they just use the containers "as is". I fear C's inherent
transparency will make this hard for Jacob to achieve.

I'm not talking about the complexity of using it as a programmer, I'm
talking about the complexity of the code, e.g. calling functions through
pointers instead of directly... when I've needed linked lists I've also
needed them to be as efficient as possible (in all but one case), so did
not want the overhead of function pointers which Jacob is using.

 

[Ian Collins]

I'm aware of that. You've miss-understood my point below...

Ah, I see.

I'm not talking about the complexity of using it as a programmer, I'm
talking about the complexity of the code, e.g. calling functions through
pointers instead of directly... when I've needed linked lists I've also
needed them to be as efficient as possible (in all but one case), so did
not want the overhead of function pointers which Jacob is using.

Fair point. Maybe that's one reason attempts to build a generic C
container library haven't been successful. I don't mean successful
technically, there are plenty out there that work well, but successful
in adoption.

To be wildly adopted, a container library must have the following
properties:

1 - Be easy to use.
2 - Flexible.
3 - No performance impact over hand rolled code.

The C++ STL used templates, so it doesn't suffer the performance impact
of function pointers so it ticks all three boxes. A good C
implementation will tick the first two but will struggle with the third.
I guess without language support for generics, any two properties are
possible at the cost of the third.

 

[Nick]

I'm not talking about the complexity of using it as a programmer, I'm
talking about the complexity of the code, e.g. calling functions
through pointers instead of directly... when I've needed linked lists
I've also needed them to be as efficient as possible (in all but one
case), so did not want the overhead of function pointers which Jacob
is using.

I'd tend to agree. A lot of link lists are really very simple (free
lists of reclaimed objects for example) and wrapping them in piles of
other stuff undoes some of the benefits (speed compared with
free/malloc) that you are aiming for.

But since I last wrote on this I've come up with a really good example
of where some more complicated standard data types would help. I'm
doing some character conversion stuff and am about to write some wrapper
code to call the (POSIX) 'iconv' function - this reads from one char
buffer and writes to another.

The prototype is:
size_t iconv(iconv_t cd,
char **inbuf, size_t *inbytesleft,
char **outbuf, size_t *outbytesleft);

and it has a whole set of return values to say whether it stopped
because of an error, because it succeeded completely or because it ran
out of space to write the result.

Think just how much easier it would be to use this function if the
output parameters were replaced with some sort of "real string"
implementation - any one of the millions! You'd just pass the input
string and check for an error return. If no error, the result is in the
output.

 

[Nick]

bartc is deluded if he really thinks all variable declarations should be
at "the top". That style is nothing more than a relic of "must do" from years
ago. As for the ridiculous comments from St Denis about putting all your
variables first makes you think more about he algorithm, well, laughable
comes to mind. There really is not other way to describe it.

A really good example of where I use block-scope variables is in large
switches in mini-language stuff. Sure, you could use a function table,
but it's often easier to do this.

For many commands you don't need any extra variables, for some you need
an integer, for another a character pointer, for another a specialised
structure. Having a pile of these all defined and pre-initialised at
the top of what could be pages of code is far less clear than
introducing a pair of braces and a variable just in the 'case' you need
them.

 

[Antoninus Twink]

for the C language is there something like CPAN is for Perl ? if this
is asking too much then maybe a list of commonly used libraries for C
? for both Linux and Windows, not necessarily(but hopefuly) portable ?

If you're using Linux, your distribution probably provides something
very much like CPAN. The relevant libraries will come neatly packaged
with documentation and descriptions you can search for keywords. They
will be called lib* and can be installted with a tool like apt-get or
rpm.

Many of the libraries will be portable, of course.

 

[Richard Bos]

I don't know whether Jacob will achieve this (within the bounds of
standard C), but being generic is one of the reasons behind the C++ STL.
The beauty of the STL design is most users never see the complexity
behind this, they just use the containers "as is".

IMO, that is the beauty of STL for C++ users, and the danger for C
users. I _want_ to know how complex a container I use is. I want no
surprises. That's why I use C, and not Java or C++.

Richard

 

[Richard Bos]

While VLAs have their obvious problems, I don't see how you can object
to something that shortens and clarifies code (mixed declarations and code).

I object because IME it doesn't clarify the code. Oh, it _could_ be used
to define an object just before the code to which it logically belongs,
but IME if nearly always _is_ used in the thought process "Oh, damn, I
need another total counter! Better declare it right here, where I first
thought of it".
That's also why I do _not_ object to the specific case of for-loop local
declarations: because in that case, it is impossible to put the
declaration in a random place somewhere hidden inside the rest of the
code. It's always, guaranteed, right where it belongs.

Richard

 

[Ian Collins]

IMO, that is the beauty of STL for C++ users, and the danger for C
users. I _want_ to know how complex a container I use is. I want no
surprises. That's why I use C, and not Java or C++.

The complexity of the standard C++ containers is defined in the language
standard, so there wont be any surprises.

 

[Ian Collins]

I object because IME it doesn't clarify the code. Oh, it _could_ be used
to define an object just before the code to which it logically belongs,
but IME if nearly always _is_ used in the thought process "Oh, damn, I
need another total counter! Better declare it right here, where I first
thought of it".

A common use case (at least for me) is for intermediate values of
complex expressions. A trivial example being:

const int systemPower = busVoltage(someBus) * loadCurrent(someBus);

Such values are naturally const, so they can't really be declared before
they are initialised.

 

[David Thompson]

Functions already have a local namespace.

How big are your functions that you need to have multiple namespaces inside
them!

C calls a function body, or other block, or a translation-unit ~=
source file, 'scope' (in each case excluding any contained scope
which re-declares aka shadows the identifier). 'namespace' means
something else, namely one of: tags; members per struct/union;
labels per function; or all other 'ordinary' identifiers per scope.

(I believe C allows you at least 1e50 distinct identifiers within one
namespace, and that's without even making use of case sensitivity.)

Do you mean 'allow' as in an implementation must provide (and a
portable progam may use) or an implementation _may_ provide?

5.2.4.1 specifies some 'minimum maximums', amounts an implementation
must provide (although formally only in 'one program' which may well
not be any program you want) including the following with
C89value/C99value :

- 127/511 identifiers with block scope [per] block

- 31/127 parameters [per] function

- 511/4095 file-scope identifiers per t.u.

- 127/1023 members of a struct or union; members of an enumeration are
ordinary identifiers in the containing scope, and I don't see anything
about the number of tags per scope or t.u.

The only obvious maximum maximum (!) is the number of distinct
identifiers using the specified (C89) or basic (C99) character set
of length up to 31 (C89) or 63 (C99) less keywords (negligible).
The former of these is in the general area of 1e55, and may be what
you were thinking of, but a program containing that many identifiers
could not be recorded in the universe. Possibly something like the old
BASIC CHAIN$ applied to universes would help -- but not any of us,
since we wouldn't exist when (if ever) the answer (42?) is produced.

Presumably you can also do this:

for(int i=0; i<LIMIT1;i++)
for(int i=0; i<LIMIT2;i++)
for(int i=0; i<LIMIT3;i++) int a=i+i+i;

Very neat.

Indeed you can, although it's mostly useless, even if you (try to)
make the body less trivial.