Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > "Small C++" Anyone?

Reply
Thread Tools

"Small C++" Anyone?

 
 
Bo Persson
Guest
Posts: n/a
 
      03-28-2007
JohnQ wrote:
:: "Bo Persson" <(E-Mail Removed)> wrote in message
:: news:(E-Mail Removed)...
::: JohnQ wrote:
::::: "Dennis (Icarus)" <(E-Mail Removed)> wrote 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


 
Reply With Quote
 
 
 
 
Dennis \(Icarus\)
Guest
Posts: n/a
 
      03-29-2007
"JohnQ" <(E-Mail Removed)> wrote in message
news:QsxOh.19266$(E-Mail Removed). net...
>
> "Dennis (Icarus)" <(E-Mail Removed)> wrote in message
> news:84a5f$460a9de6$1860878d$(E-Mail Removed)...
> > "JohnQ" <(E-Mail Removed)> wrote in message
> > news:HtwOh.19239$(E-Mail Removed). 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


 
Reply With Quote
 
 
 
 
Dennis \(Icarus\)
Guest
Posts: n/a
 
      03-29-2007
"JohnQ" <(E-Mail Removed)> wrote in message
news:QVwOh.19249$(E-Mail Removed) et...
>
> "Dennis (Icarus)" <(E-Mail Removed)> wrote in message
> news:6de81$460a47f9$1860878d$(E-Mail Removed)...
> > "JohnQ" <(E-Mail Removed)> wrote in message
> > news:uqbOh.3351$(E-Mail Removed). ..
> >>
> >> "Dennis (Icarus)" <(E-Mail Removed)> wrote in message
> >> news:2b66$460877e5$1860878d$(E-Mail Removed)...
> >> > "JohnQ" <(E-Mail Removed)> wrote in message
> >> > news:EOXNh.67$(E-Mail Removed)...
> >> >>

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


 
Reply With Quote
 
Dennis \(Icarus\)
Guest
Posts: n/a
 
      03-29-2007
"JohnQ" <(E-Mail Removed)> wrote in message
news:fvxOh.19267$(E-Mail Removed). net...
>
> "Dennis (Icarus)" <(E-Mail Removed)> wrote in message
> news:3f47$460a9de7$1860878d$(E-Mail Removed)...
> > "JohnQ" <(E-Mail Removed)> wrote in message
> > news:tBwOh.19241$(E-Mail Removed). net...
> >>
> >> "Dennis (Icarus)" <(E-Mail Removed)> wrote in message
> >> news:1e1a3$460a47fa$1860878d$(E-Mail Removed)...
> >> > "JohnQ" <(E-Mail Removed)> wrote in message
> >> > news:58bOh.3344$(E-Mail Removed) ...
> >> >>
> >> >> "Dennis (Icarus)" <(E-Mail Removed)> wrote in message
> >> >> news:d798b$460877e2$1860878d$(E-Mail Removed)...
> >> > <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


 
Reply With Quote
 
JohnQ
Guest
Posts: n/a
 
      03-29-2007

"Dennis (Icarus)" <(E-Mail Removed)> wrote in message
news:1c973$460b0fb7$1860878d$(E-Mail Removed)...
> "JohnQ" <(E-Mail Removed)> wrote in message
> news:QsxOh.19266$(E-Mail Removed). net...
>>
>> "Dennis (Icarus)" <(E-Mail Removed)> wrote in message
>> news:84a5f$460a9de6$1860878d$(E-Mail Removed)...
>> > "JohnQ" <(E-Mail Removed)> wrote in message
>> > news:HtwOh.19239$(E-Mail Removed). 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


 
Reply With Quote
 
JohnQ
Guest
Posts: n/a
 
      03-29-2007

"Dennis (Icarus)" <(E-Mail Removed)> wrote in message
news:44844$460b0fb8$1860878d$(E-Mail Removed)...
> "JohnQ" <(E-Mail Removed)> wrote in message
> news:fvxOh.19267$(E-Mail Removed). net...
>>
>> "Dennis (Icarus)" <(E-Mail Removed)> wrote in message
>> news:3f47$460a9de7$1860878d$(E-Mail Removed)...
>> > "JohnQ" <(E-Mail Removed)> wrote in message
>> > news:tBwOh.19241$(E-Mail Removed). net...
>> >>
>> >> "Dennis (Icarus)" <(E-Mail Removed)> wrote in message
>> >> news:1e1a3$460a47fa$1860878d$(E-Mail Removed)...
>> >> > "JohnQ" <(E-Mail Removed)> wrote in message
>> >> > news:58bOh.3344$(E-Mail Removed) ...
>> >> >>
>> >> >> "Dennis (Icarus)" <(E-Mail Removed)> wrote in message
>> >> >> news:d798b$460877e2$1860878d$(E-Mail Removed)...
>> >> > <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


 
Reply With Quote
 
JohnQ
Guest
Posts: n/a
 
      03-29-2007

"Dennis (Icarus)" <(E-Mail Removed)> wrote in message
news:a04fd$460b0fb7$1860878d$(E-Mail Removed)...
> "JohnQ" <(E-Mail Removed)> wrote in message
> news:QVwOh.19249$(E-Mail Removed) et...
>>
>> "Dennis (Icarus)" <(E-Mail Removed)> wrote in message
>> news:6de81$460a47f9$1860878d$(E-Mail Removed)...
>> > "JohnQ" <(E-Mail Removed)> wrote in message
>> > news:uqbOh.3351$(E-Mail Removed). ..
>> >>
>> >> "Dennis (Icarus)" <(E-Mail Removed)> wrote in message
>> >> news:2b66$460877e5$1860878d$(E-Mail Removed)...
>> >> > "JohnQ" <(E-Mail Removed)> wrote in message
>> >> > news:EOXNh.67$(E-Mail Removed)...
>> >> >>
>> > <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


 
Reply With Quote
 
JohnQ
Guest
Posts: n/a
 
      03-29-2007

"Bo Persson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> JohnQ wrote:
> :: "Bo Persson" <(E-Mail Removed)> wrote in message
> :: news:(E-Mail Removed)...
> ::: JohnQ wrote:
> ::::: "Dennis (Icarus)" <(E-Mail Removed)> wrote 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


 
Reply With Quote
 
JohnQ
Guest
Posts: n/a
 
      03-29-2007

"Dennis (Icarus)" <(E-Mail Removed)> wrote in message
news:5fbe3$460bf3aa$1860878d$(E-Mail Removed)...
> "JohnQ" <(E-Mail Removed)> wrote in message
> newsbSOh.3864$(E-Mail Removed) t...
>>
>> "Dennis (Icarus)" <(E-Mail Removed)> wrote in message
>> news:a04fd$460b0fb7$1860878d$(E-Mail Removed)...

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


 
Reply With Quote
 
Dennis \(Icarus\)
Guest
Posts: n/a
 
      03-29-2007
"JohnQ" <(E-Mail Removed)> wrote in message
newsbSOh.3864$(E-Mail Removed) t...
>
> "Dennis (Icarus)" <(E-Mail Removed)> wrote in message
> news:a04fd$460b0fb7$1860878d$(E-Mail Removed)...

<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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments