473,324 Members | 2,124 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,324 software developers and data experts.

"Small C++" Anyone?

(The "C++ Grammer" thread in comp.lang.c++.moderated prompted this post).

It would be more than a little bit nice if C++ was much "cleaner" (less
complex) so that it wasn't a major world wide untaking to create a toolchain
for it. Way back when, there used to be something called "Small C". I wonder
if the creator(s) of that would want to embark on creating a nice little
Small C++ compiler devoid of C++ language features that make toolchain
(including the compiler) a nightmare to implement (?). Yes, I realize that
would be a subset or a "dialect" of C++. Or not! They could call it
something else and avoid all the flak from the "use all of C++ all of the
time" proponents. I'd try and tackle that myself if I had another 100 years
to live. Alas, I don't so I have to stay focused on what I can produce at a
higher level of usage instead of diving into something new and so low level.

A "new" clean "little" language that is wholly a subset of C++ but is
tremendously easier to implement and to create a toolchain for. That's the
ticket! Could something like that "put C++ out of business"?

John
Mar 9 '07
169 8907
"JohnQ" <jo***********************@yahoo.comwrote in message
news:58****************@newssvr21.news.prodigy.net ...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:d7**************************@KNOLOGY.NET...
<snip>
>

There's no need for C++ IO though to read/write data. Just wrap the
(better)
platform APIs into a nicer "std library".
There is a need for C++ IO. The current system allows classes to serialize
themselves.
What are your thoughts on implementing a replacement?
>
At some point in a product's lifetime or a software company's
evolution,
there may very well be desire to avoid building product on top of
someone
else's technology. At one level one may say that programming with
technologies such as MS's COM or .net is banking too much on 3rd party
technology. At another level, one may decide that the decidedly
complex-to-implement features of C++ are too risky to buy into. I'm
already
planning aversion to C++ complexity where and when it is practical in
preparation for the future. (I use templates, but not advanced
templates
and
not the STL, for example. If I can find a way out of them, I'll
probably
take it).
Ok, so you'll avoid using standard genertic containers in place of what
you
write yourself.
And you think it'll be easier for new hires to use the ones you create
as
opposed to the STL?

Definitely! There will be "Small C++ Standard Containers and Algorithms"
that are an improvement over STL containers/algos both in usage and in
implementation.
And how will they be improved in both usage and implementation?
>

for my masters thesis, I implemented a C compiler for microprogramming.
I developed a couple of extensions to better handle the specifics for
microcode.
Took me about 6 months, using flex and bison.

Those tools are freely available.
Go for it. :-)

I may be backing my way into something like that, but I doubt it unless I
could do it in a big way with funding, resources etc. A preprocessor might
be a better place to start. Having full control of the toolchain is
definitely lucrative. That's why I started this thread afterall.
Dennis
Mar 28 '07 #151

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:da***************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:yV*****************@newssvr21.news.prodigy.ne t...
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:4d**************************@KNOLOGY.NET.. .
"JohnQ" <jo***********************@yahoo.comwrote in message
news:Zl************@newssvr22.news.prodigy.net...

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:ac*************************@KNOLOGY.NET...
<snip>

So in what language(s) do you think its easy to have reasonable
confidence
that, given their specification, the programmer will produce what
was
envisions (vs what was written in the spec?)

Small C++! Why? Because thought would be given to the feature set,
much
moreso than it was with C++, to ensure it was harder to "shoot your
whole
>foot off" or even shoot yourself in the foot.

I note the use of the future tense "would be"
Ok, letsd try this. We'll start off with the same requirements.
Ill use C++, you can use Small C++.
We'll see who finishes first. I'll admit I have an advantage in that my
language and compiler.....exists.

I fail to see your point. The thread is rationale for a new language.

My point is that since [Small] C++ does not yet exist, not even as a
specification
that can be evaluated, its difficult to evaluate its feature set and
difficult to have reasonable confidence that, given the specification, the
programmer will produce what was envisioned.
Well given that that is a goal of the new language, where it was not so with
C++, some bit of assumption can be made.
>
>>
>
Interesting that you find no other language in which you have
reasonable
confidence that, given the specification, that the programmer will
prodce
the desired result.

That's not the only criteria.

That is what I asked about though.
I see no question in there.
>
>>
>
<snip>

And then starting talking about how one can writ hard-to-maintain
code
in
C++.

I didn't say 'can', I suggested 'taught'! I said something like
"writing
C++
has the obfuscation already built-in... no need to make any special
effort
to write obfuscated C++ code!".

And I said that since C++ derives from C, and C is the one language I
know
that has a contest whose purpose is to write obfuscated code, it seems
logical that Small-C++ would also "have obfuscation built in".

That sounds completely illogical to me. B does not obviously follow
directly
>from A

Perhaps this will help?
http://en.wikipedia.org/wiki/Obfuscated_code
Obfuscated code is source code that is (usually intentionally) very hard
to
read and understand. Some languages are more prone to obfuscation than
others. C, C++ and Perl are most often cited as easily obfuscatable
languages.
Trying to write obfuscated code and doing it inherently because of the
popular usage of the language constructs are entirely different animals.
>
<snip>
>>
Apparently so do 9-bit bytes, but that makes the language a bit too
broad
if
you ask me. Eventually, the language itself will become
unmaintainable.

Yes, since there are machine architectures with 9-bit bytes.
Having the language with the flexibility to handle such architectures
is
a
good thing, IMO.

