"Small C++" Anyone?

S

SasQ

Dnia Fri, 16 Mar 2007 22:40:01 +0000, JohnQ napisa³(a):
I can't think of all the things that C++ doesn't take for granted,
such as 8-bit bytes

Because byte doesn't have to be 8-bit. Dennis actually has shown that
there are platforms where bytes are 6-bit. If there were only 8-bit
bytes in C++, it would be impossible to use C++ for that.

The same problem has emerged with the Inthernet protocols. Because
of that different bit-sizes of bytes on different platforms, all
Internet standards use a term of OCTET for 8-bit packets and BYTE
only for machine-specific bytes. So does C++, but it use a term of
CHARACTER - the count of bits which is possible to store any
character code on the specific platform. It's only a coincidence
that on the most used and most known platforms the 'char' type
has a size of 8 bits, because it use 8-bit bytes for storing
character codes.
but if a language was more platform-specific, it would
be easier to program in also.

It's easier to program for that specific platform :p But try to
use that kind of language to write a platform-independent code ;)
C++ is hard to learn.

It depends on who is learning it and from what book/person ;J
To manage projects where it is used, one should know how to
use it very well IMO.

One should know the language well if one want to code in it :p
It's impossible to write a book knowing only a few words.
It's much easier in C++ (to write unmaintainable code)!

Can you proove it, or you're only telling us truisms?
It's much easier for a bad coder. But [like Dennis mentioned already]
for a bad coder it's possible in any language. It's also that the more
features the language has, the more possibilities to screw up has a
bad coder ;) But it's not the language's fault :p
I didn't say axe the container library, just templates. Other
non-template containers would replace the template ones.

How do you make a container possible to contain object of any
arbitrary type, without templates?
Indeed! Use with caution (mostly, don't use).

Use with thinking ;)
Dennis said that operator overloading CAN lead to messy code,
not that it HAVE TO lead to messy code ;J Feel the difference:

See? :>
For math they make a lot more sense. I haven't thought about
operators in regards to decreasing complexity of implementation.
From the maintainable code standpoint, I don't think juat that
reason is enough to axe operator overloading (Who know's,
maybe that is next!).

Even if you axe templates, operator overloading, and other things
that you don't understand well, the bad programmer still would be
able to write bad programs using 'goto' to produce spaghetti code.
But it's not a C++ fault and any other languages' fault. The knife
can be uset do cut a bread, or to kill someone.
 
W

Walter Bright

SasQ said:
Dnia Fri, 16 Mar 2007 22:40:01 +0000, JohnQ napisa³(a):


Because byte doesn't have to be 8-bit. Dennis actually has shown that
there are platforms where bytes are 6-bit. If there were only 8-bit
bytes in C++, it would be impossible to use C++ for that.

You can't implement C++ with 6 bit bytes anyway. Not enough characters
to represent the source character set.

The same problem has emerged with the Inthernet protocols. Because
of that different bit-sizes of bytes on different platforms, all
Internet standards use a term of OCTET for 8-bit packets and BYTE
only for machine-specific bytes. So does C++, but it use a term of
CHARACTER - the count of bits which is possible to store any
character code on the specific platform. It's only a coincidence
that on the most used and most known platforms the 'char' type
has a size of 8 bits, because it use 8-bit bytes for storing
character codes.

It's not a coincidence. It's that C++ compiler writers are generally
sensible people. If you were writing a C++ compiler for an 8 bit byte
machine, and randomly decided you were going to have 'char' be 9 bits
long, your compiler would be a laughingstock.

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

It's hard to learn, period. Case in point - there's a world's leading
expert on the preprocessor (Paul Mensonidas). If it was easy, why is
there a need for a leading expert on it? Is there a world's leading
expert for 2+2?

Even if you axe templates, operator overloading, and other things
that you don't understand well, the bad programmer still would be
able to write bad programs using 'goto' to produce spaghetti code.
But it's not a C++ fault and any other languages' fault. The knife
can be uset do cut a bread, or to kill someone.

Good language design lines up correct practice with what is convenient
and natural for humans to write. Unfortunately, with C++ the convenient,
natural way is often the deprecated, wrong way. Case in point:

int foo[6]; // convenient, natural, deprecated, bad, boo, hiss

std::vector<int> foo(6); // correct, modern, wordy, tedious
 
K

kwikius

It's hard to learn, period. Case in point - there's a world's leading
expert on the preprocessor (Paul Mensonidas). If it was easy, why is
there a need for a leading expert on it? Is there a world's leading
expert for 2+2?

What is interesting about the preprocessor is that it can be used as a
bridge to extend the language. I think this was the case for
experimental implementation of templates. For example it has been used
by Arkadiy Vertleyb and Peder Holt to provide a working cross platform
type deduction facility (Boost.Typeof):

http://tinyurl.com/23r9at

which is very likely to be incorporated into C++. Similarly to
simulate quasi variadic templates, again likely to be included and so
on and so forth. Paul Mensonides formalisation of the preprocessor
library has been used a great deal to implement these. OTOH you can
use the preprocessor very simply too.

There is a strange ability of C++ to evolve as in the above examples.
Many of the weirdnesses, the lack of symmetry of the language has
actually been beneficial in odd ways as it allows hacks that can be
used to evolve the language. From reading D&E, it seems that the goal
was always to allow the largest possible freedom which has helped this
process.

