jacob navia wrote:
[color=blue]
> ----- Original Message -----
> From: "Malcolm" <malcolm@55bank.freeserve.co.uk>
> Newsgroups: comp.lang.c
> Sent: Tuesday, September 23, 2003 8:03 PM
> Subject: Re: GUI ?
> [snip]
>
>[color=green]
>>Because C++ offers greater power than C, what then happens is that a C++
>>interface is built on top of the C interface. This will typically provide
>>classes for objects such as buttons and scroll bars.[/color][/color]
I just have to correct some points made below. I'm not advocating C++
over C nor do I want to start a thread about C++ is better than C. I
use them both and they have their purposes. Somethings are better
coded in C++; others in C. There is no universal best language.
[color=blue]
> C is much simpler than C++, and with some syntactic improvements, can be
> used to do whatever you want to do.[/color]
I agree with the complexity issue. However, both languages can be used
to "do whatever you want to do."
[color=blue]
> Besides, one of the advantages of using C is that the API used changes very slowly,
> if at all.[/color]
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.
[color=blue]
> C++ language interfaces suffer from their name mangling schema, that makes
> impossible to interchange binary code.[/color]
The binary code generated from either language is not guaranteed to be
interchangeable, even on the same platform between compiler revisions.
The standard specification of both languages assists in interchanging
of sources between platforms. One can always stick in platform specific
code which makes porting a nightmare. The C language specification
makes no requirements about the "binary code" generated from the source.
[color=blue]
> C, with its simple binary interfaces, is needed in every C++ program to allow
> an interchange of compiled programs. See a recent article in C, C++ User's
> Journal, where the C++ code guru explained to a novice why C interfaces are
> useful and mandatory to interchange C++ stuff.[/color]
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?
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?
[color=blue][color=green]
>>What you will also find is many automated code generators which allow the
>>programmer to build GUI objects like dialogs using a point and click
>>interface.[/color]
>
>
> Yes. I did one in C. When you click in the right buttons ( or just push the
> default button) it will generate a full empty windows application for you.
> Many code generators are written in C, mind you.[/color]
Do you know this for a fact?
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.
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.
[color=blue]
> The advantages of C in GUI applications are obvious.[/color]
Actually, the advantages are not obvious. I seen GUI applications
written in Visual Basic as well as C++. No end user can tell what
language an application was written in. The quality of the application
depends on the design and coding as well as the platform. An awful
OS will render any application it runs as poor.
[color=blue]
> 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.[/color]
Here it is again, that C++ size issue. A comparable program written in
C++ should be the same size as one in C. 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.
[color=blue]
> More important, the C program is very easy to understand and debug. C is
> quite transparent.[/color]
C programs are not very easy to understand. Check out the entries to
the Obfuscated Code contest. Ada and Pascal are easier languages to
read. But readability is a personal issue, not one of the language.
I can make an assembly language program easy to read and understand.
Lisp, on the other hand...
BTW, what do you mean by "C is quite transparent?"
[color=blue]
> Implicitely instantiated default template members?
> Impenetrable class hierarchies that makes debugging a nightmare?[/color]
I've worked on C projects that had hierachial nightmares.
Again, any feature of any language can be abused. The features of
a language are to make that language more useful. One of the
responsibilities of the craftsman is to make debugging easier and
perhaps not even necessary.
[color=blue]
> No thanks. There is enough nightmares with C already, to add some.
> Keeping down complexity (simplifying) means making programming languages
> easier to read.[/color]
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.
[color=blue]
> What looks right at the beginning, doesn't look right when it is in the form of
> pages and pages of complex specifications like the directives for operator
> overloading and the class hierarchy in the C++ standard. That stuff runs for
> pages and pages, and it is completely impossible for a human being to follow
> that. It needs a compiler since a topological sort of the class hierarchy is needed,
> and I find it quite hard to do that without a computer.[/color]
WTF are you talking about. The C language specification has pages and
pages of complex specifications. 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).
Operator overloading is clearly defined in C++. Not as much fun as
casting pointers in C.
[color=blue]
> At this point we reach the rupture point. Complexity is out of hand.
>
> For instance take operator overloading. The decision of following or not
> indirect chains must be done. You can specify a cast, to transform one
> type of object into another.[/color]
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.
Ambiguous functions are noted as errors or warnings by the compiler.
[color=blue]
> Suppose you have a character string and you want to transform it into a 352
> bit floating point number. The cast is just a function that takes one argument,
> the source type, and yields another type, in this example a floating point
> object. The operator overloading is just syntactic sugar for
> qfloat a = StringToQfloat("0.177665599787E-9");
>
> The advantage of writing
> qfloat a = (qfloat)"0.177665599787E-9";
>
> is that the user doesn't have to remember the name of the conversion function.
> Was it StringToQfloat?? or it was Stringtoqfloat ? or even string2qfloat? Ahh where
> is that documentation, it was there last week...[/color]
This is, (using a California, USA term) "bogus". In the C language,
there are many different ways to convert from a string to an integer.
"Ahh, where is that documentation, it was there last week...". Was it
strtol? strtoul? strotod? scanf? atoi? sscanf?
Which one is safe? Which are completely portable? Don't get me started
on the File I/O routines.
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.
[color=blue]
> The compiler will call this function whenever a direct conversion between the
> source type and the destination type is needed. But lcc-win32 will not follow
> indirect links, i.e. if you specify a cast from A to B, and a cast from B to C
> exists, it will not be discovered. You will have to write
> (C)(B)(A)var;
> This means that it is explicitely stated in the program source, the set of
> transformations done to the data.[/color]
I see you have a casting issue with your compiler. My understanding
from the folks in news:comp.lang.c++ is that lcc-win32 is not a C++
compiler or not a good one. Your issues with that compiler are best
discussed in a newsgroup about that compiler. 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.
[snip -- type conversion issues][color=blue]
>This is my justification for stopping here. C++ doesn't stop of[/color]
course, and adds[color=blue]
> the class hierarchy with multiple inheritance so that the original simple idea
> becomes specifications that are no longer comprehensible by a human being...[/color]
Hmmm, sounds like you had a bad experience debugging somebody's
poor coding (and perhaps design). This can be done in C or C++.
This is the difference between average programmers and better
craftsman.
[color=blue]
> The crux of the matter is finding where you stop.
>
> In lcc-win32, some ideas of C++ are implemented within the C language context.
>
> Keeping C means learning where to stop.[/color]
I don't see how you came to this conclusion. Why must one stop?
I've seen OO principles coded in C that were very ugly, but
that was how it had to be done. Two examples are inheritance
and exceptions. The C++ language has made inheritance less
of a pain for the programmer to code (perhaps the pain has
been transferred to the compiler). Bad inheritance can
occur in any language where inheritance can be implemented.
Can you fathom inheritance in assembly or Lisp?
[color=blue]
>
> Templates come next, but I am getting off topic. Sorry.[/color]
Can you say macros for C? Templates in C++ are an improvement
over macros in C. Stencils are nice. Smart stencils become
a nightmare, but that is my opinion, "I could be wrong."
[color=blue]
>
> jacob
>
>[/color]
--
Thomas Matthews
C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq:
http://www.parashift.com/c++-faq-lite
C Faq:
http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
