Some concepts (Maybe LOL maybe not...)

[Guest]

gcc provides the libc which have more functions than standard C libraries.
I saw in Windows API similar functions too, with identical parameters!
So, I ask again:
Why not, a committee specifies libraries which are not standard C++ libraries
but *all* compilers include these libraries as part of them?
I mean libraries like socket using, window managment, file system, thread using etc
These libraries with *identical API* in any compiler will be a powerfull tool for any programmer
and then, we can *anything* in C++ which is *cross-platfrom*.

Another concept is the ability to write WEB Applets with C++.
With these libraries I refer above, we can do anything.
For Applets the problem is that C++ Compiler produces natural binary files.
How Java works? Java sucks... Java compile the code to virtual opcodes
and then Virtual Machine converts any virtual opcode to a group of natural opcodes.
This is unacceptable and very bad idea.
A higher-level (than Assembly) Language which is cross-platform must not "converted"
to low-level and after compiled or interpreted.
The better solution is Applet will kept as source code and Virtual Machine compile the
Applet before run it.
However, many people don't want make public their code.
So, A "converter" must exist. This "converter" has this job:
It converts C++ Applet source code to a binary which is almost identical to source code
but comments are removed, classes have changed to simple C functions, spaces are removed
and every reserved word or operator (like for, if, ++, *) is converted to a binary pepresentation.
Now, it is more difficult to steal source code of Applet and compilation-time is shorter.
With this except of Applets you can write stand-alone applications exactly like Java but with C++ speed.

And then, Java will die!...


What is your opinion?

 

[Jack Klein]

gcc provides the libc which have more functions than standard C libraries.
I saw in Windows API similar functions too, with identical parameters!
So, I ask again:
Why not, a committee specifies libraries which are not standard C++ libraries
but *all* compilers include these libraries as part of them?

Don't you understand what "standard" means? What do you think the
difference would be between standard C++ libraries and libraries that
the standard requires all compilers to include?

I mean libraries like socket using, window managment, file system, thread using etc
These libraries with *identical API* in any compiler will be a powerfull tool for any programmer
and then, we can *anything* in C++ which is *cross-platfrom*.

What about C++ compilers for platforms that don't have networking,
graphical displays, or disk storage? HOW is the compiler vendor going
to provide support for these things since the actual hardware does not
exist?

There are already libraries for doing these things that are relatively
"cross platform" among common desk-top operating systems.

Another concept is the ability to write WEB Applets with C++.

It is already quite possible to write web applets with C++. A large
number of professional programmers make a living doing just that.

With these libraries I refer above, we can do anything.

Amazingly enough, without the libraries you referred to above, you can
do the same subset of "anything" that you could do with them.

For Applets the problem is that C++ Compiler produces natural binary files.

Most C++ compilers produce code that includes native binary
components. This is not, however, a language requirement.

How Java works? Java sucks... Java compile the code to virtual opcodes
and then Virtual Machine converts any virtual opcode to a group of natural opcodes.
This is unacceptable and very bad idea.
A higher-level (than Assembly) Language which is cross-platform must not "converted"
to low-level and after compiled or interpreted.
The better solution is Applet will kept as source code and Virtual Machine compile the
Applet before run it.
However, many people don't want make public their code.
So, A "converter" must exist. This "converter" has this job:
It converts C++ Applet source code to a binary which is almost identical to source code
but comments are removed, classes have changed to simple C functions, spaces are removed
and every reserved word or operator (like for, if, ++, *) is converted to a binary pepresentation.
Now, it is more difficult to steal source code of Applet and compilation-time is shorter.
With this except of Applets you can write stand-alone applications exactly like Java but with C++ speed.

And then, Java will die!...


What is your opinion?

There is nothing that specifies that C++ implementations can't
implement a JIT compile method that you advocate. Feel free to write
one.

As for the rest of it, you are another one of those people who seem to
think that desk top computers running the handful of operating systems
you are familiar with are all that matter, or perhaps even all that
exist.

