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]

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]

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

 

[Mirco Wahab]

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.

 

[Stefan Ram]

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?

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

 

[ManicQin]

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]

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 <vector> isn'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++.

 

[ManicQin]

I'm not sure what all this business of "if you don't use X, it's
not C++" is supposed to mean.  That <vector> isn'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]

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]

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]

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]

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]

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]

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]

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

 

[ManicQin]

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?

 

[Lionel B]

?!? 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-lite/big-picture.html#faq-6.11

 

[James Kanze]

On 2008-07-23 04:26:11 -0400, James Kanze <[email protected]> said:

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]

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]

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