GUI ?

[Les Coover]

I am taking a C programming class, we get into a little C++. I understand
that C++ is used to build many different types of applications
including Microsoft Office Products
http://www.research.att.com/~bs/applications.html

The code we write is run either in a UNIX or MS-DOS window. I was wondering
how they develop the sophisticated GUI windows using
C++ programs. I'm not looking for a technical explanation just a brief
explanation.

Les

[Thomas Matthews]

Les Coover wrote:

I am taking a C programming class, we get into a little C++. I understand
that C++ is used to build many different types of applications
including Microsoft Office Products
http://www.research.att.com/~bs/applications.html

The code we write is run either in a UNIX or MS-DOS window. I was wondering
how they develop the sophisticated GUI windows using
C++ programs. I'm not looking for a technical explanation just a brief
explanation.

Les

Graphics (the 'G' in GUI) are a platform specific issue which is not
discussed in this newsgroup. The _standard_ C language has no
facilities for graphics, you will have to use platform specific
functions.

As for how GUIs are developed, that would better be discussed in
news:comp.programming or a graphics newsgroup.

For the C++ language, which doesn't have standard facilities for
graphics either, you want to the newsgroup down the hall at
news:comp.lang.c++. See the FAQs below.

--
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

[Mike Wahler]

"Les Coover" <lc******@cox.net.spam> wrote in message
news:1W*****************@news1.central.cox.net...

I am taking a C programming class, we get into a little C++. I understand
that C++ is used to build many different types of applications
including Microsoft Office Products
http://www.research.att.com/~bs/applications.html

The code we write is run either in a UNIX or MS-DOS window. I was wondering how they develop the sophisticated GUI windows using
C++ programs. I'm not looking for a technical explanation just a brief
explanation.

Platform-specific extensions and libraries, e.g. the
Win32 API, special keywords such as MS's 'fastcall',
'cdecl', etc. All this is extremely dependent upon
the host environment, so it's not covered by the
platform-dependent C language discusses here.
Standard C i/o is abstracted as 'streams of characters'.
That is, the smallest unit that can be transferred
to/from a standard C program is a character (byte).

-Mike

[Mike Wahler]

"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:t0***************@newsread4.news.pas.earthlin k.net...

[snip]

the host environment, so it's not covered by the
platform-dependent C language discusses here.

"platform-independent C language discussed here".

More coffee! :-)

-Mike

[Malcolm]

"Les Coover" <lc******@cox.net.spam> wrote in message

The code we write is run either in a UNIX or MS-DOS window. I
was wondering how they develop the sophisticated GUI windows using
C++ programs. I'm not looking for a technical explanation just a brief
explanation.

Generally what happens is that the main functionality of the platform is
written in a mixture of C and assembler. This is visible to an applications
programmer as a list of C functions. Often functions with C linkage can be
called from other programming languages as well.
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.
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. Microsoft's Microsoft Foundation Class contains a "wizard" which
produces skeleton C++ code which you then fill in with your application.

[Les Coover]

Thank you Malcolm,

great information!
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:bk**********@news7.svr.pol.co.uk...

"Les Coover" <lc******@cox.net.spam> wrote in message

The code we write is run either in a UNIX or MS-DOS window. I
was wondering how they develop the sophisticated GUI windows using
C++ programs. I'm not looking for a technical explanation just a brief
explanation.
Generally what happens is that the main functionality of the platform is
written in a mixture of C and assembler. This is visible to an

applications programmer as a list of C functions. Often functions with C linkage can be
called from other programming languages as well.
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.
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. Microsoft's Microsoft Foundation Class contains a "wizard" which produces skeleton C++ code which you then fill in with your application.

[jacob navia]

----- Original Message -----
From: "Malcolm" <ma*****@55bank.freeserve.co.uk>
Newsgroups: comp.lang.c
Sent: Tuesday, September 23, 2003 8:03 PM
Subject: Re: GUI ?
[snip]

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.
C is much simpler than C++, and with some syntactic improvements, can be
used to do whatever you want to do.

Besides, one of the advantages of using C is that the API used changes very slowly,
if at all.

C++ language interfaces suffer from their name mangling schema, that makes
impossible to interchange binary code.

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.
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.
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.
Microsoft's Microsoft Foundation Class contains a "wizard" which
produces skeleton C++ code which you then fill in with your application.

Yes. Lcc-win32 too, and it is a C application. It will not generate any
calls to some intermediate stuff code, that ties you to some particular
language.

It will generate calls to the Win32 API itself. Your program will run in all windows
compatible systems, as long as Microsoft supports that. There is no intermediate
library that should be ported to 64 bits, nor is your code tied to MFC.

The advantages of C in GUI applications are obvious.

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.

More important, the C program is very easy to understand and debug. C is
quite transparent.

Implicitely instantiated default template members?
Impenetrable class hierarchies that makes debugging a nightmare?

No thanks. There is enough nightmares with C already, to add some.
Keeping down complexity (simplifying) means making programming languages
easier to read.

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.

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.

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...

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.

This is a limitation, but I think the crux of this matter is precisely finding the
limits, where you should *stop*.

The problem of this feature, that looks quite normal at first sight, is that it
can lead to obscurity in the intent of the programmer. In complex environments,
with many data types and conversions specified, following all consequences of
adding just one conversion would be an enormous task.

