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?

On Jul 17, 11:11 am, anchitg...@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?

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.

On Jul 17, 11:11am, anchitg...@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?

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

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

Andy Champ <no.way@nospam.com> writes:

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

Andy Champ wrote:
> anchitgood@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.

anchitgood@gmail.com writes:
>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

On Jul 18, 12:50am, Mirco Wahab <wahab-m...@gmx.de> wrote:

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

On Jul 20, 9:03 am, ManicQin <Manic...@gmail.com> wrote:
> On Jul 18, 12:50 am, Mirco Wahab <wahab-m...@gmx.de> wrote:

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

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jul 20, 10:58am, James Kanze <james.ka...@gmail.com> wrote:

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

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

On Jul 22, 1:58pm, Mirco Wahab <wa...@chemie.uni-halle.de> wrote:

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

ManicQin wrote:
> On Jul 22, 1:58 pm, Mirco Wahab <wa...@chemie.uni-halle.de> wrote:
>> 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.

ManicQin wrote:
> On Jul 20, 10:58 am, James Kanze <james.ka...@gmail.com> wrote:
>
>> 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

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

On Jul 23, 8:00am, red floyd <no.spam.h...@example.com> wrote:

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

On Jul 22, 1:53 pm, ManicQin <Manic...@gmail.com> wrote:
> On Jul 20, 10:58 am, James Kanze <james.ka...@gmail.com> wrote:

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

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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jul 23, 8:35 am, ManicQin <Manic...@gmail.com> wrote:
> On Jul 23, 8:00 am, red floyd <no.spam.h...@example.com> wrote:

> > 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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jul 23, 10:26am, James Kanze <james.ka...@gmail.com> wrote:

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

On 2008-07-23 04:26:11 -0400, James Kanze <james.kanze@gmail.com> said:

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

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

> On Jul 23, 10:26Âam, James Kanze <james.ka...@gmail.com> wrote:
>
>> 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

On Jul 23, 11:56 am, Pete Becker <p...@versatilecoding.com> wrote:
> On 2008-07-23 04:26:11 -0400, James Kanze <james.ka...@gmail.com> said:

> > 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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On 2008-07-23 17:50:50 -0400, James Kanze <james.kanze@gmail.com> said:

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

On Jul 24, 2:03 am, Pete Becker <p...@versatilecoding.com> wrote:
> On 2008-07-23 17:50:50 -0400, James Kanze <james.ka...@gmail.com> said:
> > 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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

* 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'. Interestingly,
in one thread in this group long ago, when I mentioned off-hand that he'd used
'void main' in second edition of TCPPPL, I think it was, he joined in and
couldn't believe that and asked for reference (which I gave). He he. As I recall
he also corrected my "nobody's prefect", which I'd intentionally mispeled...

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


Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

* Alf P. Steinbach:
> * 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'.

Argh, keyboard devil intervened, I meant to type 'void main'.


> Interestingly, in one thread in this group long
> ago, when I mentioned off-hand that he'd used 'void main' in second
> edition of TCPPPL, I think it was, he joined in and couldn't believe
> that and asked for reference (which I gave). He he. As I recall he also
> corrected my "nobody's prefect", which I'd intentionally mispeled...
>
> 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. :-)
>
>
> Cheers,
>
> - Alf
>


--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?