Interesting and perhaps valid point. Yes, I'm going bottom up. But C
provides no other way to represent strings.
the point is you are defining what strings are in your library.
I don't mind a bit of bottom up but heavy use of it leads to
implementation details leaking into your application. I thought
this was what OO was all about. Hell, I thought that was what
Structured Programming was all about! ADTs...
Are you sure in all cases of this? And is my cast a performance hit?
In C the cast is unnecessary as a void* (which malloc() returns)
is automatically converted to any other pointer type. You need the
cast
in C++ but then you don't normally use malloc() in C++.
There is no performance hit. Casts always do little or no work.
And the implicit conversion does the same work as the explicit
(cast) conversion. Modulo a sane compiler.
OK, you and Heathfield concur. I'll consider it.
don't take my word for it check out any good C tutorial or substantial
body of C code. Not only is it standard (right back to K&R e1) but it
is widely used. If you want to moan about C you could moan that -> is
unnecessary.
struct S s;
struct S *ps;
s.field = 1;
ps = &s;
(*ps).field = 2;
ps->field = 2; /* equivalent to previous line */
ps.field = 2; /* illegal */
there is no particular reason why they couldn't have made the last
line
legal and equivalent to the previous 2.
in a function declaration
int f1();
int f2(void);
don't mean the same thing (things are different in C++). f1 takes
an unspecified but fixed number of arguments. f2 takes no arguments.
hence in the definitions
int f1 (int i) {} /* valid */
int f2 (int i) {} /* not valid */
I like my declarations and definitions to look the same
so I put the voids in the definitions.