Unless you know you will never need that portability. Then it just serves
to
>make the compiler more complex (well, so I assume, but surely it makes
the
programmer have to think more than is necessary about extraneous detail).
If
>it's not needed, not specified, it's "gold plating".

Well....I have implemented a compiler and I tell ya, byte size was not a
concern at all.
Good then, maybe that can stay.

John
Mar 28 '07 #152

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:1e***************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:58****************@newssvr21.news.prodigy.net ...
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:d7**************************@KNOLOGY.NET.. .
<snip>
>>

There's no need for C++ IO though to read/write data. Just wrap the
(better)
>platform APIs into a nicer "std library".

There is a need for C++ IO. The current system allows classes to serialize
themselves.
There's more than one way to skin a cat.
What are your thoughts on implementing a replacement?
I'm don't think it is a primary concern at the outset. IO tends to be
application-specific.
>
>>
>At some point in a product's lifetime or a software company's
evolution,
>there may very well be desire to avoid building product on top of
someone
>else's technology. At one level one may say that programming with
technologies such as MS's COM or .net is banking too much on 3rd party
technology. At another level, one may decide that the decidedly
complex-to-implement features of C++ are too risky to buy into. I'm
already
planning aversion to C++ complexity where and when it is practical in
preparation for the future. (I use templates, but not advanced
templates
and
not the STL, for example. If I can find a way out of them, I'll
probably
>take it).

Ok, so you'll avoid using standard genertic containers in place of what
you
write yourself.
And you think it'll be easier for new hires to use the ones you create
as
opposed to the STL?

Definitely! There will be "Small C++ Standard Containers and Algorithms"
that are an improvement over STL containers/algos both in usage and in
implementation.

And how will they be improved in both usage and implementation?
You'll have to wait and see. :)
>
>>
>
for my masters thesis, I implemented a C compiler for microprogramming.
I developed a couple of extensions to better handle the specifics for
microcode.
Took me about 6 months, using flex and bison.

Those tools are freely available.
Go for it. :-)

I may be backing my way into something like that, but I doubt it unless I
could do it in a big way with funding, resources etc. A preprocessor
might
be a better place to start. Having full control of the toolchain is
definitely lucrative. That's why I started this thread afterall.
John
Mar 28 '07 #153

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:6d***************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:uq***************@newssvr21.news.prodigy.net. ..
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:2b*************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:EO************@newssvr22.news.prodigy.net...
<snip>
>>
For the myriad of reasons given since this thread started.

Ok, so why do you use it?

Because it is the closest thing to what I want in a language. It's
drifting
>more and more away though. What was once even thought to be "all I ever
wanted in a language" now leaves me longing for something better based
upon
>lessons learned over the years. C++ can't evolve to be that replacement
because it is encumbered by backward compatibility and is now decidedly
too
>broad. (Or something like that).

Backward compatibility is important, but there have been times that its
been
ignored.
Make a strong enough case at the standards committee and.......
It sounds easier just to create a new language for new development where a
codebase does not exist. Why deal with politics if you don't have to? Also,
C++ is obviously on an expansion-of-features path. I don't foresee any
feature being removed ever, so the compiler system development capability
(toolchain) for C++ will only be possible with millions of dollars of
development or equivalent resources. Perhaps it's idealistic to think that a
powerful-enough language could be developed that keeps toolchain development
accessible to the masses, but I for one think that it may be possible.
Whether it is worth my time or not is another story.
>
>>
>
The means have taken over. Sight of the goal has been lost. (You
know
it
is
true). I'm not even asking why, I'm just dreaming about making it
better.

Could you be more specific then?

About what?

Uhmm...about Small-C++?

You mean more specific than everything already said in this thread? (!).
LOL. If I was more specific, I'd be writing a specification already!

Yes.
Well you know what they say about million dollar answers: they cost a
million dollars! ;)
>
>>
>


C++ is hard to learn.

It depends on who is learning it and from what book/person ;J

No it doesn't. It's hard. Don't even bother perpetuating this piece
of
this
post because we will just have to agree to disagree on that one.

Well, programming itself is "hard".

Well it doesn't have to be. I mean, that would be a goal of "Small
C++":
>programming doesn't have to be so hard. From the get go, if the new
programmer could rely on an 8-bit byte and integer types of specific
widths
exclusively, just that would help propel someone to productivity with
a
language faster. type.h is probably where I'd start if I was to start
laying
out "Small C++": a standard set of integer types of guaranteed width
and
no
nebulous integer types (no "is 32 bits on a 32 bit machine, 64 bits on
a
64
bit machine" etc.).

Ahh..so someone having difficulty with "int" and float" would find them
immediately accessible if they know that both are 32-bit?
:-)

I was talking about ints.

Yes.
>>
>
So you have int as 32-bit exclusively,

No, I didn't say that. I said you have guaranteed width integers and a
byte
>is 8 bits.

I realize that, I was using an example. Note the comma as opposed to a
period.
Well an extraneous scenario then.
>
>>
then it performs poorly on 16-bit
CPUs compared to ones that use the "native type".

So what is the guaranteed width?
Some compilers already provide as an extenson __int16, __int32, __int64,
etc.
I'm suggesting that only guaranteed width integers should be available to
avoid confusion about what happens from platform to platform. (Though I
haven't completely decided that a platform-specific-width integer is a bad
idea). Perhaps another simplification would be to have only signed integer
types.
>

