Practical applications on C++

[anchitgood]

Hey, i have to prepare my training report on C++, but I couldn't find
any satisfactory names of practical applications that are developed
using C++. Can u suggest any?

[alasham.said]

On Jul 17, 11:11 am, [e-mail] wrote:

Hey, i have to prepare my training report on C++, but I couldn't find
any satisfactory names of practical applications that are developed
using C++. Can u suggest any?

Hello,

It is hard to believe that you have done a thorough research. In any
case:

http://www.research.att.com/~bs/applications.html

Regards.

[ManicQin]

On Jul 17, 11:11*am, [e-mail] wrote:

Hey, i have to prepare my training report on C++, but I couldn't find
any satisfactory names of *practical applications that are developed
using C++. Can u suggest any?

Are you for real?
Maybe I didn't understand your question correctly,
Are you looking for an example for systems that
were coded in C++?

Or are you looking for systems that Could ONLY
be written in C++?

[Andy Champ]

an********@gmail.com wrote:

Hey, i have to prepare my training report on C++, but I couldn't find
any satisfactory names of practical applications that are developed
using C++. Can u suggest any?

Well I don't want to make you look too far, or at something you won't
have seen. How about Windows?

Andy

[Sherman Pendley]

Andy Champ <no****@nospam.comwrites:

an********@gmail.com wrote:

>Hey, i have to prepare my training report on C++, but I couldn't find
any satisfactory names of practical applications that are developed
using C++. Can u suggest any?

Well I don't want to make you look too far, or at something you won't
have seen. How about Windows?

He said *practical*. :-)

sherm--

--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net

[Mirco Wahab]

Andy Champ wrote:

an********@gmail.com wrote:

>Hey, i have to prepare my training report on C++, but I couldn't find
any satisfactory names of practical applications that are developed
using C++. Can u suggest any?

Well I don't want to make you look too far, or at something you won't
have seen. How about Windows?

If you think of Windows 5 (2000/XP), than
that's almost entirely written in C, only
some marginal modules are written in C++.

Regards

M.

[ManicQin]

On Jul 18, 12:50*am, Mirco Wahab <[e-mail]:

Well I don't want to make you look too far, or at something you won't
have seen. *How about Windows?

If you think of Windows 5 (2000/XP), than
that's almost entirely written in C, only
some marginal modules are written in C++.

It's a problem identifying system that were written in C++.
You can use a C++ compiler without using templates\classes.
You can use a C++ compiler without using OO.
So what is considered a "pure" C++ system?
I know that most of the systems in my company are
Hybrids of C++ and C how can you classify them?

[James Kanze]

On Jul 20, 9:03 am, ManicQin <[e-mail]:

On Jul 18, 12:50 am, Mirco Wahab <[e-mail]:

Well I don't want to make you look too far, or at
something you won't have seen. How about Windows?

If you think of Windows 5 (2000/XP), than
that's almost entirely written in C, only
some marginal modules are written in C++.

It's a problem identifying system that were written in C++.
You can use a C++ compiler without using templates\classes.
You can use a C++ compiler without using OO.
So what is considered a "pure" C++ system?
I know that most of the systems in my company are
Hybrids of C++ and C how can you classify them?

As hybrids of C++ and C?

I'm not sure what all this business of "if you don't use X, it's
not C++" is supposed to mean. That <vectorisn't C++, because
it doesn't use polymorphism? C++ provides a very large number
of features, to support many different paradigms. If you don't
use some feature, because some other paradigm is more
appropriate for the problem, you're still using C++.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[ManicQin]

On Jul 20, 10:58*am, James Kanze <[e-mail]:

I'm not sure what all this business of "if you don't use X, it's
not C++" is supposed to mean. *That <vectorisn't C++, because
it doesn't use polymorphism? *C++ provides a very large number
of features, to support many different paradigms. *If you don't
use some feature, because some other paradigm is more
appropriate for the problem, you're still using C++.

