C++ wish list and beyond

Discussion in 'C++' started by Zorro, Jun 28, 2005.

  1. Zorro

    Zorro Guest

    For almost a decade now some desirable features have appeared in
    circulations as C++ wish list. Consider the following features.

    Invariants and Contracts.
    Extending enumerations.
    Namespaces with private and public sections.
    Platform independent threading.
    Platform independent serialization.

    This is a small list of features that are supported by Z++, a platform
    independent superset of C++ for distributed computing. Just visit
    www.zhmicro.com and get a free compiler with many well-documented

    Zorro, Jun 28, 2005
    1. Advertisements

  2. Zorro

    Panjandrum Guest

    Please bear in mind that C++ already is the most complicated
    programming language around. Any "improvements" need more than good
    C++ as better Eiffel? No.
    What for?
    Better: "exported" and not-exported symbols (like in Win-DLL).
    Maybe a threading library on top of platform primitives.
    Not nececcary, IMO
    Z++, D, Heron, ...? It's more promising to establish better C++ idioms
    than to invent new languages. The latter is much easier.
    Panjandrum, Jun 28, 2005
    1. Advertisements

  3. [...]
    Bad choice of name. What if somebody comes up with a successor to Z++?

    Marcin Kalicinski, Jun 28, 2005
  4. Btw. please retest your website with IE 6.0 on Windows with 120 dpi font
    Marcin Kaliciñski, Jun 28, 2005
  5. Zorro

    Zorro Guest

    Please read carefully the logical responses to your statements before
    making another hasty judgement. It is my intent to be courteous. I
    apologies if the choice of words imply otherwise. Thank you.
    Is it the language, or the libraries for various platforms that is the
    most complicated? C++ does have several issues that Z++ systematically
    resolves, including static class members (I will generally point one or
    two items. You need to read some of the many white papers at
    www.zhmicro.com to get a better idea of the improvements).

    Z++ reduces the complexity of third-party and other libraries by
    several orders of magnitude. You can only judge after at least looking
    at some of the example programs. You will be surprised with the degree
    of reduction in complexity.

    However, linguistic extensions of Z++, such as tasks for
    object-oriented multi-threading, as well as the simplicity of creating
    platform independent global threads, and indeed a lot more, is what
    reduces the complexity. The lack of such linguistic constructs and
    relying on system calls and libraries is the bulk of complexity, not
    the size of the language. I am not familiar with any Eiffel library to
    make a judgement.

    Eiffel is a good language. However, the invariants and contracts of Z++
    are not a copy of Eiffel. In particular the flavor of contracts is more
    object-oriented and in Z++ they are called Constraints, not contracts.
    By the way, Eiffel differs from C++ not because of Invariants. It is a
    fully object-oriented language lacking the notion of global space with
    many defending articles. You should also read my view on that in the
    bloggers posted at the site.
    Just because Eiffel does not support something it does not make it
    unnecessary. The what for is answered in one of the white papers.
    Well. You must have been tired. Z++ is the language for platform free
    component oriented software development, but that is not related to
    namespaces at all. Any program in Z++ can execute as standalone, or
    simply used as (universal DLL) without any of those export/import mess.

    The export that you are mentioning, when taken in context of namespaces
    of Z++, maps to the public section of a namespace. By the way, in Z++
    namespaces can be derived from one another.

    What are platform primitives? Why a set of primitives and then a set of
    libraries? What is wrong with a simple linguistic universal solution
    that conforms to the overall design of the base language, in this case
    C++? It would be nice to know what you have in mind, indeed. The
    statement is too vague.
    The point here is that, you can simply send and receive programming
    objects in binary the same way you do input and output in C++. You
    simply overload operators << and >> for your object, just as simply as
    you do for stdin and stdout. So, what do you mean not necessary. How
    did you judge that, if I may ask?

    At the end you are listing several languages and making a correct
    comment "It is easier to invent new languages". The whole point is that
    Z++ is a superset of C++, and is not a new language. Relatively
    speaking, Eiffel is a new language (although goes back to early

    I also started in early eighties, as a mathematician (PhD) and my first
    attempt was a form of BASIC in 1984. It was successful for its time but
    I contiued my research until 1989 when I decided to go with C++. I
    presented Z++ in 1993 as my proposal for second PhD in Computer
    Science, and completed the prototype in 1996. Z++ is not an invented
    language. It has gone through years of research and refinement. The
    main point is that, enforcing a new language (including Eiffel and ADA)
    is like a conquerer forcing invaded countries to speak their language.
    You should read my article on Evolution and the reasons for taking the
    path C, C++ and Z++.
    Zorro, Jun 28, 2005
  6. Zorro

    Zorro Guest

    Thanks Marcin.

    Indeed I meant to say I am only going to list a few. The features cover
    all items on any wish list and go way beyond it. In fact, Z++
    coherently blends in well-tested features of ADA, APL etc. and properly
    extends them. The design of Z++ is based on abstractions in software
    engineering over several decades. The presentation is based on C++
    which goes back to Simula. Z++ is an evolution resting over a long span
    of history of successful attempts.

    Since Z++ executables run on a virtual processor of about 300K, the
    only thing I can see in the future is more evolved Z++ without any
    legacy programs. The possible increments in the instruction set of the
    virtual processor will not violate existing code. The process is like
    extending Intel processors than making a larger virtual machine. The
    novelty in the design is that the work is done by the compiler, linker
    etc, not the virtual machine.

    The successors of Z++ will be future versions of Z++. As it is, the sum
    of all languages does not match up with Z++, and yet it hardly takes a
    week of self-study to move up from C++ to Z++.

    Thanks again.
    Zorro, Jun 29, 2005
  7. Zorro

    Zorro Guest

    I have informed the person doing the page.

    Thank you.
    Zorro, Jun 29, 2005
  8. Zorro

    Panjandrum Guest

    Ok, I carefully read your first message:
    Q: What is Zorro talking about?
    A: He posts to comp.lang.c++. He's talking about C++.
    Q: What is Zorro talking about?
    A: He's still talking about C++ (nothing else mentioned yet).
    Q: What is Zorro talking about?
    A: Oops, Z++! My fault, I haven't read the message bottom up as I
    should! Sorry to have wasted your precious time. I'm not interested in
    buying your product. BTW, you should consider to create a comp.lang.z++
    group to avoid further misunderstanding. Z++ is obviously off topic in
    group dedicated to C++.
    Panjandrum, Jun 29, 2005
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.