<snip>
>>
Or I could just stop using more and more of the C++ constructs and
replace
them with my own. Yes, at some point there is limitation by not having
access to the compiler. At that point, someone may want to embark on
building a compiler system or solicit someone to do it.
An example is using the __int8 style integers exclusively in
preparation
for
a compiler that ONLY supports guaranteed width integers.

Go for it.

I'm not sure that is plausible for me to do it. Needs more research. If I
pick up on more and more of the concepts as time goes on, before anyone
else
>makes the thing, I just might do it. It's probably harder than I care to
get
>into though. It would be a great job for someone already skilled in
compiler/tool development.

Well, one of your goal was to make Small-c++ easy for anyone to implement.
Being the first to pick from the existing patterns and techniques, etc.
would be the hard part and someone already on top of compiler/tool building,
assuming they had the right practicality for the job, could avoid most of
the startup research. Showing someone how and why after the fact would be
the easy part.

John
Mar 28 '07 #154

"Julián Albo" <JU********@terra.eswrote in message
news:46********@x-privat.org...
JohnQ wrote:
>cases. It's the more-is-more language. Small C++ is envisioned as the
less-is-more language.

In that case, you have already achieved your goal, because Small C++ is
nothing. Impossible to be less.
It's a (fuzzy) vision. Time is making it clearer though. It's a concept (a
set of them) yet to be proven. It may become more lucrative as C++ expands
with features to fill the universe and the compilers become big plates of
spaghetti maintained by a very few multi-million dollar projects/companies.

John
Mar 28 '07 #155
"JohnQ" <jo***********************@yahoo.comwrote in message
news:Ht*******************@newssvr14.news.prodigy. net...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:da***************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:yV*****************@newssvr21.news.prodigy.ne t...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:4d**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:Zl************@newssvr22.news.prodigy.net...

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:ac*************************@KNOLOGY.NET...
<snip>

So in what language(s) do you think its easy to have reasonable
confidence
that, given their specification, the programmer will produce what
was
envisions (vs what was written in the spec?)

Small C++! Why? Because thought would be given to the feature set,
much
moreso than it was with C++, to ensure it was harder to "shoot your
whole
foot off" or even shoot yourself in the foot.

I note the use of the future tense "would be"
Ok, letsd try this. We'll start off with the same requirements.
Ill use C++, you can use Small C++.
We'll see who finishes first. I'll admit I have an advantage in that
my
language and compiler.....exists.

I fail to see your point. The thread is rationale for a new language.
My point is that since [Small] C++ does not yet exist, not even as a
specification
that can be evaluated, its difficult to evaluate its feature set and
difficult to have reasonable confidence that, given the specification,
the
programmer will produce what was envisioned.

Well given that that is a goal of the new language, where it was not so
with
C++, some bit of assumption can be made.
I'm sure you remember what happens when you assume.

Heck, I could say that I have a goal for NewC++ where it'd be impossible to
express an incorrect program.
Everything would be caught at compile time.
Doesn't mean it'd happen.

There's a difference between "goal" and what's achieved.
>
>

Interesting that you find no other language in which you have
reasonable
confidence that, given the specification, that the programmer will
prodce
the desired result.

That's not the only criteria.
That is what I asked about though.

I see no question in there.
It was above.
So in what language(s) do you think its easy to have reasonable confidence
that, given their specification, the programmer will produce what was
envisions (vs what was written in the spec?)
>
>

<snip>

And then starting talking about how one can writ hard-to-maintain
code
in
C++.

I didn't say 'can', I suggested 'taught'! I said something like
"writing
C++
has the obfuscation already built-in... no need to make any special
effort
to write obfuscated C++ code!".

And I said that since C++ derives from C, and C is the one language I
know
that has a contest whose purpose is to write obfuscated code, it
seems
logical that Small-C++ would also "have obfuscation built in".

That sounds completely illogical to me. B does not obviously follow
directly
from A
Perhaps this will help?
http://en.wikipedia.org/wiki/Obfuscated_code
Obfuscated code is source code that is (usually intentionally) very hard
to
read and understand. Some languages are more prone to obfuscation than
others. C, C++ and Perl are most often cited as easily obfuscatable
languages.

Trying to write obfuscated code and doing it inherently because of the
popular usage of the language constructs are entirely different animals.
And C allows one to write obfuscated code due to popular usage of the
language constructs.

Dennis
Mar 28 '07 #156
"JohnQ" <jo***********************@yahoo.comwrote in message
news:tB*******************@newssvr14.news.prodigy. net...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:1e***************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:58****************@newssvr21.news.prodigy.net ...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:d7**************************@KNOLOGY.NET...
<snip>
>

There's no need for C++ IO though to read/write data. Just wrap the
(better)
platform APIs into a nicer "std library".
There is a need for C++ IO. The current system allows classes to
serialize
themselves.

There's more than one way to skin a cat.
Indeed.
>
What are your thoughts on implementing a replacement?

I'm don't think it is a primary concern at the outset. IO tends to be
application-specific.
Oh, I think it'd be a pretty important consideration.

<snip>
>
Definitely! There will be "Small C++ Standard Containers and
Algorithms"
that are an improvement over STL containers/algos both in usage and in
implementation.
And how will they be improved in both usage and implementation?

You'll have to wait and see. :)
Uhmm....ok.