It is unclear to me what the future holds for C++. There must come a
point where the language is too complicated to implement commercially,
though I suspect there will always be at least a gcc compiler (e.g
ConceptGCC), but I think that its certainly a lesson that doing things
the wrong way from a classical point of view can provide more rewards
than doing things the right way. For example I think that Bjarne
Stroustrup was advised at some point to use a parser generator to
write CFront, but opted instaed to write the thing by hand and IMO a
lot of the way C++ is now springs from that decision..

C++ is probably now a language in middle age, but whatever its future
and whatever its faults,it certainly must be seen historically as one
of the great programming languages.

regards
Andy Little
 
A

Alf P. Steinbach

* SasQ:
Source character set and execution environment character set are
two different things. You can implement a compiler that runs on
a platform with 8-bit characters for source and generates 6-bit
machine code for other platform, where there are 6-bit bytes/chars.
The Standard doesn't require any particular bit count for 'char'.
It requires only that sizeof(char) == 1 [counting in bytes] and
is able to contain any character code from the character set of
the execution environment.

A C++ char must be 8 bits more or more.
 
S

SasQ

Dnia Sat, 17 Mar 2007 02:58:14 -0700, Walter Bright napisa³(a):
You can't implement C++ with 6 bit bytes anyway. Not enough
characters to represent the source character set.

Source character set and execution environment character set are
two different things. You can implement a compiler that runs on
a platform with 8-bit characters for source and generates 6-bit
machine code for other platform, where there are 6-bit bytes/chars.
The Standard doesn't require any particular bit count for 'char'.
It requires only that sizeof(char) == 1 [counting in bytes] and
is able to contain any character code from the character set of
the execution environment.
It's not a coincidence. It's that C++ compiler writers are
generally sensible people. If you were writing a C++ compiler
for an 8 bit byte machine, and randomly decided you were going
to have 'char' be 9 bits long, your compiler would be a
laughingstock.

It depends on the target machine which the compiler is made for.
If the target machine has 9-bit bytes/characters, there's nothing
to laugh of :p The coincidence I've said about was that the
platforms with 8-bit bytes are the most known, so a few people
would consider that there are platforms with different character
sizes. The coincidence is you are [very probably] using exactly
that platform so you think it's the only possible.
C++ commitee hadn't the possibility for that kind of assumptions.
It's hard to learn, period.

It's not hard, period, I won, and I'm taking all your gold :p
Case in point - there's a world's leading expert on the
preprocessor (Paul Mensonidas). If it was easy, why is there
a need for a leading expert on it? Is there a world's leading
expert for 2+2?

Will you deduce also that C++ is stupid from the fact that
there are world's leading experts in stupidity? :J
The fact that there are leading experts not implicate that
one have to be expert to use C++.
Good language design lines up correct practice with what is
convenient and natural for humans to write.

The problem is that different practices are convenient for different
people. One like using goto, the other hates classes because "they're
too bloaty", one another don't use templates because don't understand
them... Bad code is the effect of bad habbits of programmers. Many
programmers has come to C++ from other languages and still try to
write programs in C++ in the similar ways they do in that other
languages. C programmers prefer to use ye olde char arrays instead
of std::string or implement a list for any used data type by hands,
instead of using std::list or std::vector. Java programmers can't
handle operator overloading and think it's "strange and unusefull" ;J
They swear on multiple inheritance because they learned to think
in terms of interfaces. They're trying to stuff everything into
classes because in Java there isn't any other possibility. They're
trying to initialize class members in a class definition because
that's the way they've do it in Java. Pascal programmers write
"VeryLongObjectName := VeryLongObjectName + 2" instead of
"VeryLongObjectName += 2", and
"VeryLongObjectName := VeryLongObjectName + 1" instead of
"++VeryLongObjectName" because they uset do to that in Pascal and
it's possible to do the same in C++, so they do.
And some programmers simply learned C++ from some bad old book
[i.e. "C++ for Dummies" where the author is wondering why comments
in C++ don't end with semicolon "like the other statements do" :pPP]
and don't know anything about software designing/modelling, so
they write bulky, unreadable and unmaintainable code.
It's good to know the rationales behind the C++ features used.
If you know, you use it the proper way.
Unfortunately, with C++ the convenient, natural way is often
the deprecated, wrong way. Case in point:

int foo[6]; // convenient, natural, deprecated, bad, boo, hiss

Convenient for whom? :p
For me, worrying about writing out of array boundaries, allocating
more than it's needed in a case of "future needs", memory
allocation/deallocation/reallocation [for dynamic arrays], and
memory leaks, isn't convenient nor natural at all.

But it might be natural/convenient for a low-level programmer ;)
std::vector<int> foo(6); // correct, modern, wordy, tedious

You forgot "jazzy" :>

BTW...

typedef std::vector<int> IntVec;

and then:

IntVec myArray(6);

if you are scared by the syntax ;)

BTW2 it's not good comparison, because int foo[6] can contain
only 6 elements, and std::vector<int> foo(6) can contain 6 and
more if it's needed. The former can't contain more than 6 elements
and if you stuff-in more than 6 there, your ass is on fire :)
In the case of std::vector you don't need even to think about
that kind of problems ;) And that's the reason it's better,
not the "programming style".
 
S

SasQ

Dnia Sat, 17 Mar 2007 13:09:44 +0100, Alf P. Steinbach napisa³(a):
A C++ char must be 8 bits more or more.

"C++ Standard":
"(...)
3.9.1 Fundamental types [basic.fundamental]

1. Objects declared as characters (char) shall be large enough to store
any member of the implementation's basic character set.
(...)"

I dont' see any bits there...
 
B

Bo Persson

SasQ said:
Dnia Sat, 17 Mar 2007 13:09:44 +0100, Alf P. Steinbach napisa³(a):
A C++ char must be 8 bits more or more.

