Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #88820 > unrolled thread

Z++ for Windows and Linux

Back to article view | Back to comp.lang.c++

Contents

  Z++ for Windows and Linux Zorro <zorabih@gmail.com> - 2023-01-24 15:09 -0800
    Re: Z++ for Windows and Linux "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-24 15:12 -0800
      Re: Z++ for Windows and Linux "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-24 15:14 -0800
        Re: Z++ for Windows and Linux Öö Tiib <ootiib@hot.ee> - 2023-01-24 16:41 -0800
          Re: Z++ for Windows and Linux Zorro <zorabih@gmail.com> - 2023-01-31 11:07 -0800
            Re: Z++ for Windows and Linux scott@slp53.sl.home (Scott Lurndal) - 2023-01-31 19:27 +0000
        Re: Z++ for Windows and Linux Zorro <zorabih@gmail.com> - 2023-01-31 11:00 -0800
        Re: Z++ for Windows and Linux Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-31 14:22 -0800
          Re: Z++ for Windows and Linux "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-31 14:29 -0800
            Re: Z++ for Windows and Linux Zorro <zorabih@gmail.com> - 2023-01-31 15:25 -0800
              Re: Z++ for Windows and Linux scott@slp53.sl.home (Scott Lurndal) - 2023-02-01 00:30 +0000
                Re: Z++ for Windows and Linux Zorro <zorabih@gmail.com> - 2023-02-01 09:28 -0800
                  Re: Z++ for Windows and Linux scott@slp53.sl.home (Scott Lurndal) - 2023-02-01 18:05 +0000
                    Re: Z++ for Windows and Linux Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-02 07:09 -0800
                      Re: Z++ for Windows and Linux Muttley@dastardlyhq.com - 2023-02-02 16:11 +0000
                        Re: Z++ for Windows and Linux Zorro <zorabih@gmail.com> - 2023-02-02 13:39 -0800
                        Re: Z++ for Windows and Linux Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-02 17:42 -0800
              Re: Z++ for Windows and Linux Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-31 16:32 -0800
                Re: Z++ for Windows and Linux Zorro <zorabih@gmail.com> - 2023-02-01 08:36 -0800
                  Re: Z++ for Windows and Linux Muttley@dastardlyhq.com - 2023-02-01 17:10 +0000
                    Re: Z++ for Windows and Linux Zorro <zorabih@gmail.com> - 2023-02-01 10:07 -0800
                  Re: Z++ for Windows and Linux James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-01 13:24 -0500
                    Re: Z++ for Windows and Linux Zorro <zorabih@gmail.com> - 2023-02-01 10:57 -0800
              Re: Z++ for Windows and Linux Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-01 08:52 +0200
                Re: Z++ for Windows and Linux Zorro <zorabih@gmail.com> - 2023-02-01 08:01 -0800
                  Re: Z++ for Windows and Linux Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-01 19:23 +0200
                    Re: Z++ for Windows and Linux Zorro <zorabih@gmail.com> - 2023-02-01 14:03 -0800

Page 2 of 2 — ← Prev page 1 [2]

#88951

On Wednesday, February 1, 2023 at 11:10:25 AM UTC-6, Mut...@dastardlyhq.com wrote:
> On Wed, 1 Feb 2023 08:36:45 -0800 (PST) 
> Zorro <zor...@gmail.com> wrote: 
> >On Tuesday, January 31, 2023 at 6:32:44 PM UTC-6, Keith Thompson wrote: 
> >Thus, the entire C++ class is within Z++ class, but there is a lot more, with 
> >minor difference in syntax, basically
> Using pascal style keywords instead of brackets is hardly a minor difference.
> >no braces are used. This is not a direct extension of C++. Maybe we could say 
> >"semantically superset", 
> >but that would be vague.
> One of the reasons Objective-C was unpopular was the mashing up of 2 different 
> syntax styles into one language. You should take note.

We are not mashing up anything. Z++ syntax for constructs is like Eiffel or Ada. Z++ compiler will
not accept C or C++ programs, because it it not a plain extension of C++. There is only one syntax
and that is of Z++. However, over-all beyond constructs that need a closing tag, the rest is C++ syntax.

C++ won popularity (I am glad it did) because ATT sent B. Strousroup and G. Booch to all major shops
to introduce and advertise it. In the 90's ATT paid for an entire "Computer Journal" and filled it with rather
childish articles touting C++. A lot of money was spent on C++. Again, I like C++ as it is, so I am glad
it won.

