Since C has only a few name spaces, automatic inclusion of
all the declarations in all the headers would make a large (and
growing) group of identifiers reserved. Observe, for example,
the care C99 took to avoid making `bool' a keyword, in deference
to existing code that already defined its own `bool'.
I think I combined all the headers once, and the resulting file was still
small, at least compared to say windows.h. And on a typical development
machine, that shouldn't be an issue.
As to avoiding clashes with user-space, my other comment about having
'proper' headers instead of simple include files, might have helped here by
having system names in a higher scope that could be overridden by user
identifiers.
Otherwise, in the case of using bool: surely there are tools that will
refactor code so that problem names (that are now keywords for example) are
fixed, by substituting an automatic or user-supplied alternative (or by
using the C# idea of using @name I think it was, to allow @name as an
identifier, when name is a reserved word.)
I suspect you misunderstand what type qualifiers are. For
starters, your example of `long long unsigned int' has none at all.
Well, I defined what I meant by it. long long unsigned int (even with the
small redundancy removed) is still a mouthful. And makes for longer
declarations that are different to grasp in a glance.
All you've suggested is putting the declarations through a
food processor to chop them into bits and rearrange the fragments.
Yes, rearranged so they are instantly readable without having to enlist
the help of CDECL, or following an algorithm.
Requiring *two* different styles of declaration just makes
reading declarations twice as hard as it is today, since the
reader needs to know two different sets of rules.
C already allows these two styles: however the left-to-right type-spec that
I'm suggesting might go at the start of a declaration, has to be built up
first using typedef, and needs a name assigned to it. This seems a
recommended method of building complex types.
I'm saying this can be done without bothering with creating a new, named
type using typedef.
When I first encountered C in the late 1970's, two things
immediately leapt out at me as syntactic traps: leading 0 for
octal, and the prohibition of white space between the name and
parameter list of a function-like macro. "There," said I to
myself, said I, "are two fruitful sources of error that will
plague C programmers for ever and ever Amen."
Boy, was I wrong! In the thirty-plus years of reading and
writing C that followed, I've seen (and committed) errors of
all kinds, but never, not even once, have I been tripped up or
seen anyone else tripped up by either of these two fatal flaws.
If I'd used C that long (rather than sporadically for a few years), then I'm
sure it would have tripped *me* up: sometimes I like lining up tables of
numbers, and sometimes I like to space those numbers using leading zeros...
(Shrug.) I find it easier to read a more compact notation.
Quickly, now: is the 4096's bit set or clear in
2x11011110101011011011111011101111
You mean bit 11? I would also introduce separators between digits (I use
these elsewhere), your example might then look like:
2x1101_1110_1010_1101_1011_1110_1110_1111
Then bit 11 would be 1.
? If the number were written as 0xDEADBEEF would you reach your
answer more or less rapidly?
In an old thread on this, I gave an example of a literal that had to consist
of, starting from the lsb, one 1 bit, two 0 bits, three 1 bits, four 0 bits,
five 1 bits, six 0 bits, and seven 1 bits. In binary that would be:
2x1111111000000111110000111001
or, misusing my separators:
2x1111111_000000_11111_0000_111_00_1
How does that look in hex? And without writing in binary first...
No, binary literals would have been really trivial to implement in the early
days of C, and would have been very handy.
Not sure what you mean here. If you've got an actual array
and want the element count, the division is a simple and reliable
way to get the answer. Wrap it in a macro if you like; I've done
so sometimes myself.
Sure, like lengthof(). Or length(). Or dim(). Or array_length(). Or
whatever. Which then is put into your personal headers, so that when you
post code here for example, it will cause problems.
If it was part of the language, then it'd be standardised.
But if you're looking for a way to get the element count from
a pointer to an array element, or even to the [0] element, that's
a completely different can of worms, wriggly wriggly worms.
I'm not looking at significant language extensions here.
As far as I can see, real true actual magic would be needed
(since C objects aren't required to carry their types around at
run-time in a form the program could query). Maybe Dumbledore C
could do it.
In this example, using my suggestion of "%?":
int a;
double b;
char *c;
printf ("A,B,C = %? %? %?",a,b,c);
The compiler knows the format string, and can change those "%? %? %?" to "%d
%f %s".
In the rarer case of using a runtime format, let's say containing "A,B,C =
%? %f %s", then yes it's a little more difficult:
char *fmt;
printf (fmt, a,b,c);
There are a number of ways to tackle this without having to write any
special code. For example, for the compiler to transparently convert to:
qprintf(fmt,'d',a, 'f',b, 's',c)
Ie. calling a variation of printf() where every parameter is preceded by
it's main format character. If a format code is "?", it will use the one
supplied; if not, it will ignore the supplied code.
However this is less efficient when most format strings will be
conventional. Possibly better then to explicitly can the special printf
version that adds those extra codes (and the compiler needs to be aware
of these special functions).
Your objection is unclear to me.
It's been discussed here before. In my reply to Keith, I gave an example of
a short, sweet variation on 'for'.
Your objection is unclear to me.
Possibly on your OS, text and binary modes are the same. In mine, text mode
always seems to give problems.
Because they're the implementation's own province, not yours.
Do you intend to forbid an implementation from doing non-portable
things? You'll have a hard time doing I/O -- heck, you'll have a
hard time getting your own main() called.
Either these headers are supposed to be human-readable, or not. Sometimes I
have to try and decipher these things as I try and call some API or other
from a non-C language, and the only details provided are in a C header file.
If these attributes are to do with calling conventions, then there aren't
too many of those, and perhaps they can just be listed somewhere.
I won't argue this any further if you want to disagree for a last