Java vs C++

Java has packages (libraries) for everything. EVERYTHING.

Instead, C++ is too poor in its classes.

Is there a concept to extend C++ with other standard libraries, about
multithreading, socket programming etc?

I do not speak about libraries programmed only in one platform (e.g. MFC)
but about standard C++ libraries.

Is there a plan to add in C++ those capabilities in the future?

Why we not use standard C++ for e.g. socket programming?
Why we must move to Java for a non-platform specific program?
Regards
Paul Gessos

[stephan beal]

- Chameleon - wrote:

Is there a concept to extend C++ with other standard libraries, about
multithreading, socket programming etc?

www.boost.org

--
----- stephan beal
Registered Linux User #71917 http://counter.li.org
I speak for myself, not my employer. Contents may
be hot. Slippery when wet. Reading disclaimers makes
you go blind. Writing them is worse. You have been Warned.

[Mike Smith]

<- Chameleon -> wrote:

Java has packages (libraries) for everything. EVERYTHING.

Instead, C++ is too poor in its classes.

Is there a concept to extend C++ with other standard libraries, about
multithreading, socket programming etc?

I do not speak about libraries programmed only in one platform (e.g. MFC)
but about standard C++ libraries.

Is there a plan to add in C++ those capabilities in the future?

Why we not use standard C++ for e.g. socket programming?
Why we must move to Java for a non-platform specific program?

Because in C++-land, standard really means *standard*; i.e. those
features which are available to *all* platforms that can run C++. Not
all C++-capable platforms have TCP/IP stacks, for instance. Or
threading capability, or graphics displays, etc. therefore these things
are considered nonstandard. That doesn't mean, of course, that you
can't *have* graphics, or sockets, or threads, but only by using
third-party libraries that are not part of the standard language itself.

--
Mike Smith

[Socketd]

On Thu, 17 Jul 2003 21:06:09 +0300
"<- Chameleon ->" <ch******@hotmail.NOSPAM.com> wrote:

Why we not use standard C++ for e.g. socket programming?
Why we must move to Java for a non-platform specific program?

www.wxwindows.org

br
socketd

> > Java has packages (libraries) for everything. EVERYTHING.

Instead, C++ is too poor in its classes.

Is there a concept to extend C++ with other standard libraries, about
multithreading, socket programming etc?

I do not speak about libraries programmed only in one platform (e.g. MFC) but about standard C++ libraries.

Is there a plan to add in C++ those capabilities in the future?

Why we not use standard C++ for e.g. socket programming?
Why we must move to Java for a non-platform specific program?

Because in C++-land, standard really means *standard*; i.e. those
features which are available to *all* platforms that can run C++. Not
all C++-capable platforms have TCP/IP stacks, for instance. Or
threading capability, or graphics displays, etc. therefore these things
are considered nonstandard. That doesn't mean, of course, that you
can't *have* graphics, or sockets, or threads, but only by using
third-party libraries that are not part of the standard language itself.

there is a logic...
but of course this logic decreases too much abilities of C++ (I speak always
for cross-platform developments)
I mean: In how many machines Java is not working?
And what is the problem if my C++ program says in Unix or DOS console: "This
program requires graphical interface"?

All the machine unsuported functions can return an error message. (such as
fopen() returns 0)

do you agree?

Regards
Paul Gessos

>

Why we not use standard C++ for e.g. socket programming?
Why we must move to Java for a non-platform specific program?

www.wxwindows.org

very usefull! Thanks!

[Rayiner Hashem]

> multithreading, socket programming etc?
If you want free and cross-platform, look at the Adaptive
Communications library. It supports both multithreading and network
programming, as well as IPC, shared memory, filesystem access, dynamic
module loading, and XML parsing. For the GUI bit, use wxwindows if you
want something free and Qt if you are willing to pay.

Why we must move to Java for a non-platform specific program?

You don't. You just need to spend some time looking for libraries
appropriate to your application and researching the best ones to use.
The fact that stuff like ACE is available should be common knowledge
to C++ programmers. If it isn't for you, Google is always there to
bail you out.

[E. Robert Tisdale]

Paul Gessos wrote:

Java has packages (libraries) for everything. EVERYTHING.

Instead, C++ is too poor in its classes.
There are hundreds of times as many C++ classes.
Is there a concept to extend C++ with other standard libraries,
about multithreading, socket programming etc?
There is *no* Java standard.
There are *no* standard Java libraries.
I do not speak about libraries programmed only in one platform (e.g. MFC)
but about standard C++ libraries.
Then don't speak about the Java libraries.
They won't port to anything that doesn't implement JVM.
Is there a plan to add in C++ those capabilities in the future?
I hope not.
C++ compiler developers are *not* generally the best library developers.
Why we not use standard C++ for e.g. socket programming?
Because there is no reason why sockets should be included
in the C++ standard library.
Why we must move to Java for a non-platform specific program?

I agree that there should be standard library APIs
which include C++ language bindings for sockets
and all of the other objects that you find in the Java library.
But these standards have nothing to do
with the ANSI/ISO C++ language standards
and should be specified separately.

Why don't you propose a standard API (ADT plus C++ language binding)
for a socket library? If you can get people interested, you may want
to visit the American National Standards Institute (ANSI) web site:

http://www.ansi.org/

and investigate Standards Activities to find out how to work through
the standards approval process.

Are you a C++ theologian - dogmatist?
Everyone which ask new ideas is troll?

Is there a concept to extend C++ with other standard libraries,
about multithreading, socket programming etc?

There is *no* Java standard.
There are *no* standard Java libraries.

I do not speak about libraries programmed only in one platform (e.g. MFC) but about standard C++ libraries.

Then don't speak about the Java libraries.
They won't port to anything that doesn't implement JVM.

Is there a plan to add in C++ those capabilities in the future?

I hope not.
C++ compiler developers are *not* generally the best library developers.

Why we not use standard C++ for e.g. socket programming?

Because there is no reason why sockets should be included
in the C++ standard library.

Why we must move to Java for a non-platform specific program?

I agree that there should be standard library APIs
which include C++ language bindings for sockets
and all of the other objects that you find in the Java library.
But these standards have nothing to do
with the ANSI/ISO C++ language standards
and should be specified separately.

Why don't you propose a standard API (ADT plus C++ language binding)
for a socket library? If you can get people interested, you may want
to visit the American National Standards Institute (ANSI) web site:

http://www.ansi.org/

and investigate Standards Activities to find out how to work through
the standards approval process.

A standard API for a socket library, a managing windows library etc...

You are correct
I agree with you
Thanks!

Regards
Paul Gessos

[Mike Smith]

<- Chameleon -> wrote:

there is a logic...
but of course this logic decreases too much abilities of C++ (I speak always
for cross-platform developments)
I mean: In how many machines Java is not working?
I don't know exactly, but the number is greater for Java than for C++,
I'll bet.

Compare that to the question: How much work and cost is required to
create a C++ implementation for a platform, versus a Java implementation?
And what is the problem if my C++ program says in Unix or DOS console: "This
program requires graphical interface"?

All the machine unsuported functions can return an error message. (such as
fopen() returns 0)

do you agree?

It's not a question of whether I agree, but of whether the C++ standards
bodies agree, and apparently, they don't.

--
Mike Smith