"C++ Standard":
"(...)
3.9.1 Fundamental types [basic.fundamental]

1. Objects declared as characters (char) shall be large enough to
store any member of the implementation's basic character set.
(...)"

I dont' see any bits there...

The minimum size comes (indirectly) from 18.2.2 saying that the <climits>
header has the same contents as the C header "limits.h". The C standard
requires CHAR_BIT to be 8 or higher.



Bo Persson
 
D

Dennis \(Icarus\)

Ian Collins said:
Bollocks. The code has nothing to do with a manager, it should be the
domain and responsibility of the development team.

Thats pretty much wht I think, also.
Use pair programming and collective code ownership and none of this crap
is necessary.

Yeah, pretty much.


What he means here, from what I can tell, is there's no way to harness, rein
in, the language.
Since the wild programmers can't be managed, attention must be focused on
the compiler.


Dennis
 
D

Dennis \(Icarus\)

Walter Bright said:
You can't implement C++ with 6 bit bytes anyway. Not enough characters
to represent the source character set.

EBCDIC doesn't have the right chaacters either, bwhcih is why, IIRC, there
are equivalent representations
to those characters.

It's hard to learn, period. Case in point - there's a world's leading
expert on the preprocessor (Paul Mensonidas). If it was easy, why is
there a need for a leading expert on it? Is there a world's leading
expert for 2+2?

Well, until now, I didnt know there was a leading expert on the
preprocessor.
:)
Even if you axe templates, operator overloading, and other things
that you don't understand well, the bad programmer still would be
able to write bad programs using 'goto' to produce spaghetti code.
But it's not a C++ fault and any other languages' fault. The knife
can be uset do cut a bread, or to kill someone.

Good language design lines up correct practice with what is convenient
and natural for humans to write. Unfortunately, with C++ the convenient,
natural way is often the deprecated, wrong way. Case in point:

int foo[6]; // convenient, natural, deprecated, bad, boo, hiss

So what's deprecated about that? If foo has no need to be expanded, why
bother with a vector?
In debug vector may check subscripts to see that they're in range, but if
you don't need that, nor need the other capabilities of vector.....?
std::vector<int> foo(6); // correct, modern, wordy, tedious

Dennis
 
D

Dennis \(Icarus\)

JohnQ said:
Let's see... BigCompany can either 1.) Develop departmental software with
C++ and a high-powered (read, expensive) IT manager, or 2.) Use a different
tool and omit the specialist requirement. Which are they going to choose?

Depends on what they're trying to do. For a multi-platform project, C#
wouldn't be a good tool, nor VB.
Heck, they could just choose to outsource the job to India. ;-)

But STL requires templates and that could lead to unmaintainable code if the
manager can't keep the programmers on a leash.

I guess trying to manage the compiler is easier than trying to manage your
team.
But if it's known it won't be moving, why not use the easy-to-use language
for that platform?

Go for it. Heck, I've said myself that when it comes to writing automation
clients with Windows, I prefer using C# to C++.
C# has nice language features/libraries that make this a bit easier (for me)
than C++.
Now, this isn't the fault of C++, since to Unix/Linux folks support for COM
automation may not be too appropriate.
No, just language-level things.
Ok.


Ouch, I sure wouldn't want to be the one to examine microscopically all that
template code the programmers wrote.


The manager needs to be able to control the product. It shouldn't be at the
whim of any/all of the programmers.

Without managing the programmers, they can't control the product.
Again, too labor intensive.

We don't find it too intensive. Is every line reviewed? Nah.
Significant changes, sure, especially when those changes are going into a
service pack.

And it takes more experience and years and therefor costs more with C++
because of all the ins and outs of it.

C++ is a powerful langauge, no doubt about it.
That's different: they are trying to make obfuscated code. With C++ and
templates and other features, the obfuscation is almost built-in to the
language! ;)

My point is, still, than unmaintainable code can be written in C, without
templates and other features. :)
Templates, operator overloading, function overloading, default arguments....
Have to? Why would they have to? Obviously you can make cosmic hierarchies
or not.

Ok, could you demonstrate non-template containers for any object?
This container class should invoke the appropriate methods on the class for
assignment, copy construction, etc.
Who says "Small C++" wouldn't have generics? They just won't be so
exploitable and won't be difficult to implement.

So they won't be as powerful?

Lets see, template default arguments? Template member functions?
At least "C with classes". ;)


At least they won't be trained to do it and think that is good coding for
production software.

And who thinks that? :)

Dennis
 
S

SasQ

Dnia Sat, 17 Mar 2007 15:22:00 +0100, Bo Persson napisa³(a):
The minimum size comes (indirectly) from 18.2.2 saying that
the <climits> header has the same contents as the C header
"limits.h". The C standard requires CHAR_BIT to be 8 or higher.

OK thanx, I've missed that. It would be better defined
explicitly, than 'indirectly', though.

Hmm.. But the 9-bit bytes [and more] are still OK, right? :J
 
B

Bo Persson

SasQ said:
Dnia Sat, 17 Mar 2007 15:22:00 +0100, Bo Persson napisa³(a):


OK thanx, I've missed that. It would be better defined
explicitly, than 'indirectly', though.

I guess the committee just wanted to avoid repeating the 500 or so pages of
the C standard.
Hmm.. But the 9-bit bytes [and more] are still OK, right? :J

9-bit bytes are very much present on machines like this

http://www.unisys.com/products/mainframes/os__2200__mainframes/model__specifications.htm


36-bit words, and everything. :)


Bo Persson
 