I agree with you but what I meant is if I write:
//snip
#include <stdio.h>
void main()
{
printf("hello world");
}
//
and compiling it in an c++ compiler is it a c++ program or a c? (I
gave a bit exaggerated example)
it's a c syntax but c++ will have no problem compiling it (except the
void main() warning )

[Mirco Wahab]

ManicQin wrote:

I agree with you but what I meant is if I write:
//snip
#include <stdio.h>
void main()
{
printf("hello world");
}
//
and compiling it in an c++ compiler is it a c++ program or a c? (I
gave a bit exaggerated example)
it's a c syntax but c++ will have no problem compiling it (except the
void main() warning )

I'd use the heuristic approach: If you save this to manicqin.c,
then it's clearly a C program. Use manicqin.cpp, manicqin.cxx
or manicqin.cc - and I'd sure count it as a C++ program and
evaluate it as C++. Wouldn't you too?

Regards & scnr

Mirco

[ManicQin]

On Jul 22, 1:58*pm, Mirco Wahab <[e-mail]:

I'd use the heuristic approach: If you save this to manicqin.c,
then it's clearly a C program. Use manicqin.cpp, manicqin.cxx
or manicqin.cc - and I'd sure count it as a C++ program and
evaluate it as C++. Wouldn't you too?

Regards & scnr

Mirco

SO... ... ...
If I save it as a .cs can I call it C#? I'm just kidding.
With no other approach coming to my mind I will have to agree.

[Mirco Wahab]

ManicQin wrote:

On Jul 22, 1:58 pm, Mirco Wahab <[e-mail]:

>I'd use the heuristic approach: If you save this to manicqin.c,
then it's clearly a C program. Use manicqin.cpp, manicqin.cxx
or manicqin.cc - and I'd sure count it as a C++ program and
evaluate it as C++. Wouldn't you too?

SO... ... ...
If I save it as a .cs can I call it C#? I'm just kidding.

No kidding here. Theres one example here:
http://perl.plover.com/obfuscated/bestever.pl

Save it as .ps and/or copy it directly to your (PS-)printer,
it'll be Postscript and print something there. Save it
as .pl and run it on the command line, it'll be a Perl
file and print (almost) the same on stdout.

So this *can* matter sometimes ;-)

Regards

M.

[red floyd]

ManicQin wrote:

On Jul 20, 10:58 am, James Kanze <[e-mail]:

>I'm not sure what all this business of "if you don't use X, it's
not C++" is supposed to mean. That <vectorisn't C++, because
it doesn't use polymorphism? C++ provides a very large number
of features, to support many different paradigms. If you don't
use some feature, because some other paradigm is more
appropriate for the problem, you're still using C++.

I agree with you but what I meant is if I write:
//snip
#include <stdio.h>
void main()
{
printf("hello world");
}
//
and compiling it in an c++ compiler is it a c++ program or a c

It's not C++. In C++, main() returns int.

[ManicQin]

On Jul 23, 8:00*am, red floyd <[e-mail]:

It's not C++. *In C++, main() returns int.