Dennis
Mar 28 '07 #157

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:84***************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:Ht*******************@newssvr14.news.prodigy. net...
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:da***************************@KNOLOGY.NET. ..
"JohnQ" <jo***********************@yahoo.comwrote in message
news:yV*****************@newssvr21.news.prodigy.ne t...

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:4d**************************@KNOLOGY.NET.. .
"JohnQ" <jo***********************@yahoo.comwrote in message
news:Zl************@newssvr22.news.prodigy.net...

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:ac*************************@KNOLOGY.NET...
<snip>

So in what language(s) do you think its easy to have reasonable
confidence
that, given their specification, the programmer will produce what
was
envisions (vs what was written in the spec?)

Small C++! Why? Because thought would be given to the feature set,
much
moreso than it was with C++, to ensure it was harder to "shoot your
whole
foot off" or even shoot yourself in the foot.

I note the use of the future tense "would be"
Ok, letsd try this. We'll start off with the same requirements.
Ill use C++, you can use Small C++.
We'll see who finishes first. I'll admit I have an advantage in that
my
language and compiler.....exists.

I fail to see your point. The thread is rationale for a new language.

My point is that since [Small] C++ does not yet exist, not even as a
specification
that can be evaluated, its difficult to evaluate its feature set and
difficult to have reasonable confidence that, given the specification,
the
programmer will produce what was envisioned.

Well given that that is a goal of the new language, where it was not so
with
>C++, some bit of assumption can be made.

I'm sure you remember what happens when you assume.
"assume" was a bad word then. Theorizing would be better. It's not like I'm
pulling all of this out of thin air. There are reasonable goals and
directions for further investigation and prototyping.
>>
>
Interesting that you find no other language in which you have
reasonable
confidence that, given the specification, that the programmer will
prodce
the desired result.

That's not the only criteria.

That is what I asked about though.

I see no question in there.

It was above.
So in what language(s) do you think its easy to have reasonable confidence
that, given their specification, the programmer will produce what was
envisions (vs what was written in the spec?)
Small C++.
>
>>
>
<snip>

And then starting talking about how one can writ hard-to-maintain
code
in
C++.

I didn't say 'can', I suggested 'taught'! I said something like
"writing
C++
has the obfuscation already built-in... no need to make any special
effort
to write obfuscated C++ code!".

And I said that since C++ derives from C, and C is the one language
I
know
that has a contest whose purpose is to write obfuscated code, it
seems
logical that Small-C++ would also "have obfuscation built in".

That sounds completely illogical to me. B does not obviously follow
directly
from A

Perhaps this will help?
http://en.wikipedia.org/wiki/Obfuscated_code
Obfuscated code is source code that is (usually intentionally) very
hard
to
read and understand. Some languages are more prone to obfuscation than
others. C, C++ and Perl are most often cited as easily obfuscatable
languages.

Trying to write obfuscated code and doing it inherently because of the
popular usage of the language constructs are entirely different animals.

And C allows one to write obfuscated code due to popular usage of the
language constructs.
There are more mechanisms in C++ hence more possibility for obfuscation.
Just the "template obfuscation machinery" should be enough proof of that.
(Of course I am using "obfuscation" to mean "incomprehsible/unmaintainable"
at worst, or "hard to understand" at best).

John
Mar 28 '07 #158

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:3f**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:tB*******************@newssvr14.news.prodigy. net...
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:1e***************************@KNOLOGY.NET. ..
"JohnQ" <jo***********************@yahoo.comwrote in message
news:58****************@newssvr21.news.prodigy.net ...

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:d7**************************@KNOLOGY.NET.. .
<snip>
There's no need for C++ IO though to read/write data. Just wrap the
(better)
platform APIs into a nicer "std library".

There is a need for C++ IO. The current system allows classes to
serialize
themselves.

There's more than one way to skin a cat.

Indeed.
>>
What are your thoughts on implementing a replacement?

I'm don't think it is a primary concern at the outset. IO tends to be
application-specific.

Oh, I think it'd be a pretty important consideration.
It's at the library level rather than the language proper level. Foundations
first. Higher level things afterwards. For the most part.
>
<snip>
>>
Definitely! There will be "Small C++ Standard Containers and
Algorithms"
>that are an improvement over STL containers/algos both in usage and in
implementation.

And how will they be improved in both usage and implementation?

You'll have to wait and see. :)

Uhmm....ok.

Dennis


Mar 28 '07 #159
Dennis (Icarus) wrote:
:: "JohnQ" <jo***********************@yahoo.comwrote in message
:: news:58****************@newssvr21.news.prodigy.net ...
:::
::: "Dennis (Icarus)" <no********@ever.invalidwrote in message
::: news:d7**************************@KNOLOGY.NET...
:: <snip>
:::
:::
::: There's no need for C++ IO though to read/write data. Just wrap the
::: (better) platform APIs into a nicer "std library".
::
:: There is a need for C++ IO. The current system allows classes to
:: serialize themselves.
:: What are your thoughts on implementing a replacement?

If you have binary compatibility across all implementations on all hardware,
the rest will be simple. :-)