J

JohnQ

Ian Collins said:
Bollocks. The code has nothing to do with a manager, it should be the
domain and responsibility of the development team.

"Development team" usually means a range of people from all over the place
with varying degrees of experience. If "the development team" is not like
one of those conglomerations of staffing agency provided groups, but rather
a contractor who specializes in the type of software to be custom produced
for a project (or a product), ... well even then, the architecting,
engineering, designing is going to (or should IMO) be the responsibility of
few people (many times one key person). I'm talking about serious software,
not just something that doesn't matter as long as it works.
Use pair programming and collective code ownership and none of this crap
is necessary.

Ooooo... you pushed my button there. I'll refrain from my thoughts on that
practice (and in general, I think the topic may be drifting too far at that
level).
No he doesn't. He may be responsible for its delivery, but certainly
not its implementation.

There's two kinds of managers: lightweights and heavyweights. The latter are
skilled in both the engineering aspects and the managerial aspects. The
former are (hehe, glorified secretaries! ;) ) just skilled in management
techniques. Anyway, chances are, the heavyweight manager will also be the
project leader and calling the shots and making the critical decisions.

Nevermind the answer to your "what?".

John
 
S

SasQ

Dnia Sat, 17 Mar 2007 19:49:35 +0100, Bo Persson napisa³(a):
I guess the committee just wanted to avoid repeating the 500
or so pages of the C standard.

I think it would be convenient to split the standard document
into some smaller parts - the core language definition in one,
the C standard library in another, the C++ [STL?] library in
another, maybe some "additional guarantees for most common
platforms" in another...
It might be good also to create a place where language users
could post external libraries proposals, and other users
could compare it and choose the ones fullfilling their needs.
Languages [or platforms ;J] like Java or .NET has the little
advantage that all libraries are gathered in one place and
well defined/documented for their users. And there are
"standard" libraries for GUI, databases, communication,
threading, networking etc. There are many libraries for C++
doing the same, but it's not that easy to find it and compare.
Here C++ looses with its competitors ;J
The Commitee should consider this and do some tiding with
the external libraries, making them more accessible for users.
36-bit words, and everything. :)

Hmm... I've always wondered how C++ support 64-bit processors?
The standard and Stroustrup says that the type 'int' has size
most convenient for integer arithmetics and it usually correspond
to machine word and sizes of processor registers / data bus.
On 64-bit machines, that is 64 bit, so does 'int' have 64-bit there?
Or it's still 32-bit, and 'long' is 64-bit?
I've seen that Microsoft compilers use non-standard [not in C++]
'long long int' type for 64-bit integers, and 'int' is 32-bit.
I don't know how it fullfils the rule "most convenient for
integer arithmetics" :p but i suspect the next step would be
'long long long int' showing Bill's fallic wishes ;)
So what it should be?

Case 1 [suggested by actual standard I think]:
sizeof(short) == ? //dunno, but >= 2 and <= sizeof(int)
sizeof(int) == 8
sizeof(long) == 8

Case 2 [middle ground]:
sizeof(short) == 16
sizeof(int) == 32
sizeof(long) == 64

Case 3 [backward compatibility option]:
sizeof(short) == 16
sizeof(int) == 32
sizeof(long) == 32
sizeof(long long) == 64

Case 4 [think different]:
some other combination

Which one it might be and why?
 
D

Dennis \(Icarus\)

SasQ said:
Dnia Sat, 17 Mar 2007 19:49:35 +0100, Bo Persson napisa³(a):
I guess the committee just wanted to avoid repeating the 500
or so pages of the C standard.

I think it would be convenient to split the standard document
into some smaller parts - the core language definition in one,
the C standard library in another, the C++ [STL?] library in
another, maybe some "additional guarantees for most common
platforms" in another...
It might be good also to create a place where language users
could post external libraries proposals, and other users
could compare it and choose the ones fullfilling their needs.
Languages [or platforms ;J] like Java or .NET has the little
advantage that all libraries are gathered in one place and
well defined/documented for their users. And there are
"standard" libraries for GUI, databases, communication,
threading, networking etc. There are many libraries for C++
doing the same, but it's not that easy to find it and compare.
Here C++ looses with its competitors ;J

Ok, which GUI library should be the standard?
X? Win32?
Communication/Networking?
Database?
Posix threads?

These are more appropriate for a specific platform, be it MS windows or the
Java virtual machine.

C++ doesn't make any assumptions.
The Commitee should consider this and do some tiding with
the external libraries, making them more accessible for users.


Hmm... I've always wondered how C++ support 64-bit processors?

Depends on the implementation.
The standard and Stroustrup says that the type 'int' has size
most convenient for integer arithmetics and it usually correspond
to machine word and sizes of processor registers / data bus.
On 64-bit machines, that is 64 bit, so does 'int' have 64-bit there?

Depends on the implementation. GCC, I think, uses 64-bit ints,
VC++ uses 32-bit ints, as do longs.

<snip>
Backwards compatibility is important - particularly when writing binary data
files.
if you've been writing ints (or longs) and they increased from 32 to
64-bits....that'd
cause some difficulties when porting.

Dennis
 
J

JohnQ

Dennis (Icarus) said:
Depends on what they're trying to do. For a multi-platform project, C#
wouldn't be a good tool, nor VB.
Heck, they could just choose to outsource the job to India. ;-)