so compiling:
int main() { return 0; }
in a C compiler would fail? (no...)
Or is it a new Hybrid? (instead of working C with classes ...
it's the new striped C++)

what about double main() { return 0.0; } (heresy!!!)
what language is it?

anyway I could give you other examples, they are all
not important. thanks to back compatibility the two languages
are bonded.

[James Kanze]

On Jul 22, 1:53 pm, ManicQin <[e-mail]:

On Jul 20, 10:58 am, James Kanze <[e-mail]:

I'm not sure what all this business of "if you don't use X, it's
not C++" is supposed to mean. That <vectorisn't C++, because
it doesn't use polymorphism? C++ provides a very large number
of features, to support many different paradigms. If you don't
use some feature, because some other paradigm is more
appropriate for the problem, you're still using C++.

I agree with you but what I meant is if I write:
//snip
#include <stdio.h>
void main()
{
printf("hello world");}
//

and compiling it in an c++ compiler is it a c++ program or a
c? (I gave a bit exaggerated example) it's a c syntax but c++
will have no problem compiling it (except the void main()
warning )

Well, it's not a legal program in either language; both
languages require the return type of main to be int. (C allows
the compiler to support void main() as an extension, C++
requires a diagnostic. And if you change the return type to
int, falling of the end of a function which returns a value is
undefined behavior in C.)

Other than that: if you put the code in a file with an extension
.cpp or .cc, it's a C++ program. In such simple cases, you
can't tell the difference, but typical C won't compile with a
C++ compiler (and vice versa, of course).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 23, 8:35 am, ManicQin <[e-mail]:

On Jul 23, 8:00 am, red floyd <[e-mail]:

It's not C++. In C++, main() returns int.

so compiling:
int main() { return 0; }
in a C compiler would fail? (no...)

If the compiler is conformant, it will output a diagnostic.
With the compilers I have, it either fails, or causes a
diagnostic about being anachronistic. Including if I compile it
as C (where a compiler is allowed to accept it without a
diagnostic).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[ManicQin]

On Jul 23, 10:26*am, James Kanze <[e-mail]:

but typical C won't compile with a
C++ compiler

?!? How come ?!?
maybe I just didn't understand you.
Isn't C++ fully back Compatible with C?

[Pete Becker]

On 2008-07-23 04:26:11 -0400, James Kanze <ja*********@gmail.comsaid:

>
Well, it's not a legal program in either language; both
languages require the return type of main to be int. (C allows
the compiler to support void main() as an extension, C++
requires a diagnostic.

As far as I can see, both languages require the same thing here. I
don't have the C90 standard handy, but C99 says that main "shall be
defined with a return type of int ...". Similarly, in C++, main "shall
have a return type of int ...". In both cases, a return type of void is
a valid extension: a conforming compiler must issue a diagnostic, and
having done that, it can do whatever its implementor chooses.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[Lionel B]

On Wed, 23 Jul 2008 02:15:36 -0700, ManicQin wrote:

On Jul 23, 10:26Â*am, James Kanze <[e-mail]:

>but typical C won't compile with a
C++ compiler

?!? How come ?!?
maybe I just didn't understand you.
Isn't C++ fully back Compatible with C?

Not quite. See:

http://www.parashift.com/c++-faq-lit....html#faq-6.11

--
Lionel B

[James Kanze]

On Jul 23, 11:56 am, Pete Becker <[e-mail]:

On 2008-07-23 04:26:11 -0400, James Kanze <[e-mail]:

Well, it's not a legal program in either language; both
languages require the return type of main to be int. (C
allows the compiler to support void main() as an extension,
C++ requires a diagnostic.

As far as I can see, both languages require the same thing
here. I don't have the C90 standard handy, but C99 says that
main "shall be defined with a return type of int ...".
Similarly, in C++, main "shall have a return type of int ...".
In both cases, a return type of void is a valid extension: a
conforming compiler must issue a diagnostic, and having done
that, it can do whatever its implementor chooses.

There's a subtle difference in the way the standards are worded.
In C++, an error requires a diagnostic unless it is specified to
be undefined behavior; in C, an error is undefined behavior
unless it is specified to require a diagnostic. Beyond that,
of course, there are some general statements: violating a
constraint on an operator in an expression requires a diagnostic
in C, because there is a general statement which says so, even
if there isn't a specific statement for each constraint. And in
both languages, if the standard neglects to specify the
behavior, it is undefined. But as far as I can tell, none of
these cases affect the return value of main.

Note too the difference in wording concerning main. In C++: "It
shall have a return type of type int, but otherwise its type is
implementation-defined." (The "otherwise" is, IMHO,
significant.) In C: "[...] or in some other
implementation-defined manner." In context, it's not really
clear if that statement applies just to the parameters, or to
the function signature in general. I'd interpret it as
applying to the function signature in general, but I can easily
understand the other interpretation as well. Regardless,
however; C doesn't require a diagnostic if you define main with
a signature which isn't supported; C++ does.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Pete Becker]

On 2008-07-23 17:50:50 -0400, James Kanze <ja*********@gmail.comsaid:

>
There's a subtle difference in the way the standards are worded.
In C++, an error requires a diagnostic unless it is specified to
be undefined behavior; in C, an error is undefined behavior
unless it is specified to require a diagnostic.

C99, 5.1.1.3 says:

A conforming implementation shall produce at least one diagnostic
message (identi�ed in
an implementation-de�ned manner) if a preprocessing translation unit or
translation unit
contains a violation of any syntax rule or constraint, even if the
behavior is also explicitly
speci�ed as unde�ned or implementation-de�ned. Diagnostic messages need not be
produced in other circumstances. [footnote omitted]

Beyond that,
of course, there are some general statements: violating a
constraint on an operator in an expression requires a diagnostic
in C, because there is a general statement which says so, even
if there isn't a specific statement for each constraint. And in
both languages, if the standard neglects to specify the
behavior, it is undefined. But as far as I can tell, none of
these cases affect the return value of main.

Note too the difference in wording concerning main. In C++: "It
shall have a return type of type int, but otherwise its type is
implementation-defined." (The "otherwise" is, IMHO,
significant.) In C: "[...] or in some other
implementation-defined manner." In context, it's not really
clear if that statement applies just to the parameters, or to
the function signature in general. I'd interpret it as
applying to the function signature in general, but I can easily
understand the other interpretation as well. Regardless,
however; C doesn't require a diagnostic if you define main with
a signature which isn't supported; C++ does.

It's a constraint violation, even though the behavior is explicitly
specified as implementation-defined. So 5.1.1.3 requires a diagnostic.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[James Kanze]

On Jul 24, 2:03 am, Pete Becker <[e-mail]:

On 2008-07-23 17:50:50 -0400, James Kanze <[e-mail]:

There's a subtle difference in the way the standards are
worded. In C++, an error requires a diagnostic unless it is
specified to be undefined behavior; in C, an error is
undefined behavior unless it is specified to require a
diagnostic.

C99, 5.1.1.3 says:

A conforming implementation shall produce at least one
diagnostic message (identified in an implementation-defined
manner) if a preprocessing translation unit or translation
unit contains a violation of any syntax rule or constraint,
even if the behavior is also explicitly specified as
undefined or implementation-defined. Diagnostic messages
need not be produced in other circumstances. [footnote
omitted] Beyond that, of course, there are some general
statements: violating a constraint on an operator in an
expression requires a diagnostic in C, because there is a
general statement which says so, even if there isn't a
specific statement for each constraint. And in both
languages, if the standard neglects to specify the behavior,
it is undefined. But as far as I can tell, none of these
cases affect the return value of main.

Note too the difference in wording concerning main. In C++:
"It shall have a return type of type int, but otherwise its
type is implementation-defined." (The "otherwise" is, IMHO,
significant.) In C: "[...] or in some other
implementation-defined manner." In context, it's not really
clear if that statement applies just to the parameters, or
to the function signature in general. I'd interpret it as
applying to the function signature in general, but I can
easily understand the other interpretation as well.
Regardless, however; C doesn't require a diagnostic if you
define main with a signature which isn't supported; C++
does.