I think that's what John is looking for.
Bo Persson
Mar 28 '07 #160
JohnQ wrote:
:: "Bo Persson" <bo*@gmb.dkwrote in message
:: news:56*************@mid.individual.net...
::: JohnQ wrote:
::::: "Dennis (Icarus)" <no********@ever.invalidwrote in message
::::::
:::::: Well, programming itself is "hard".
:::::
::::: Well it doesn't have to be. I mean, that would be a goal of "Small
::::: C++": programming doesn't have to be so hard. From the get go, if
::::: the new programmer could rely on an 8-bit byte and integer types
::::: of specific widths exclusively, just that would help propel
::::: someone to productivity with a language faster. type.h is
::::: probably where I'd start if I was to start laying out "Small
::::: C++": a standard set of integer types of guaranteed width and no
::::: nebulous integer types (no "is 32 bits on a 32 bit machine, 64
::::: bits on a 64 bit machine" etc.).
:::
::: Why is having a certain number of bits in an integer so good?
::
:: Inter-application communication. Portable data storage.

You get that by specifying the communications protocol, and the data storage
format.

Not by forcing everyone else to use you favorite format.

::
::: If you use it as a counter for number of objects (like characters),
::: isn't it EXTREMELY good that it is 16 bits on 16-bit hardware, 32
::: bits on 32-bit hardware, 36 bits on 36-bit hardware, and 64 bits on
::: 64-bit hardware?
::
:: No, not extremely. It's pretty trivial if you ask me.
::
:::
::: Not too big, not too small, but just right!
:::
:::
::: Just consider if we were to specify 9-bit bytes, 36-bit ints, and
::: 72-bit floating point for everyone, just because some machines look
::: like that.
::
:: I like 8-bit bytes and guaranteed-width integers. So does the
:: internet.

But that's at the network interface layer. The 9-bit machine will have to
convert to and from the proper protocol. Not a problem, as network transport
is much slower anyway.

But when I do some computations on my 36-bit machine, I want to be ALLOWED
to use 36-bit ints and 72-bit doubles. If the language says that it MUST
ALWAYS be 32-bit and 64-bit, I'm toast.

With Java, that is the case. With C++, it is not. I see that as a advantage!
Bo Persson
Mar 28 '07 #161
"JohnQ" <jo***********************@yahoo.comwrote in message
news:Qs*******************@newssvr14.news.prodigy. net...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:84***************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:Ht*******************@newssvr14.news.prodigy. net...
>
<snip>
>
Well given that that is a goal of the new language, where it was not so
with
C++, some bit of assumption can be made.
I'm sure you remember what happens when you assume.

"assume" was a bad word then. Theorizing would be better. It's not like
I'm
pulling all of this out of thin air. There are reasonable goals and
directions for further investigation and prototyping.
But, as yet, since nothing as yet exists, you can't really say whether it
will or not.
>
>



Interesting that you find no other language in which you have
reasonable
confidence that, given the specification, that the programmer will
prodce
the desired result.

That's not the only criteria.

That is what I asked about though.

I see no question in there.
It was above.
So in what language(s) do you think its easy to have reasonable
confidence
that, given their specification, the programmer will produce what was
envisions (vs what was written in the spec?)

Small C++.
I find it interesting that you think a hypothetical, non-existent language
gives you reasonable confidence that ,given their specification, the
programmer will produce what was envisioned, and NO other language.

<snip>
>
Trying to write obfuscated code and doing it inherently because of the
popular usage of the language constructs are entirely different
animals.

And C allows one to write obfuscated code due to popular usage of the
language constructs.

There are more mechanisms in C++ hence more possibility for obfuscation.
Just the "template obfuscation machinery" should be enough proof of that.
(Of course I am using "obfuscation" to mean
"incomprehsible/unmaintainable"
at worst, or "hard to understand" at best).
Then by that logic, a Small-C++ programmer has a higher proability of
writing obfuscated (incomprehensible/unmaintainable/hard to understand) code
since it will have more mechanisms than C. Or will it? :-)

Dennis
Mar 29 '07 #162
"JohnQ" <jo***********************@yahoo.comwrote in message
news:QV******************@newssvr14.news.prodigy.n et...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:6d***************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:uq***************@newssvr21.news.prodigy.net. ..
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:2b*************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:EO************@newssvr22.news.prodigy.net...
<snip>
>
For the myriad of reasons given since this thread started.

Ok, so why do you use it?

Because it is the closest thing to what I want in a language. It's
drifting
more and more away though. What was once even thought to be "all I ever
wanted in a language" now leaves me longing for something better based
upon
lessons learned over the years. C++ can't evolve to be that replacement
because it is encumbered by backward compatibility and is now decidedly
too
broad. (Or something like that).
Backward compatibility is important, but there have been times that its
been
ignored.
Make a strong enough case at the standards committee and.......

It sounds easier just to create a new language for new development where a
codebase does not exist. Why deal with politics if you don't have to?
Also,
C++ is obviously on an expansion-of-features path. I don't foresee any
feature being removed ever, so the compiler system development capability
(toolchain) for C++ will only be possible with millions of dollars of
development or equivalent resources. Perhaps it's idealistic to think that
a
powerful-enough language could be developed that keeps toolchain
development
accessible to the masses, but I for one think that it may be possible.
Whether it is worth my time or not is another story.
Well, the key thing is that these features aren't being added just for the
sake of change
They're being requested because they fill a need.

I find it interesting, also, that the one language you think gives
"reasonable confidence that, given their specfication, the programmer will
produce what was envisioned".....may not be worth your time?
<snip>
>
>





C++ is hard to learn.

It depends on who is learning it and from what book/person ;J