Yeah, but remember this thread started with the concept of "Small C++". I'm
actually aguing for that hypothetical (non-existent) language in competition
with C++ (or not because it's already been rejected there) in some nebulous
domain. I know it's a fuzzy stance, where C++ isn't chosen now, maybe "Small
C++" could be in the future.
I guess trying to manage the compiler is easier than trying to manage your
team.

The manager (or project leader/architect/lead engineer, whatever) should be
able to have reasonable confidence that given his specifications, the
programmers will produce what was envisioned.
Go for it. Heck, I've said myself that when it comes to writing automation
clients with Windows, I prefer using C# to C++.
C# has nice language features/libraries that make this a bit easier (for
me)
than C++.
Now, this isn't the fault of C++, since to Unix/Linux folks support for
COM
automation may not be too appropriate.

Well the thing is, I'm not arguing for those things. I'm just being
pessimistically optimistic that some kind of C++ will survive and grow
rather than become more and more a language used solely for "to the bare
metal" programming (which is why I like it though: turn-off, to me, is
"garbage collected language"). Hey, maybe that's _my_ job: to use C++ in
unexpected places. Not that I'd actually consider developing in an
environment that requires that the source code be divulged.
Without managing the programmers, they can't control the product.

Yes, if they are C++ programmers. But if they were "Small C++" programmers,
s/he wouldn't have to be so concerned that taking eyes off of the
programmers for a few would cause the development to begin forking into
obfuscationland.

(We seem to be getting quite a bit of mileage on this topic, huh.)
We don't find it too intensive. Is every line reviewed? Nah.
Significant changes, sure, especially when those changes are going into a
service pack.

Are you actually arguing that a nuclear reactor should be used for brewing
coffee?

;) (OK, no more analogies).
C++ is a powerful langauge, no doubt about it.

You are suggesting that a long learning curve is indicative of power.

(This thread is getting pretty silly. You're obviously playing with me now.)
My point is, still, than unmaintainable code can be written in C, without
templates and other features. :)
Templates, operator overloading, function overloading, default
arguments....

OK. Well try to stay on topic then from now on, OK? :p
Ok, could you demonstrate non-template containers for any object?

Non-C++ templates?
This container class should invoke the appropriate methods on the class
for
assignment, copy construction, etc.


So they won't be as powerful?

Obviously you are asking if they will be gold plated. Overkill will be
avoided.
Lets see, template default arguments? Template member functions?

This is how I see those things: cleaning up the small particles/crumbs first
and not concentrating on the big pile of stuff.

(OK I lied about "no more analogies").
(Also, I just realized that this discussion is like interface classes: all
specification and no implementation. That must be a sign.)
And who thinks that? :)

Probably every C++ programmer before his fifth year of using the language.
And you KNOW that the staffing companies are hiring the C++ newbies to code
on multi-million dollar projects. (Well, I assume that hasn't changed
anyway: been there, done that).

John
 
J

JohnQ

SasQ said:
Dnia Fri, 16 Mar 2007 22:40:01 +0000, JohnQ napisa³(a):

What does "napisal(a)" mean?

(Did I write that? If I did, I'm wondering in what context and what I meant.
It's probably a hint that I don't forsee ever programming anything ever that
doesn't make that assumption. Does that make me "bad"? How much easier would
C++ be if it made that assumption. I really want to know that).
Because byte doesn't have to be 8-bit. Dennis actually has shown that
there are platforms where bytes are 6-bit. If there were only 8-bit
bytes in C++, it would be impossible to use C++ for that.