Adding just a new small conversion would have the automatic side-effect of
making a great number of new conversions available, many of them not
foreseen at all by the programmer since new and longer paths are possible.

This is my justification for stopping here. C++ doesn't stop of course, and adds
the class hierarchy with multiple inheritance so that the original simple idea
becomes specifications that are no longer comprehensible by a human being...

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.

Templates come next, but I am getting off topic. Sorry.

jacob

[Jeff]

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:bk**********@news7.svr.pol.co.uk...

"Les Coover" <lc******@cox.net.spam> wrote in message

The code we write is run either in a UNIX or MS-DOS window. I
was wondering how they develop the sophisticated GUI windows using
C++ programs. I'm not looking for a technical explanation just a brief
explanation.
Generally what happens is that the main functionality of the platform is
written in a mixture of C and assembler. This is visible to an

applications programmer as a list of C functions. Often functions with C linkage can be
called from other programming languages as well.
Because C++ offers greater power than C,
What ? I strongly disagree with you, can you provide some evidence ?
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.
Button and scrollbars are created by windows API (for example,
CreateWindowEx() can create all the window, button, listbox, scrollbar,
text, combobox, etc.... ). You can call this API by any languages, including
C , C++, VB, etc. It is nothing related to the language itself.

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
No. The most common way to create GUI application is using Resource Script.
You use the Resource Script editor from your IDE to "draw" the GUI, and save
as a "rc" file. After all, you can use the resource in your code and create
a GUI anytime.
interface. Microsoft's Microsoft Foundation Class contains a "wizard"

which

There is two way to create application by Visual Sutdio.

1. Use the MFC to do the basic things for you. It give you some overhead
and you never know what it is doing actually. When you use other development
tool (eg, your company do not have Visual Studio), you can't do anything.

2. Create the window application directly by calling Win32 API. You control
all the things and you gain the performance. You will learn the windows
functions and you can use them in any language.
--
Jeff
-je6543 at yahoo.com

[Richard Bos]

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

Because C++ offers greater power than C,

[points at Malcolm]
[laughs]
[redirects Malcolm to
<http://catb.org/esr/jargon/html/T/Turing-tar-pit.html>, item 2]

Richard

[Malcolm]

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

Because C++ offers greater power than C,

[points at Malcolm]
[laughs]

Yeah, OK I know that most computer languages, including C and C++, are
Turing equivalent. However I needed to expalin to the OP why anyone would
bother to build a C++ interface on top of a C API.

The reason is that C is very clumsy in expressing "is a" relationships. If
you want a button which "is a" window, and flyoff button which "is a"
button", then a C++ class hierarchy will express those connections between
the objects very well. In C on the other hand you would have to resort to
devices such as nested structures.

[Malcolm]

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

Because C++ offers greater power than C,

[points at Malcolm]
[laughs]

Yeah, OK I know that most computer languages, including C and C++, are
Turing equivalent. However I needed to expalin to the OP why anyone would
bother to build a C++ interface on top of a C API.

The reason is that C is very clumsy in expressing "is a" relationships. If
you want a button which "is a" window, and flyoff button which "is a"
button", then a C++ class hierarchy will express those connections between
the objects very well. In C on the other hand you would have to resort to
devices such as nested structures.

[Thomas Matthews]

jacob navia wrote:

----- Original Message -----
From: "Malcolm" <ma*****@55bank.freeserve.co.uk>
Newsgroups: comp.lang.c
Sent: Tuesday, September 23, 2003 8:03 PM
Subject: Re: GUI ?
[snip]

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.
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.

C is much simpler than C++, and with some syntactic improvements, can be
used to do whatever you want to do.
I agree with the complexity issue. However, both languages can be used
to "do whatever you want to do."

Besides, one of the advantages of using C is that the API used changes very slowly,
if at all.
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.
C++ language interfaces suffer from their name mangling schema, that makes
impossible to interchange binary code.
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.

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.
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?
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.

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.

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.
The advantages of C in GUI applications are obvious.
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.

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. 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.

More important, the C program is very easy to understand and debug. C is
quite transparent.
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?"

Implicitely instantiated default template members?
Impenetrable class hierarchies that makes debugging a nightmare?
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.
No thanks. There is enough nightmares with C already, to add some.
Keeping down complexity (simplifying) means making programming languages
easier to read.
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.

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.
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.
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.
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.

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...
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.
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.
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]This is my justification for stopping here. C++ doesn't stop of course, and adds the class hierarchy with multiple inheritance so that the original simple idea
becomes specifications that are no longer comprehensible by a human being...
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.
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.
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?


Templates come next, but I am getting off topic. Sorry.
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."

jacob

--
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

[jacob navia]

"Thomas Matthews" <Th**********************@sbcglobal.net> wrote in message
news:5P*****************@newssvr33.news.prodigy.co m...

jacob navia wrote:

Besides, one of the advantages of using C is that the API used changes very slowly,
if at all.

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.

C++ language interfaces suffer from their name mangling schema, that makes
impossible to interchange binary code.
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]

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.
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.

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.

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.

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.

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.
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.

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.
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 news:comp.lang.c++ 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.

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.

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!

:-)

Templates come next, but I am getting off topic. Sorry.

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.