No it doesn't. It's hard. Don't even bother perpetuating this
piece
of
this
post because we will just have to agree to disagree on that one.

Well, programming itself is "hard".

Well it doesn't have to be. I mean, that would be a goal of "Small
C++":
programming doesn't have to be so hard. From the get go, if the new
programmer could rely on an 8-bit byte and integer types of specific
widths
exclusively, just that would help propel someone to productivity
with
a
language faster. type.h is probably where I'd start if I was to
start
laying
out "Small C++": a standard set of integer types of guaranteed width
and
no
nebulous integer types (no "is 32 bits on a 32 bit machine, 64 bits
on
a
64
bit machine" etc.).

Ahh..so someone having difficulty with "int" and float" would find
them
immediately accessible if they know that both are 32-bit?
:-)

I was talking about ints.
Yes.
>

So you have int as 32-bit exclusively,

No, I didn't say that. I said you have guaranteed width integers and a
byte
is 8 bits.
I realize that, I was using an example. Note the comma as opposed to a
period.

Well an extraneous scenario then.
John, it was your scenario - I just picked the specific width. :-)
>
>
then it performs poorly on 16-bit
CPUs compared to ones that use the "native type".
So what is the guaranteed width?
Some compilers already provide as an extenson __int16, __int32, __int64,
etc.

I'm suggesting that only guaranteed width integers should be available to
avoid confusion about what happens from platform to platform. (Though I
haven't completely decided that a platform-specific-width integer is a bad
idea). Perhaps another simplification would be to have only signed integer
types.
That wouldn't be a good thing.

<snip>

Dennis
Mar 29 '07 #163
"JohnQ" <jo***********************@yahoo.comwrote in message
news:fv*******************@newssvr14.news.prodigy. net...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:3f**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:tB*******************@newssvr14.news.prodigy. net...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:1e***************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:58****************@newssvr21.news.prodigy.net ...

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:d7**************************@KNOLOGY.NET...
<snip>
There's no need for C++ IO though to read/write data. Just wrap the
(better)
platform APIs into a nicer "std library".

There is a need for C++ IO. The current system allows classes to
serialize
themselves.

There's more than one way to skin a cat.
Indeed.
>
What are your thoughts on implementing a replacement?

I'm don't think it is a primary concern at the outset. IO tends to be
application-specific.
Oh, I think it'd be a pretty important consideration.

It's at the library level rather than the language proper level.
Foundations
first. Higher level things afterwards. For the most part.
Given that object-oriented programming tries to hide object details.
They know how to create (initialize), copy, assign, clean up, it seems
logical that the i/o mechanism would be a "foundation" issue.
Given that you're not fond of C++'s stream mechanism and <<, >(gained
through operator overloading), you'd need to have a means for doing so.
After all, if you want a clearer token to set as an i/o operator, that'd be
part of the language.
If you keep the idea of operator overloadig, then that's anothr item that
can lead to "obfuscated code".

Dennis
Mar 29 '07 #164

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:1c**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:Qs*******************@newssvr14.news.prodigy. net...
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:84***************************@KNOLOGY.NET. ..
"JohnQ" <jo***********************@yahoo.comwrote in message
news:Ht*******************@newssvr14.news.prodigy. net...
<snip>
>>
Well given that that is a goal of the new language, where it was not
so
with
C++, some bit of assumption can be made.

I'm sure you remember what happens when you assume.

"assume" was a bad word then. Theorizing would be better. It's not like
I'm
>pulling all of this out of thin air. There are reasonable goals and
directions for further investigation and prototyping.

But, as yet, since nothing as yet exists, you can't really say whether it
will or not.
I can make some deductions from my own libraries.
>
>>
>>

Interesting that you find no other language in which you have
reasonable
confidence that, given the specification, that the programmer
will
prodce
the desired result.

That's not the only criteria.

That is what I asked about though.

I see no question in there.

It was above.
So in what language(s) do you think its easy to have reasonable
confidence
that, given their specification, the programmer will produce what was
envisions (vs what was written in the spec?)

Small C++.

I find it interesting that you think a hypothetical, non-existent language
gives you reasonable confidence that ,given their specification, the
programmer will produce what was envisioned, and NO other language.
I like C++ though overall. Why would I look at another language when I've
looked at them already and made the choice to go with C++ over them?
>
<snip>
>>
Trying to write obfuscated code and doing it inherently because of the
popular usage of the language constructs are entirely different
animals.
>
And C allows one to write obfuscated code due to popular usage of the
language constructs.

There are more mechanisms in C++ hence more possibility for obfuscation.
Just the "template obfuscation machinery" should be enough proof of that.
(Of course I am using "obfuscation" to mean
"incomprehsible/unmaintainable"
>at worst, or "hard to understand" at best).

Then by that logic, a Small-C++ programmer has a higher proability of
writing obfuscated (incomprehensible/unmaintainable/hard to understand)
code
since it will have more mechanisms than C. Or will it? :-)
The goal is to create mechanisms that aren't exploitable if possible.
Templates started out as simple text replacement and evolved into
incomprehensibility as sometimes applied.

John
Mar 29 '07 #165

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:44**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:fv*******************@newssvr14.news.prodigy. net...
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:3f**************************@KNOLOGY.NET.. .
"JohnQ" <jo***********************@yahoo.comwrote in message
news:tB*******************@newssvr14.news.prodigy. net...

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:1e***************************@KNOLOGY.NET. ..
"JohnQ" <jo***********************@yahoo.comwrote in message
news:58****************@newssvr21.news.prodigy.net ...

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:d7**************************@KNOLOGY.NET.. .
<snip>
There's no need for C++ IO though to read/write data. Just wrap the
(better)
platform APIs into a nicer "std library".