Well what if "Small C++" would target only 8-bits/byte hardware? C'mon now,
there could be some synergy in such a combination, surely (or at least lil
ol me doesn't know any better).
The same problem has emerged with the Inthernet protocols. Because
of that different bit-sizes of bytes on different platforms, all
Internet standards use a term of OCTET for 8-bit packets and BYTE
only for machine-specific bytes.

C++ wants to be "everywhere" (does it? If not, then stop calling it "general
purpose".), but in doing so, keeps itself out of anything high level.
"Engineering": a discipline where one learns more and more about less and
less, until eventually, one knows everything about nothing.

(I don't know "BYTE". (I was sick that day).) <- extra credit for anyone who
can place the periods properly in this. (Yes, I really would like to know).
So does C++, but it use a term of
CHARACTER - the count of bits which is possible to store any
character code on the specific platform. It's only a coincidence
that on the most used and most known platforms the 'char' type
has a size of 8 bits, because it use 8-bit bytes for storing
character codes.

What did you just say? I'm all for non-nebulousness. If even the bits and
"bytes" haven't been standardized, we're in loads-O-trouble! (And they
haven't, and I find that sad and unnecessary complexity. (Because I'm a
developer and don't mind being a scientist for things I want to investigate,
but do mind having to be a scientist of things I don't think I should have
to be for).<--should the period be inside or outside the closing
parenthesis?
It's easier to program for that specific platform :p But try to
use that kind of language to write a platform-independent code ;)

It's seems to be a question of leadership. No one is making any commitments
at the lowest levels. Hence, it's "all things to all platforms". It sucks.
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.
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.
One should know the language well if one want to code in it :p

Like I said before, there are two kinds (of managers): lightweights and
heavyweights (using the terms that PMI training uses).

Stick to the points please.
It's impossible to write a book knowing only a few words.

I've never ever understood why people ... well does the world owe you
something? Maybe you should talk to "the world" about repayment and not the
unsuspecting (employees, programmers.. whatever).

Let it be known, that I'm not dissing C++. I like it. I am using it. But
I've used it a long time and now my own usage of it has "grown wings" (OK,
only internally... in reality, it has only hatched it's shell).
Can you proove it, or you're only telling us truisms?

I don't have to prove it in the boxing ring. I can just start producing
software in "Small C++" and become free of the dogma. :p

It's true isn't it. C++ is a religion. Or an institution.

You prove me wrong.
It's much easier for a bad coder. But [like Dennis mentioned already]
for a bad coder it's possible in any language.

He was off topic at that passage in his post. Yes, a logic error.
It's also that the more
features the language has, the more possibilities to screw up has a
bad coder ;) But it's not the language's fault :p

You're wrong. If you evolve a language to badness, the coders are just
martyrs. :p

(Small C++: 1, C++ 0)

How's that grab ya?
How do you make a container possible to contain object of any
arbitrary type, without templates?

C++ templates? (Where is the D guy when you need him?!). Didn't he find a
way to make templates palatable? OK, he didn't. Implementation-wise, maybe
he did. My perception is that D is a follower language rather than a leader
one. (No offense Walter. You found mechanisms that are better than C++'s,
probably. Kudos. I'm not switching over though.) <-- I think the period is
correct here (?).
Use with thinking ;)

C++: programmer spends most of his (sure, "her"... like there are any C++
developers who are women. Hey, that's a sign!) time in the solution space
instead of the problem space. If we need science, it is those concept and
NOT the latest and greatest technique of using the infinite possibilities of
C++ templates.
Dennis said that operator overloading CAN lead to messy code,
not that it HAVE TO lead to messy code ;J Feel the difference:

Context: newbie C++ coder, just out of college. Big systems are being built
by these people and .. (hmmm, aside, so today the exploiters of programmers
are versed in C++?). Yep, I'm an oldie. I was in that environment a long
time ago. I keep tabs on it a little, but I don't know it anymore, nor do I
want to (other than the high level view that surely does not exist).

(Hey, it's Saturday and I shouldn't be online "talking tech". Deal with my
short answers).

I use printf() (temporarily). Yep, I think C++ IO is obsolete at the
outset. C'mon now, it can't even decide on what a byte is, and you want me
to accept what it considers an input/output to be. Surely you jest.
Even if you axe templates, operator overloading, and other things
that you don't understand well,

I resent your implication. I'll respond with: I have less and less patience
for assholes. So try not to be one (in the future). :p

John
 
B

Bo Persson

SasQ said:
Dnia Sat, 17 Mar 2007 19:49:35 +0100, Bo Persson napisa³(a):
I guess the committee just wanted to avoid repeating the 500
or so pages of the C standard.

I think it would be convenient to split the standard document
into some smaller parts - the core language definition in one,
the C standard library in another, the C++ [STL?] library in
another, maybe some "additional guarantees for most common
platforms" in another...

There are different chapters in the standard document. :)

Not copying the C standard was partly to avoid introducing errors in the
process. What if the C and C++ standards turned out to be conflicting,
because of an editing mistake?


I believe that the committee wanted to avoid the blessing of particular
subsets of the language. Therefore they were intentionally vague in some
parts of the document, so that C++ could be implemented on hardware that are
not "the most common platform".

If you want to target 32-bit, two's complement, IEEE floating point
platforms with 8-bit bytes, you can easily do that without the help of the
committee. Just mark the box "Not suitable for 36-bit mainframes".


Also, the "most common platform" might just not be a PC, but an embedded
processor. Some of those have 16-bit or 32-bit bytes. :)

It might be good also to create a place where language users
could post external libraries proposals, and other users
could compare it and choose the ones fullfilling their needs.
Languages [or platforms ;J] like Java or .NET has the little
advantage that all libraries are gathered in one place and
well defined/documented for their users.

The also have the "advantage" of a single company promoting their own
standard. This leads to interesting portability problems for platforms that
are not directly supported. Very expensive ones, sometimes.

For example, I work with IBM mainframes - a relatively low volume, but very
important platform. To run Java on this system, you need special add-on
hardware to implement the standard requirements. Dotnet doesn't run at all.
And there are
"standard" libraries for GUI, databases, communication,
threading, networking etc. There are many libraries for C++
doing the same, but it's not that easy to find it and compare.
Here C++ looses with its competitors ;J
The Commitee should consider this and do some tiding with
the external libraries, making them more accessible for users.

Some of the committee members are also active in boost.org, doing just that.

Hmm... I've always wondered how C++ support 64-bit processors?
The standard and Stroustrup says that the type 'int' has size
most convenient for integer arithmetics and it usually correspond
to machine word and sizes of processor registers / data bus.
On 64-bit machines, that is 64 bit, so does 'int' have 64-bit there?
Or it's still 32-bit, and 'long' is 64-bit?

The problem here is the defintion of "most convenient" or "most natural" for
a given platform.

For x64 platforms, 32-bit ints acually have shorter instructions than 64-bit
operations. That somehow makes it "natural" for the platform, in that AMD
decided to keep opcodes for 32-bit operations the same, and use extended
opcodes for 64-bit operations. That is different from when 16-bit code was
once transformed to 32-bit code.


Bo Persson
 
S

SasQ

Dnia Sun, 18 Mar 2007 00:31:43 -0500, JohnQ napisa³(a):
What does "napisal(a)" mean?

"wrote" in Polish.
Did I write that?

Yes. In the post from 2007-03-16 23:40.
How much easier would C++ be if it made that assumption.

I don't know, but I think if C++ assume that bytes are always 8-bit,
people coding for the platform where bytes are more than 8 bits
would protest or can't use C++ for those platforms.
Well what if "Small C++" would target only 8-bits/byte hardware?

Noone's stopping you ;) If you don't want to support platforms with
other-than-8-bit bytes, feel free. C++ creators have had other aims.
C++ wants to be "everywhere"