Now, the reason for Z++ syntax, among many other things, is that it can catch and tell you what the error
is, and where it occurred. For instance, C++ compiler loses its view when a closing brace "}" is missed in
a nested statement, say "if within a loop", or even worse when nesting is too deep. That does not happen
in Z++. It can tell you what is missing, and where.

I reviewed all major languages, and weighed their syntax before deciding on the syntax for Z++. My intent
is not to advertise Z++ as "platform-independent"  C++. Actually C++ is hardly about 60% of Z++. The main
Idea behind Z++ is distributed computing, which requires: component-orientation and platform-independence.

[toc] | [prev] | [next] | [standalone]

#88952

On 2/1/23 11:36, Zorro wrote:
...
> OK, initially C++ was called C with classes, around 1989 templates and exceptions were added.
> For many years C++ was compiled to C, and the C compiler would finish the job. Thus, C++ is a
> direct extension of C, even though now C++ compiler does the whole work. So now you only need
> to indicate "extern "C"" for linkage purposes.

The C standard specifies the requirements for a conforming extension to
C: "A conforming implementation may have extensions (including
additional library functions), provided they do not alter the behavior
of any strictly conforming program." (4p6)

That's a very strict requirement, and it has been a very long time since
any version of C++ even came close to qualifying as an extension to C.
See Annex C.5 and C.6 of the C++ standard for a 10 page list of ways in
which C++ gives code that is permitted in both languages a significantly
different meaning than it would have as C code.

The C++ standard has similar language in 4.1p8, except that it uses
"well-formed" rather than "strictly conforming". There are significant
conceptual differences between "strictly conforming", as that term is
defined by the C standard, and "well-formed" as it is defined by the C++
standard, but they serve similar purposes in the two standards, and are
both very strict requirements. I sincerely doubt, from what you've said,
that Z++ even comes close to qualifying.

[toc] | [prev] | [next] | [standalone]

#88953

On Wednesday, February 1, 2023 at 12:25:05 PM UTC-6, james...@alumni.caltech.edu wrote:
> On 2/1/23 11:36, Zorro wrote: 
> ...
> > OK, initially C++ was called C with classes, around 1989 templates and exceptions were added. 
> > For many years C++ was compiled to C, and the C compiler would finish the job. Thus, C++ is a 
> > direct extension of C, even though now C++ compiler does the whole work. So now you only need 
> > to indicate "extern "C"" for linkage purposes.
> The C standard specifies the requirements for a conforming extension to 
> C: "A conforming implementation may have extensions (including 
> additional library functions), provided they do not alter the behavior 
> of any strictly conforming program." (4p6) 
> 
> That's a very strict requirement, and it has been a very long time since 
> any version of C++ even came close to qualifying as an extension to C. 
> See Annex C.5 and C.6 of the C++ standard for a 10 page list of ways in 
> which C++ gives code that is permitted in both languages a significantly 
> different meaning than it would have as C code. 
> 
> The C++ standard has similar language in 4.1p8, except that it uses 
> "well-formed" rather than "strictly conforming". There are significant 
> conceptual differences between "strictly conforming", as that term is 
> defined by the C standard, and "well-formed" as it is defined by the C++ 
> standard, but they serve similar purposes in the two standards, and are 
> both very strict requirements. I sincerely doubt, from what you've said, 
> that Z++ even comes close to qualifying.

I think there is a big misunderstanding, sorry. Look, a program will consist of a lot of
statement such as:

new for creating dynamic objects
a++ or ++a for incrementing (and decrementing)
a << 4 or a <<= 4 and many other operators
pointer arithmetic
invoking methods, like p->method(...)
etc.

The syntax and semantics are identical to C++. But that is the bulk of a program. The main
difference is in the definitions, which are mostly extended. For instance:

enum something {....};

is exactly as in C++, but the values are private. Yes, C++ later added "enum class", but the work on
Z++ started in 1991 while I was still in academia. In addition, in Z++ you can extend enumeration:

enum another_thing : something {...};

Now, another_thing will include "something", and then add to it the new values.

Z++ does not have to deal with conforming to C++ standard, because it is not claiming to be
a direct extension of C++. It is a different language which uses the same syntax and semantics
for much of the statements that constitute a program. I hope this clarifies things somewhat.

[toc] | [prev] | [next] | [standalone]

#88937

01.02.2023 01:25 Zorro kirjutas:

> Thank you. ,Z++ is a "Superset", not an extension of C++, as it it to C. The list of
> corrections to C++ is too long, here is a few simple ones:
[...]> The case
> statements can be written as: "case 1..10:" instead of listing them all, or if not contiguous you can us commas,
> as in: "case 1, 3, 12:". Since strings are built-in types, they can be used as case labels.

This would make sense if there was an implicit 'break' at the end of 
each 'case' (no fall-through), is that so?

[toc] | [prev] | [next] | [standalone]

#88945

On Wednesday, February 1, 2023 at 12:52:21 AM UTC-6, Paavo Helde wrote:
> 01.02.2023 01:25 Zorro kirjutas: 
> 
> > Thank you. ,Z++ is a "Superset", not an extension of C++, as it it to C. The list of 
> > corrections to C++ is too long, here is a few simple ones:
> [...]> The case
> > statements can be written as: "case 1..10:" instead of listing them all, or if not contiguous you can us commas, 
> > as in: "case 1, 3, 12:". Since strings are built-in types, they can be used as case labels.
> This would make sense if there was an implicit 'break' at the end of 
> each 'case' (no fall-through), is that so?


Correct, each case body is a block in which you can declare objects visible within that block, and there is no
break at end of block (it is implicit).

[toc] | [prev] | [next] | [standalone]

#88948

01.02.2023 18:01 Zorro kirjutas:
> On Wednesday, February 1, 2023 at 12:52:21 AM UTC-6, Paavo Helde wrote:
>> 01.02.2023 01:25 Zorro kirjutas:
>>
>>> Thank you. ,Z++ is a "Superset", not an extension of C++, as it it to C. The list of
>>> corrections to C++ is too long, here is a few simple ones:
>> [...]> The case
>>> statements can be written as: "case 1..10:" instead of listing them all, or if not contiguous you can us commas,
>>> as in: "case 1, 3, 12:". Since strings are built-in types, they can be used as case labels.
>> This would make sense if there was an implicit 'break' at the end of
>> each 'case' (no fall-through), is that so?
> 
> 
> Correct, each case body is a block in which you can declare objects visible within that block, and there is no
> break at end of block (it is implicit).

Ok, good!

About the built-in string type: is the encoding fixed? If it is variable 
length like UTF-8, then do indexing and lengths happen in bytes or 
unicode characters?

Is there a separate character data type?

Are they immutable like in Python? If immutable, are the contents 
reference-counted? In a thread-safe way?

Is small string optimisation used?

Are zero bytes allowed in the middle of the string?

I'm curious because I have implemented a built-in string type for a 
scripting language where all these questions came up.

[toc] | [prev] | [next] | [standalone]

#88954

On Wednesday, February 1, 2023 at 11:23:58 AM UTC-6, Paavo Helde wrote:
> 01.02.2023 18:01 Zorro kirjutas: 
> > On Wednesday, February 1, 2023 at 12:52:21 AM UTC-6, Paavo Helde wrote: 
> >> 01.02.2023 01:25 Zorro kirjutas: 
> >> 
> >>> Thank you. ,Z++ is a "Superset", not an extension of C++, as it it to C. The list of 
> >>> corrections to C++ is too long, here is a few simple ones: 
> >> [...]> The case 
> >>> statements can be written as: "case 1..10:" instead of listing them all, or if not contiguous you can us commas, 
> >>> as in: "case 1, 3, 12:". Since strings are built-in types, they can be used as case labels. 
> >> This would make sense if there was an implicit 'break' at the end of 
> >> each 'case' (no fall-through), is that so? 
> > 
> > 
> > Correct, each case body is a block in which you can declare objects visible within that block, and there is no 
> > break at end of block (it is implicit).
> Ok, good! 
> 
> About the built-in string type: is the encoding fixed? If it is variable 
> length like UTF-8, then do indexing and lengths happen in bytes or 
> unicode characters? 
> 
> Is there a separate character data type? 
> 
> Are they immutable like in Python? If immutable, are the contents 
> reference-counted? In a thread-safe way? 
> 
> Is small string optimisation used? 
> 
> Are zero bytes allowed in the middle of the string? 
> 
> I'm curious because I have implemented a built-in string type for a 
> scripting language where all these questions came up.

As a built-in type it is an abstraction that can be extended in the future, only if needed. For now they are C-string
meaning single-byte ASCII characters.  But of course one can create classes for whatever string kind
like unicode, UTF-8 etc, which then will not be built-in, and cannot be used as case labels. So, the answer to
your questions is no. Sorry.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web