There is a need for C++ IO. The current system allows classes to
serialize
themselves.

There's more than one way to skin a cat.

Indeed.

What are your thoughts on implementing a replacement?

I'm don't think it is a primary concern at the outset. IO tends to be
application-specific.

Oh, I think it'd be a pretty important consideration.

It's at the library level rather than the language proper level.
Foundations
>first. Higher level things afterwards. For the most part.

Given that object-oriented programming tries to hide object details.
They know how to create (initialize), copy, assign, clean up, it seems
logical that the i/o mechanism would be a "foundation" issue.
???
Given that you're not fond of C++'s stream mechanism and <<, >>
I'm not fond of operator overloading or operators in general, such as >>/<<.
>(gained
through operator overloading), you'd need to have a means for doing so.
I still see it (IO) as a library issue.
After all, if you want a clearer token to set as an i/o operator, that'd
be
part of the language.
Again, I doubt I would assign an operator(s) for IO.
If you keep the idea of operator overloadig, then that's anothr item that
can lead to "obfuscated code".
Like I said, I'm not fond of operator overloading or operators in general.
They make code (other than numeric code) hard to grok. Especially overloaded
operators.

John
Mar 29 '07 #166

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:a0**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:QV******************@newssvr14.news.prodigy.n et...
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:6d***************************@KNOLOGY.NET. ..
"JohnQ" <jo***********************@yahoo.comwrote in message
news:uq***************@newssvr21.news.prodigy.net. ..

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:2b*************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:EO************@newssvr22.news.prodigy.net...

<snip>

For the myriad of reasons given since this thread started.

Ok, so why do you use it?

Because it is the closest thing to what I want in a language. It's
drifting
more and more away though. What was once even thought to be "all I
ever
wanted in a language" now leaves me longing for something better based
upon
lessons learned over the years. C++ can't evolve to be that
replacement
because it is encumbered by backward compatibility and is now
decidedly
too
broad. (Or something like that).

Backward compatibility is important, but there have been times that its
been
ignored.
Make a strong enough case at the standards committee and.......

It sounds easier just to create a new language for new development where
a
codebase does not exist. Why deal with politics if you don't have to?
Also,
>C++ is obviously on an expansion-of-features path. I don't foresee any
feature being removed ever, so the compiler system development capability
(toolchain) for C++ will only be possible with millions of dollars of
development or equivalent resources. Perhaps it's idealistic to think
that
a
>powerful-enough language could be developed that keeps toolchain
development
>accessible to the masses, but I for one think that it may be possible.
Whether it is worth my time or not is another story.

Well, the key thing is that these features aren't being added just for the
sake of change
They're being requested because they fill a need.
C++: the "all things for all people" language. "One size fits all".
>
I find it interesting, also, that the one language you think gives
"reasonable confidence that, given their specfication, the programmer will
produce what was envisioned".....may not be worth your time?
Well, I can control my own code as I don't have teams of developers to
manage. In the future, that may change and I'll personally have the troubles
of any other manager faced with C++ development (although I can curb a lot
of the chaff by requiring use of in-house libraries, patterns, techniques
and such). There's already so many developers who have the required
knowledge to start prototyping "Small C++". Rather than getting directly
involved with the nitty gritty low level compiler design details, I'd rather
sanction it, as I have other things I'm involved with and want to continue
pursuing: I can't do everything.
>
So you have int as 32-bit exclusively,

No, I didn't say that. I said you have guaranteed width integers and a
byte
is 8 bits.

I realize that, I was using an example. Note the comma as opposed to a
period.

Well an extraneous scenario then.

John, it was your scenario - I just picked the specific width. :-)
Your's was a different scenario. I'm not sure what your point was/is. I just
said that having guaranteed width integers exclusively sounds like a
lucrative simplification and that it could produce productive programmers
faster.
>
>>
>

then it performs poorly on 16-bit
CPUs compared to ones that use the "native type".

So what is the guaranteed width?
Some compilers already provide as an extenson __int16, __int32,
__int64,
etc.

I'm suggesting that only guaranteed width integers should be available to
avoid confusion about what happens from platform to platform. (Though I
haven't completely decided that a platform-specific-width integer is a
bad
idea). Perhaps another simplification would be to have only signed
integer
types.

That wouldn't be a good thing.
Why not? One less choice to be faced with at every integer type selection.

John
Mar 29 '07 #167