Yes. So does Internet ;) And maybe you could write your posts for
this group only because of that creators of Internet protocols
didn't made any platform-specific assumptions. Where they want
8-bit and no more no less, they require OCTET. Mail protocols
are designed to send 7-bit characters and 8-bit also, because
they don't assume how many bits the characters should have.

I heard there were suggestions to introduce new built-in data types
to C++0x for programmers who want presice bit sizes: byte, word,
dword, qword etc. but I don't know the further story of that ideas.
Some compilers offer an extensions like _int16, _int32, _int64 etc.
for the same reason, but they're non-standard, so the code would
compile only on those compilers supporting those extensions.
What did you just say? I'm all for non-nebulousness. If even
the bits and "bytes" haven't been standardized, we're in
loads-O-trouble!

* Bit is the smallest part of information, 0 or 1.
* Byte is a group of bits making a single memory "cell" - it's the
smallest addressable memory piece [some processors can address
particular bits in bytes too, but that's not that every bit has
his own address, only full bytes are addressed].
The most common platforms have 8-bit bytes, but it's still only
a special case, only a coincidence ;)
* Octet is always 8 bits, no more no less, on every platform.
* 'char' type is for storing characters [or, to be more precise:
their numeric codes]. It have to be big enough to store all
character codes from the particular machine's character set.
* C++ uses 'char' also as a smallest-size type. Because bytes
are the smallest addressable memory pieces, 'char' corresponds
to them and has a size of 1 byte [no matter how many bits
that byte has on a given platform].
* For a long time all known character sets fit into bytes. As they
become bigger than bytes, 'wchar_t' type has emerged. It can
consist from more than 1 byte.

So, not only C++, but any multiplatform language can't assume
that bytes are always 8-bit. The only assumptions possible are:

1. Bit is the smallest piece of information, 0 or 1.
2. One byte is the smallest _addressable_ memory piece consisting
of some count of bits.
3. Character codes from near evry [or maybe every] basic character
set fits into byte. The ones that doesn't fit, are treated as
wide-character sets.

Is it anymore clrear now? :)
Because I'm a developer and don't mind being a scientist for
things I want to investigate

It's good to know well the tools used. You can't say "I don't
have to be a welder to weld".
Hence, it's "all things to all platforms". It sucks.

Suck for who? :)
I appreciate that I can write code in C++ and compile it on
a platform where bytes are 9-bits ;)
No it doesn't. It's hard.

Hard for you doesn't mean hard for everyone.
I first learnt C++ from an old bad book which treat C++ as a
"better C" and used C-like low-level techniques for everything.
I thought that I knew C++ back then, and that it's hard.
Next I've got another book of some Polish autor, who explained
all C++ issues well and I've understood it better.
But recently I've read Stroustrup books and just then I've
understood many rationales behind particular C++ features,
why they're where they are, and how to use id properly.
Problem with learning C++ is that there are many books and
many teachers, but not every of them understands well the
subjects he describes. If you want to learn C++ well, read
Stroustrup books, or other people involved in C++ evolution
[like Koenig & Moo - their "Accelerated C++" is a good book too].
Don't even bother perpetuating this piece of this post because
we will just have to agree to disagree on that one.
?


Like I said before, there are two kinds (of managers):
lightweights and heavyweights (using the terms that PMI
training uses).

I don't like managers trying to stuff their hands into my code.
If they don't trust me, let they write that code by theirselves ;J
I've never ever understood why people ... well does the world
owe you something? Maybe you should talk to "the world" about
repayment and not the unsuspecting (employees, programmers.. whatever).
??

Let it be known, that I'm not dissing C++. I like it. I am
using it.

And who's telling you that you don't? :)
I don't have to prove it in the boxing ring. I can just
start producing software in "Small C++" and become free
of the dogma. :p

The dogmas are that kind of truisms like the one you've said
["It's much easier in C++ to write unmaintainable code"].
Because if you say that, it means nothing [for me] without
any evidence confirming that.
It's true isn't it. C++ is a religion.
:D

You prove me wrong.

Religion is based on faith and believes.
Our "current C++" advocacy is based on knowledge.
You're wrong. If you evolve a language to badness,
the coders are just martyrs. :p

The more features language has, it always be the ones
who don't understand it well and use it a wrong way.
Like using a preprocessor to do obfuscating macros.
Using a type casting to fiddling bits inside objects.
Using inheritance for everything only to reuse code.
If you use a lighter without care, you can burn yourself.
Stroustrup said that in C you could shoot your foot if
you did something without care. C++ protects you from
aiming on your leg, but if you really want, it won't
stop you and you can shoot out all your leg then.
It's the "Trust the programmer" rule.
C++ templates? (Where is the D guy when you need him?!).

Yes, in some cases D's template syntax is better. But it's not
better in all the cases and there are cases where C++ wins.
C++ and D has simply a different set of features. Choose the
one you need for a particular job ;)
C++: programmer spends most of his (sure, "her"... like
there are any C++ developers who are women. Hey, that's a sign!)

Sign of what? :) I knew at least five women who learned C++
with me on a university. And they understand it well ;)
time in the solution space instead of the problem space.

Strange, I spend more time in the problem space, on designing
and thinking about the program structure. Then it's easier to
sit down to the keyboard and code it in.
I use printf() (temporarily). Yep, I think C++ IO is obsolete
at the outset. C'mon now, it can't even decide on what a byte
is, and you want me to accept what it considers an input/output
to be. Surely you jest.

C'mon now, C lays on the same assumptions as C++ :p
BTW try this one with printf:

class SomeClass {
//..some stuff
};

SomeClass someObject;
printf("what '%' code should be placed here? :p", someObject);

C++ IO is object oriented. It HAVE TO be, because if you can
create new data types, you should also be able to use it with
IO the same way as built-in types. With printf you can't, because
it has '%' codes only for built-in types.
There's another reason behind using iostreams instead of printf:
iostream output operators are matched at compile time and in a
machine code there'll be only calls for the proper functions to
handle only proper data types, and nothing else. OTOH printf
have to parse format string at run-time every time it's called,
and choose the proper branch of execution for the particular type.
All that branches will be there in executable even if you print
only one type in a whole program. In a case of iostreams, there
could be only the ones used [code of the operator<<'s for the
used types only].
I resent your implication. I'll respond with: I have less and
less patience for assholes. So try not to be one (in the future). :p

No offence, I didn't mean anything bad. I've only said that you
might probably not understand that well the features of C++ you
found hard or unnecessary. It's nothing bad, I've been there too
and thought that C++ features unnecessary or strange. But if you
understand the reason why that features are where they are, and
what rationale directed C++ inventors, you start to see why that
features are good and are there for a reason.
If you haven't read Stroustrup's books yet, I encourage you
to do it. "The C++ Programming Language" is good for learning
C++ to understand it well and use it the proper way. "The C++
Design and Evolution" will show you the rationale behind every
language feature, how it evolved with time, what were the other
options and why the current ones had been choosed. And maybe it
will help you with making decissions and designing your
"Small C++" too ;) I wish you good luck.
 
D

Dennis \(Icarus\)

JohnQ said:
What does "napisal(a)" mean?


(Did I write that? If I did, I'm wondering in what context and what I meant.
It's probably a hint that I don't forsee ever programming anything ever that
doesn't make that assumption. Does that make me "bad"? How much easier would
C++ be if it made that assumption. I really want to know that).

Uhmm...yes....yes you did. Check your "sent items" folder (or equivalent) or
check google.

C++ wants to be "everywhere" (does it? If not, then stop calling it "general
purpose".), but in doing so, keeps itself out of anything high level.
"Engineering": a discipline where one learns more and more about less and
less, until eventually, one knows everything about nothing.

I thought we covered this, but we can do so again.
To summarize my understanding, "high-level" is, IIRC GUI, Databases, etc
However, folks use C++ to do GUI, Databases, etc, so it doesn't seem to be
kept "out of anything high level".
(I don't know "BYTE". (I was sick that day).) <- extra credit for anyone who
can place the periods properly in this. (Yes, I really would like to know).

What did you just say? I'm all for non-nebulousness. If even the bits and
"bytes" haven't been standardized, we're in loads-O-trouble! (And they
haven't, and I find that sad and unnecessary complexity. (Because I'm a
developer and don't mind being a scientist for things I want to investigate,
but do mind having to be a scientist of things I don't think I should have
to be for).<--should the period be inside or outside the closing
parenthesis?

Well, lets see, you have bit shift operations in C++ so they are, indeed,
standardized.
Byte means different things to different platforms, but the most common
platforms do use 8 bits per byte.
However, the designers of C++ thought it shuld be able to range from
embedded controllers to supercomputer clusters.
And it does so.

It's seems to be a question of leadership. No one is making any commitments
at the lowest levels. Hence, it's "all things to all platforms". It sucks.
Why?

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?
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".
I don't have to prove it in the boxing ring. I can just start producing
software in "Small C++" and become free of the dogma. :p

Well...in order to start producing software in Small C++ you'd hae to have a
compiler, and to get the compiler you'd have to have a language spec.
It's much easier for a bad coder. But [like Dennis mentioned already]
for a bad coder it's possible in any language.

He was off topic at that passage in his post. Yes, a logic error.

Off-topic? You're complaining that C++ features lead to unmaintainable code,
I point out that its possible to do this in any lanaguage, including C, and
you think this is a logic error?
You're wrong. If you evolve a language to badness, the coders are just
martyrs. :p

(Small C++: 1, C++ 0)

How's that grab ya?

Meaningless, since Small C++ doesn't exist?
C++ templates? (Where is the D guy when you need him?!). Didn't he find a
way to make templates palatable? OK, he didn't. Implementation-wise, maybe
he did. My perception is that D is a follower language rather than a leader
one. (No offense Walter. You found mechanisms that are better than C++'s,
probably. Kudos. I'm not switching over though.) <-- I think the period is
correct here (?).

Ok, lets see Small-C++'s generics?
C++: programmer spends most of his (sure, "her"... like there are any C++
developers who are women. Hey, that's a sign!) time in the solution space

I work with quite a few C++ developers who are women, and there were lots at
the university I attended.
You don't know ANY?
instead of the problem space. If we need science, it is those concept and
NOT the latest and greatest technique of using the infinite possibilities of
C++ templates.


Context: newbie C++ coder, just out of college. Big systems are being built
by these people and .. (hmmm, aside, so today the exploiters of programmers
are versed in C++?). Yep, I'm an oldie. I was in that environment a long
time ago. I keep tabs on it a little, but I don't know it anymore, nor do I
want to (other than the high level view that surely does not exist).

So you're out of touch then?

I use printf() (temporarily). Yep, I think C++ IO is obsolete at the
outset. C'mon now, it can't even decide on what a byte is, and you want me
to accept what it considers an input/output to be. Surely you jest.

I'll point out that printf comes from C, and C doesn't define what a byte is
either.
For consistency, you shouldn't use printf either.

<snip>
Dennis
 

Ask a Question

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

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

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top