It's a constraint violation, even though the behavior is
explicitly specified as implementation-defined.

I was under the impression that something only qualified as a
constraint violation if it were in a paragraph with the heading
"constraints" (but I could easily be wrong).

I also think that the most natural interpretation of the "[...];
or in some other implementation defined manner" in §5.1.2.2.1/1
has it applying to the complete clause which precedes, including
the "defined with a return type of int", so that an
implementation can legally define a version of main which takes
a void (or a double, or a char const*) as a return value. (Note
the difference with respect to the C++ standard, which says "It
shall have a return type of type int, but otherwise its type is
implementation-defined." There's a big difference between "but
otherwise" and simply "or".

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Pete Becker]

On 2008-07-24 03:46:06 -0400, James Kanze <ja*********@gmail.comsaid:

On Jul 24, 2:03 am, Pete Becker <[e-mail]:

>On 2008-07-23 17:50:50 -0400, James Kanze <[e-mail]:

>>There's a subtle difference in the way the standards are
worded. In C++, an error requires a diagnostic unless it is
specified to be undefined behavior; in C, an error is
undefined behavior unless it is specified to require a
diagnostic.

>C99, 5.1.1.3 says:

>>A conforming implementation shall produce at least one
diagnostic message (identified in an implementation-defined
manner) if a preprocessing translation unit or translation
unit contains a violation of any syntax rule or constraint,
even if the behavior is also explicitly specified as
undefined or implementation-defined. Diagnostic messages
need not be produced in other circumstances. [footnote
omitted] Beyond that, of course, there are some general
statements: violating a constraint on an operator in an
expression requires a diagnostic in C, because there is a
general statement which says so, even if there isn't a
specific statement for each constraint. And in both
languages, if the standard neglects to specify the behavior,
it is undefined. But as far as I can tell, none of these
cases affect the return value of main.