More than 95% of the processors produced in the world every year are
not the Pentiums, SPARCs, or PowerPCs that happen to power desk top
computers. They are used in printers, hard disk drives, modems,
automobile engines, medical devices, DVD players, routers, and many
more products that you could begin to dream of. These devices do not
have sockets, graphical displays, or disk drives. Yet many of them
are programmed in C++, more so with every passing year.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[Dave O'Hearn]

So, I ask again:
Why not, a committee specifies libraries which are not standard C++
libraries but *all* compilers include these libraries as part of them?
I mean libraries like socket using, window managment, file system,
thread using etc. These libraries with *identical API* in any compiler
will be a powerfull tool for any programmer and then, we can *anything*
in C++ which is *cross-platfrom*.

There is such a standard for C; it is called POSIX. POSIX specifies
the familiar networking functions like bind(), and a threading model,
and some other things.

I think what you are looking for is just POSIX wrappers for C++, or
something more or less equivalent. There is a library called ACE that
does a lot of these things,

http://www.cs.wustl.edu/~schmidt/ACE-overview.html

Also, Boost has a threading library, which may (or may not) make it
into the next C++ standard,

http://www.boost.org/libs/thread/doc/index.html

While your hope that something like this will become standard, and all
compilers will ship with such libraries, is not very realistic for the
reasons Jack Klein gave, you can reasonably hope to see more portable,
cross-platform libraries like the above come into common usage.

 

[Sean Fraley]

gcc provides the libc which have more functions than standard C libraries.
I saw in Windows API similar functions too, with identical parameters!
So, I ask again:
Why not, a committee specifies libraries which are not standard C++
libraries but *all* compilers include these libraries as part of them?
I mean libraries like socket using, window managment, file system, thread
using etc These libraries with *identical API* in any compiler will be a
powerfull tool for any programmer and then, we can *anything* in C++ which
is *cross-platfrom*.

The ANSI C++ standard was released in approximately 1998, and so far I have
heard of only ONE compiler that is 100% conformant with the standard. If
the current standard is taking over five years to implement properly, then
the last thing we need is to start adding a great deal of stuff to it. I
would REALLY like to be able to quit keeping track of the various behavior
quirks between compilers, and the above proprosal will just set that back
even further.

In addition, keep in mind that just about all of the items mentioned above
are things that really lie outside territory the standard library is
supposed to handle. The standard library is rather minimal on purpose,
attemtpting to provide only those things that can be expected to be
available in just about every situation that a C++ program is intended to
run. Remember please that cash registers, communication sattelites,
appliances, and a great many other things really don't have or need a
windowing system, hierarchial filesystem, multithreading, etc. On the
other hand, such things as the ability to allocate memory (<memory>),
handle minimal input and output of some form (<iostream>), handle

Another concept is the ability to write WEB Applets with C++.
With these libraries I refer above, we can do anything.
For Applets the problem is that C++ Compiler produces natural binary
files. How Java works? Java sucks... Java compile the code to virtual
opcodes and then Virtual Machine converts any virtual opcode to a group of
natural opcodes. This is unacceptable and very bad idea.
A higher-level (than Assembly) Language which is cross-platform must not
"converted" to low-level and after compiled or interpreted.
The better solution is Applet will kept as source code and Virtual Machine
compile the Applet before run it.
However, many people don't want make public their code.
So, A "converter" must exist. This "converter" has this job:
It converts C++ Applet source code to a binary which is almost identical
to source code but comments are removed, classes have changed to simple C
functions, spaces are removed and every reserved word or operator (like
for, if, ++, *) is converted to a binary pepresentation. Now, it is more
difficult to steal source code of Applet and compilation-time is shorter.
With this except of Applets you can write stand-alone applications exactly
like Java but with C++ speed.

And then, Java will die!...

(blink)...
(blink)...

I'm beginning to think that you are having difficulties with the idea of
"lowest common denominator". The current system used by java, along with
the idea of "just in time" compilers, does a decent job of operating in
most environments that it can expected to be used. Can we expect it to
match the speed of a C++ program that was compiled with optimizations?
Probably not. Can we expect it to eventually perform at a reasonable speed
in most common applications? Probably yes. More importantly, it does an
adequate job of attempting to reduce a certain amount of performance
overhead while allowing developers to create applets that can be used by as
wide of an audience as possible.

As for the suggestion of compiling pseudo source at runtime, this is a
pretty bad idea. Try writing a simple compiler, and look at what it has to
do. Compiling is a rather expensive process. Parsing, lexxing, and
translating source code into opcodes is requires a decent amount of CPU
time, and the amount of data structures that have to be mamipulated
normally result in a sizeable amount of memory consumption. This would
result in a pretty hefty load time for an app. The reason that this is a
problem is that the average human being doesn't take a sizeable notice of
the speed at which a program executes, but can't seem to ignore the fact
that there is a decent amount of lag from the time they take action to
start the program and the time it is up and ready for use.

As for killing Java, why? What did Java ever do to you?

Were you molested by a coffee mug as a young child?

What is your opinion?

My opinions is that yes, that dress does in fact make you butt look big.

Pax,
Sean

 

[Thomas Matthews]

I mean don't provide support.
So C++ is cross-platfrom in these platforms but these libraries are not implemented.
compile-time error.
In all other platforms C++ will be a great cross-platform tool

C++ is used in many platforms.
The issue of portability has been settled in many professional
communities: Section the code into standard C++ and platform dependent
code. Those few platform depended code pieces must be rewritten
for each platform. No way to go about it. Even with Java, the
concept still holds. Platforms are not the same and each has
different features, no matter how you try to standard-ize it.

Yes but if compiler compiles source to a not native binary we need a Virtual Machine
I don't hear anything about C++ VM.

Most applications that are compiled in C++ for a specific machines
are done so to optimize for speed. An interpretive language is slower
but more portable. Java is hybrid. Choose portability or speed.

Yes but in this case, code is not cross-platform.
(Except if we had cross-platform libraries, that I mean)

One can write a virtual machine. Have the libraries in source
code form. Account for all the differences between all of your
platforms that you want (and will want) to port to. Good Luck!

noticeable!...

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

 

[Erik]

gcc provides the libc which have more functions than standard C libraries.
[...]

For Applets the problem is that C++ Compiler produces natural binary files.
How Java works? Java sucks... Java compile the code to virtual opcodes
and then Virtual Machine converts any virtual opcode to a group of natural opcodes.
This is unacceptable and very bad idea.

Read my comment below.

A higher-level (than Assembly) Language which is cross-platform must not "converted"
to low-level and after compiled or interpreted.
The better solution is Applet will kept as source code and Virtual Machine compile the
Applet before run it.
However, many people don't want make public their code.
So, A "converter" must exist. This "converter" has this job:
It converts C++ Applet source code to a binary which is almost identical to source code
but comments are removed, classes have changed to simple C functions, spaces are removed
and every reserved word or operator (like for, if, ++, *) is converted to

a binary pepresentation.
You just described JIT compilation. If it would be a good idea for C++, why
isn't it for Java? Java
VM's are nowadays quite often JIT compilers. There is a good chance that
your (optimizing) C++
compiler does that, but that intermediate code is never displayed to you.

Now, it is more difficult to steal source code of Applet and compilation-time is shorter.
With this except of Applets you can write stand-alone applications exactly

like Java but with C++ speed.
The reason for Java being so slow is not the JIT compilation technique. The
reflection library may slow
it down a little (I'd guess about as much as enabling RTTI and using
dynamic_cast and typeid would slow
down a C++ program). Exceptions slows it down too, but not more than they
would slow down a C++
program. Other reasons for bad performance from Java is the lack of pointers
and extensive security checks.
Unless you are writing performance-critic inner loops none of these things
probably matter.
I think the reason for Java being slow is that the best programmers and the
most resources is put into
writing C++ compilers. BTW, don't like Java either, but that's for the lack
of syntax (like operator
overloading) and the fact that the compiler reports things that should be
warnings (like loss of precision when
converting a double to an int or not catching an exception) as errors.