Thomas Matthews said:
You answered:
The speed at which an API changes is not related to the language. An
API in Ada or Lisp can change as fast as one in C or C++. This is a
design issue, not a language one.
In theory yes, in practice, C is the only language used by most OSes for the API.
No C++ API interface for an OS is running now, but I think some now defunct
machines used C++ for all their OS interface. Mostly, it is C that is used.
Lisp was used by Symbolics, but as an API interface was the only example I know.
ADA is probably used in the pentagon for some OS work, but nothing from that
is public so I can't tell you.
It is mostly C that is used in:
o Linux, and Unix in general.
o All the windows API.
o The Mac had a Pascal interface, but with OS-X it comes back to the C API of Unix.
The binary code generated from either language is not guaranteed to be
interchangeable, even on the same platform between compiler revisions.
Shared libraries are interchangable. They make transparent the C runtime and
can be used from any laguage. Of course, linking object files of two compilers is
not a good idea, but sharing libraries on .so or .dll is widespread.
[snip]
What is a binary interface? Is it an interface with two arguments or
are you talking the actual specification of passing arguments and
receiving values from functions?
A binary interface is this
int strcmp(char *a,char *b);
This means in most systems that a word is returned with the result of the function
calling a routine that receives two words containing each one a machine address
that is generally pushed in the stack from right to left. Yes, nothing of that is in
the standard, it is only standard practice.
Can you quote C&V from the C standard about the interface specification?
My understanding is that a stack is not required and many platforms use
a stack to pass arguments. Hmmm, standard?
A C standard shouldn't get bogged down into details about if there is a stack or not.
But 99.999% of the people discussing in this group have machines where a stack
is present.
Do you know this for a fact?
Yes. Since I wrote that stuff I know that it exists, sorry.
I wrote a code generator in C++. I would expect that a code generator
would be written in a language that had excellent string handling.
Well, C is not the best in that area. But you can do it, it is not that complicated.
The problem comes from a conservative opinion in the standards and in the C
community as a whole. The primitive string data structure is very bad in intensive
usage. But it has sticked around since it is standard. And nobody wants to change it
since all development of C should be done in C++.
Many people stick to a "minimal" C, using only a data structure where text is
handled by data buffers finished by a zero byte, without any length information.
Each time the length of the string is needed, the whole string must be searched
to find the zero byte. This is obvious and been discussed to death but never a
fix was done.
No bounds checking are done, and no checks at all are provided. The programmer
is expected to be perfect. This is obviously impossible, and bugs in string handling
programs are widespread.
C++ improved this obviously, specially by giving people the capacity of writing string
handling packages more easily.
An application has no bearing on the quality of the language that it
was written in. There are excellent "applications" written in C as
well as horrible. Microsoft has some good applications and some not
so good ones. Some are written in Visual Basic, others in a mixture
of languages.
In principle you are right. The problem with debugging C++ is that an extra effort
must be done to cater for a language where only two compilers exist: Comeau and
Edison Design Group front end. All others implement subsets of the standard
with non-overlapping bugs.
The advantages of C in GUI applications are obvious. [snip]
Take the C program of lcc-win32, the IDE+Debugger, "wedit".
It is around 700K executable size. A comparable C++ program would be like 3-4MB.
Here it is again, that C++ size issue. A comparable program written in
C++ should be the same size as one in C.
Mmm, did you use the STL? Now come on... please be realistic.
If it is different by using
features or design issues not present in C, it is not a comparable
program. Size is not the only issue when developing an application;
quality, robustness and development time come to mind. If size was
an isssue, we would still be coding in assembler.
I use to program in assembler sometimes. There is nothing faster even after all
this years. Compilers are loosers against an assembly programmer since they have
to be right for ALL cases. The assembler programmer must be right only for THIS
program.
[snip]
what do you mean by "C is quite transparent?"
C programs do not have so much automatic baggage supplied by the compiler
like C++. The compiler actually, is more transparent. The objective must be
to keep the compiler transparent.
I've debugged many nightmares in C and C++ as well as other languages.
The complexity of a language may be related to its readibility. The
measure of readibility depends on the craftsman.
In general yes, in practice you will see how much C++ code will survive.
Let's see.
WTF are you talking about. The C language specification has pages and
pages of complex specifications.
Yes, but nowhere is required from the programmer that he/she performs a topological
sort of the class structure pleeeeeze.
Most specs in the C standard are very short, and describe things like prototypes,
library functions like strcmp, and other such issues. Yes, they are complex, but
they can be read by anybody, and do not specify so many features that only two
compilers in the whole world implement it *FULLY*
That's why there are so many books
out there. The complexity of the specification comes from the more
string requirements for standardization and portability. Here is one
example issue: What happens when memcmp() is passed null pointers?
(Hint, the answer isn't specified directly in the memcmp() section).
No sorry. The C++ complexity comes not from the specs of memcmp, even if they are
more detailed than the C99 instructions. They come from issues like name spaces
that nobody seems to get right, and from the sheer number of features that this
"super compiler" must do.
Operator overloading is clearly defined in C++. Not as much fun as
casting pointers in C.
Yes, that is a good idea of C++ and I said in my message that I have tried to
replicate it in a C context.
The beauty of the diea comes better when it doesn't have a heavy class inheritance
structure or similar mixups.
Can do in C. Your point? There are no "indirect chains" to follow.
The compiler selects the appropriate function based on a set of rules.
Yes, and it has to follow the inheritance hierarchy. and sort which class
member is the "nearest".
This is precisely my point. I am sure that the set of rules exists, since the
C++ standard specifies them. I am only saying that it is impossible for a
human being to do that in his/her head each time it is calling a function member.
And that when the human being is no longer able to see what are the consequences
of the code he/she is writing are, the complexity gets out of hand.
This is said beyond any "my computer language against yours", feeling by the
way. I am just trying to get the best of both worlds: the simplicty of C and the
power of some C++ features.
[snip]
In C++, one can convert a user-defined type from another type by
creating "constructor" methods. So if one wanted to convert from
a string to a qfloat, either an explicit constructor is created or
a global function is created.
I don't see your basis for this argument.
The problem with automatically called constructors is that they do not appear
in the program source, and can't be easily controlled by the programmer.
I think that in the stage of a C languag framework, a cast is more explicit and
natural than paying the huge price of having constructors being called
ALWAYS.
If you read my message again you maybe notice that I was speaking of new
numeric data types, as an example of the advantages of using normal syntax
for user defined types.
I see you have a casting issue with your compiler. My understanding
from the folks in is that lcc-win32 is not a C++
compiler or not a good one.
100% correct. lcc-win32 is a C compiler and will never be a C++ compiler.
I have incorporated into the compiler some facilities of C++, like operator
overloading, references, default arguments for functions, and generic
functions (using the same name for different functions with different inputs).
This makes C easier to use, and I hope some other people see it as a proof
that the good ideas of C++ can be done in a simpler environment where they
do not increase the complexity of the language but its capacity of expression.
Obviously, such an approach will be rejected by the "pure C" people and by the
"pure C++" people, I had expected that when I started.
Your issues with that compiler are best
discussed in a newsgroup about that compiler.
Yes, but this discussion about C++ and C is pertinent to this group, and I
hope I can still say my opinion here.
As far as casting goes,
I don't see the need to convert a variable from type A to C via
type B. I would consider this a design flaw. I believe that any
conversion between user defined type should use explicit functions
to show the reader exactly what is happening.
Yes, this is the same conclusion I expressed in the last lines of my article. The
emphasis was in why this would be bad, i.e. the design guidelines.
I don't see how you came to this conclusion. Why must one stop?
Because, for instance, if you drink 0.25 liters of milk is good for you, but
if you drink 25 liters of milk is deadly for you. Please learn when to stop!
Can you say macros for C? Templates in C++ are an improvement
over macros in C.
I have in mind something different. Not at all macros but compile time
functions, i.e. you write true functions that compile C code. That would be
great for template writing and would simplify it a lot.