"Bo Persson" <bo*@gmb.dkwrote in message
news:56*************@mid.individual.net...
JohnQ wrote:
:: "Bo Persson" <bo*@gmb.dkwrote in message
:: news:56*************@mid.individual.net...
::: JohnQ wrote:
::::: "Dennis (Icarus)" <no********@ever.invalidwrote in message
::::::
:::::: Well, programming itself is "hard".
:::::
::::: Well it doesn't have to be. I mean, that would be a goal of "Small
::::: C++": programming doesn't have to be so hard. From the get go, if
::::: the new programmer could rely on an 8-bit byte and integer types
::::: of specific widths exclusively, just that would help propel
::::: someone to productivity with a language faster. type.h is
::::: probably where I'd start if I was to start laying out "Small
::::: C++": a standard set of integer types of guaranteed width and no
::::: nebulous integer types (no "is 32 bits on a 32 bit machine, 64
::::: bits on a 64 bit machine" etc.).
:::
::: Why is having a certain number of bits in an integer so good?
::
:: Inter-application communication. Portable data storage.

You get that by specifying the communications protocol, and the data
storage format.

Not by forcing everyone else to use you favorite format.
It's consistency, not force. Use C++ if you like "portable to 9-bit
processors"-type generality. If you don't give a care about that level of
portability, use Small C++ and have a simply elegant life.
>
::
::: If you use it as a counter for number of objects (like characters),
::: isn't it EXTREMELY good that it is 16 bits on 16-bit hardware, 32
::: bits on 32-bit hardware, 36 bits on 36-bit hardware, and 64 bits on
::: 64-bit hardware?
::
:: No, not extremely. It's pretty trivial if you ask me.
::
:::
::: Not too big, not too small, but just right!
:::
:::
::: Just consider if we were to specify 9-bit bytes, 36-bit ints, and
::: 72-bit floating point for everyone, just because some machines look
::: like that.
::
:: I like 8-bit bytes and guaranteed-width integers. So does the
:: internet.

But that's at the network interface layer. The 9-bit machine will have to
convert to and from the proper protocol. Not a problem, as network
transport is much slower anyway.
But I don't care about 9-bit machines: I'm creating an 8-bit byte language
and relegating C++ to the fringe cases. Why penalize the common case for all
the special cases?
>
But when I do some computations on my 36-bit machine, I want to be ALLOWED
to use 36-bit ints and 72-bit doubles. If the language says that it MUST
ALWAYS be 32-bit and 64-bit, I'm toast.
Then use C++, as it handles all the special cases, and not Small C++.
Simple. Being able to rely on 8-bit bytes, and unpadded structures, sounds
beautiful to me.
>
With Java, that is the case. With C++, it is not. I see that as a
advantage!
John
Mar 29 '07 #168
"JohnQ" <jo***********************@yahoo.comwrote in message
news:Pb*****************@newssvr21.news.prodigy.ne t...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:a0**************************@KNOLOGY.NET...
<snip>

Well, the key thing is that these features aren't being added just for
the
sake of change
They're being requested because they fill a need.

C++: the "all things for all people" language. "One size fits all".
And, I suspect that, were Small-C++ created, standardized, it too would
grow, and expand, becoming the very thing you dislike.

<snip>

That wouldn't be a good thing.

Why not? One less choice to be faced with at every integer type selection.
Uhm....because a variable's value represetns something, and if that
something can never be negative, its better to use unsigned.

Dennis
Mar 29 '07 #169

"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:5f***************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:Pb*****************@newssvr21.news.prodigy.ne t...
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:a0**************************@KNOLOGY.NET.. .
<snip>
>
Well, the key thing is that these features aren't being added just for
the
sake of change
They're being requested because they fill a need.

C++: the "all things for all people" language. "One size fits all".

And, I suspect that, were Small-C++ created, standardized, it too would
grow, and expand, becoming the very thing you dislike.

<snip>
>
That wouldn't be a good thing.

Why not? One less choice to be faced with at every integer type
selection.

Uhm....because a variable's value represetns something, and if that
something can never be negative, its better to use unsigned.
I default to using unsigned ints though too. It's pretty trivial. I'm OK
with it either way. It does show though how everything would be reevaluated
for selection or exclusion in Small C++.

John
Mar 29 '07 #170

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: lawrence | last post by:
I'm trying to read up on the rfc's that govern form inputs. Much of what I'm reading is stuff I didn't know before and some of it is alarming. This one left with me questions: ...
1
by: Harag | last post by:
Hi all Classic ASP, Textpad Local "test" WebServer. IIS5 Well my MS script debugger isn't running and I can't findout why. I'm sick of it failing on me so was looking for an alternative. I...
13
by: penguin732901 | last post by:
Checking back for discussions, there was a lot of talk about 2000 being slower than 97, but not so much lately. What is the latest opinion? Anyone care to set up a poll for how many NG members...
4
by: Hai Nguyen | last post by:
I'm learning C sharp and do not like vb much. I'm creatiing a wepage using panel to test myself. I tried to use these code below, which is written in VB, and to transform them to c sharp but I got...
7
by: Skc | last post by:
Hullo Just like to check whether anyone has tried RentACoder. I intend to farm out a small job that must use C#, WinForms, ADO.Net for around US$400, but don't know whether RentACoder is...
8
by: Dgates | last post by:
Has anyone typed up an index for the O'Reilly book "C# and VB.NET Conversion?" I'm just learning C#, and often using this little book to see which VB.NET terms translate directly to some term in...
0
by: Gareth | last post by:
I cannot find a reference anywhere to anyone having done this successfully... can anyone enlighten me on how you get a SSL login page working with ASP.NET and forms authentication. I have...
2
by: Bruno Alexandre | last post by:
Hi guys, does anyone know where is the Website used in the MSDN "Lear ASP.NET 2.0 with Jeff Prosise" (http://msdn.microsoft.com/asp.net/beta2/multimedia/default.aspx) events? The website used...
5
by: tony | last post by:
I'm using PHP 5 on Win-98 command line (ie no web server involved) I'm processing a large csv file and when I loop through it I can process around 275 records per second. However at around...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.