>>Note too the difference in wording concerning main. In C++:
"It shall have a return type of type int, but otherwise its
type is implementation-defined." (The "otherwise" is, IMHO,
significant.) In C: "[...] or in some other
implementation-defined manner." In context, it's not really
clear if that statement applies just to the parameters, or
to the function signature in general. I'd interpret it as
applying to the function signature in general, but I can
easily understand the other interpretation as well.
Regardless, however; C doesn't require a diagnostic if you
define main with a signature which isn't supported; C++
does.

>It's a constraint violation, even though the behavior is
explicitly specified as implementation-defined.

I was under the impression that something only qualified as a
constraint violation if it were in a paragraph with the heading
"constraints" (but I could easily be wrong).

I think you're right there. But I misspoke: it's a violation of a
syntax rule, and 5.1.1.3 still requires a diagnostic.

>
I also think that the most natural interpretation of the "[...];
or in some other implementation defined manner" in §5.1.2.2.1/1
has it applying to the complete clause which precedes, including
the "defined with a return type of int", so that an
implementation can legally define a version of main which takes
a void (or a double, or a char const*) as a return value.

If that was the intention, it could have been said much more simply:

the arguments and return type of main are implementation-defined.

But note that it's not a matter of whether an implementation "can
legally define a version of main which takes a void". Clearly it can:
that's what that last clause says. The question is whether it must
issue a diagnostic, which is what 5.1.1.3 requires.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[James Kanze]

On Jul 24, 10:26 am, "Alf P. Steinbach" <[e-mail]:

* James Kanze:

I was under the impression that something only qualified as a
constraint violation if it were in a paragraph with the heading
"constraints" (but I could easily be wrong).

I also think that the most natural interpretation of the "[...];
or in some other implementation defined manner" in §5.1.2.2.1/1
has it applying to the complete clause which precedes, including
the "defined with a return type of int", so that an
implementation can legally define a version of main which takes
a void (or a double, or a char const*) as a return value. (Note
the difference with respect to the C++ standard, which says "It
shall have a return type of type int, but otherwise its type is
implementation-defined." There's a big difference between "but
otherwise" and simply "or".

Summing up: when the standard is unclear it is unclear.

I think the only thing to conclude from that is that perhaps
the C standard could have been clarified a bit. If your
interpretation should be correct, then e.g. Bjarne Stroustrup
would have to fix his FAQ, since he (with access to the folks
who created C) maintains that C never allowed 'int main'.

It certainly wasn't allowed in early C compilers, or in
traditional C. The C90 only allowed the two defined signatures,
but because, IMHO, other signatures were undefined behavior, an
implementation could define them. All of the Unix
implementations of C I know also defined a third variant, with
an additional char** argument. (I just looked it up, and I'll
admit, it surprised me; I had always believed that an
implementation was free to define additional signatures in C90,
as it is in C99.)

Practically, of course, it doesn't matter. Implementations will
do what they want, regardless of the standard. And if you want
to be portable (true C or C++, independently of the compiler),
there are only two signatures which work, and both return int.

[...]

Actually I would like a little code-phrase like "[note:
different member of the committee have at least three
different opinions about what this means]" added where
applicable. :-)

That probably applies to 90% of the standard:-).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]