Some concepts (Maybe LOL maybe not...)

Discussion in 'C++' started by Guest, Aug 17, 2003.

  1. Guest

    Guest 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?
     
    Guest, Aug 17, 2003
    #1
    1. Advertising

  2. Guest

    Jack Klein Guest

    On Mon, 18 Aug 2003 00:39:55 +0300, "<- Chameleon ->"
    <> wrote in comp.lang.c++:

    > 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
     
    Jack Klein, Aug 18, 2003
    #2
    1. Advertising

  3. Guest

    Dave O'Hearn Guest

    "<- Chameleon ->" <> wrote:
    > 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.

    --
    Dave O'Hearn
     
    Dave O'Hearn, Aug 18, 2003
    #3
  4. Guest

    Sean Fraley Guest

    - Chameleon - wrote:

    > 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
    errors(<stdexcept>), perform common algorithms(<algorithm>), and the like
    can be expected of almost any practical program.

    > 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
     
    Sean Fraley, Aug 18, 2003
    #4
  5. <- Chameleon -> wrote:

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

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


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

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


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

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

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

    >
    >
    > 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
     
    Thomas Matthews, Aug 18, 2003
    #5
  6. Guest

    Erik Guest

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

    > And then, Java will die!...
    >
    >
    > What is your opinion?
    >
    >
     
    Erik, Aug 18, 2003
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Weyoun the Dancing Bong

    LOL @ College course.

    Weyoun the Dancing Bong, Jan 20, 2004, in forum: HTML
    Replies:
    13
    Views:
    716
    Hywel Jenkins
    Jan 20, 2004
  2. SorceCode
    Replies:
    2
    Views:
    3,387
    Christian Jan├čen
    Jan 26, 2004
  3. nospam
    Replies:
    11
    Views:
    603
    Thomas Dickey
    May 3, 2007
  4. Replies:
    2
    Views:
    821
  5. Trans
    Replies:
    0
    Views:
    158
    Trans
    Apr 23, 2006
Loading...

Share This Page