(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  8927 
Dnia Fri, 16 Mar 2007 22:40:01 +0000, JohnQ napisał(a):
>Shortly after I graduated I was working in a data procesing
center. We got a tape from a company that used 6-bit characters,
instead of the 8-bit EBCDIC our system used. We had a conversion
chart, but I had to write program in COBOL to do the conversion.
Ugly code. Wouldve been much cleaner in C++.
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.
>And unmaintainable code can be written is just about any language.
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?
>What about operator overloading? That can lead to messy
code as well.
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:
>It can also lead to very elegant code too - e.g. the IOStream
operations or if one is defining math library.
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.
--
SasQ
SasQ wrote:
Dnia Fri, 16 Mar 2007 22:40:01 +0000, JohnQ napisał(a):
>>Shortly after I graduated I was working in a data procesing
center. We got a tape from a company that used 6-bit characters,
instead of the 8-bit EBCDIC our system used. We had a conversion
chart, but I had to write program in COBOL to do the conversion.
Ugly code. Wouldve been much cleaner in C++.
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.
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.
>C++ is hard to learn.
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<intfoo(6); // correct, modern, wordy, tedious
On 17 Mar, 09:58, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
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
Dnia Sat, 17 Mar 2007 02:58:14 -0700, Walter Bright 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.
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 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 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.
>>C++ is hard to learn.
It depends on who is learning it and from what book/person ;J
It's hard to learn, period.
It's not hard, period, I won, and I'm taking all your gold :P
<stamp of a leg>
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++.
>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.
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<intfoo(6); // correct, modern, wordy, tedious
You forgot "jazzy" :>
BTW...
typedef std::vector<intIntVec;
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<intfoo(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".
--
SasQ
* 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.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
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...
--
SasQ
"Ian Collins" <ia******@hotmail.comwrote in message
news:56*************@mid.individual.net...
JohnQ wrote:
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:da**************************@KNOLOGY.NET...
But STL requires templates and that could lead to unmaintainable code if
the
manager can't keep the programmers on a leash.
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.
>
Far too extreme. Code reviews are a good, useful technique - can even
find
>problems before they get into the code base.
And you can get tools that can analyze a cde base for compliance to code
standards.
Use pair programming and collective code ownership and none of this crap
is necessary.
Yeah, pretty much.
<snip>
>That's a personnel/management issue though.
It is with C++ because there is no way to harness it.
What?
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
"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:N5******************************@comcast.com. ..
SasQ wrote:
Dnia Fri, 16 Mar 2007 22:40:01 +0000, JohnQ napisał(a):
>Shortly after I graduated I was working in a data procesing
center. We got a tape from a company that used 6-bit characters,
instead of the 8-bit EBCDIC our system used. We had a conversion
chart, but I had to write program in COBOL to do the conversion.
Ugly code. Wouldve been much cleaner in C++.
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.
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.
<snip>
>
C++ is hard to learn.
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?
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<intfoo(6); // correct, modern, wordy, tedious
Dennis
"JohnQ" <jo***********************@yahoo.comwrote in message
news:4E*****************@newssvr13.news.prodigy.ne t...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:da**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:51*****************@newssvr13.news.prodigy.ne t...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:23**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:%4****************@newssvr29.news.prodigy.net ...
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:a5***************************@KNOLOGY.NET...
<snip>
Just because its there doesn't mean you have to use it.
Yeah, but how do you control a wild team of C++ programmers? Also,
what
if
Same way you do a wild team of Java, Eiffel, Lisp, Fortran or COBOL
programmers.
the IT managers are up to running a project with a milder
subset/higher
level toolchain but don't have the years of C++ project management
skill
to
embark on such a project? Well then they either job it out/get
consultants,
don't do it, or use something else. That's how C++ gets pushed out
of
the
picture.
Is C++ project management really that different from managing a Java
project?
Not for a seasoned software development project manager. But for an IT
department manager who manages everything, either one of those may be
tough.
So its the IT manager experience/competence level that's more important?
Thats kind of what I was thinking.
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. ;-)
<snip>
It also shows Win32 as having a shrinking user base. :-)
Scripting and HTML had the greatest increase.
From the article, the reason was the reduction in application
complexity,
such as automatic garbage collection.
There are garbage collecting systems for C++, IIRC, and looks like it'll
be
in the version 2.0 of the standard.
http://www.infoworld.com/article/05/...html?s=feature
Now, memory leaks are a problem, surely. Though realistically any
resource
can fail to be managed properly, not just memory.
Manage these resources through classes, se STL collections and string
objects.....is it really that much more complex than Java?
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.
>
<snip>
Shortly after I graduated I was working in a data procesing center.
We
got
a
tape from a company that used 6-bit characters, instead of the 8-bit
EBCDIC
our system used.
We had a conversion chart, but I had to write program in COBOL to do
the
conversion. Ugly code.
Wouldve been much cleaner in C++.
I can't think of all the things that C++ doesn't take for granted, such
as
8-bit bytes, but if a language was more platform-specific, it would be
easier to program in also.
And if it were more platform-specific it would be much more difficult to
move programs to different platforms when they came out.
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.
>
Or are you not just referring to word sizes and such, but stuff like GUI
and/or databases?
No, just language-level things.
Ok.
>
I'm pretty sure an IT department would find generic collection
classes
useful, so templates would be there
And a bunch of C++ programmers exploiting all the possibilities of
templates
is a scary thought to the IT manager.
<shrugsounds like the IT manager isn't managing then.
Maybe/probably can't, but we should he have to micro-manage and assume
everyone is on their honor to follow the coding standard (which would
probably be way too intricate if all the ways templates could be used
were
excluded... well, maybe not: just list hot they CAN be used). Still,
switching them off is one method of control, though extreme.
Far too extreme. Code reviews are a good, useful technique - can even
find
problems before they get into the code base.
And you can get tools that can analyze a cde base for compliance to code
standards.
Ouch, I sure wouldn't want to be the one to examine microscopically all
that
template code the programmers wrote.
And a manager is either micromanaging becase they doesn't trust their
developers to do the right thing, or they do.
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.
>
Code reviews, even on just a few projects, can provide "spot-checks".
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.
<snip>
Yes, one should know how to use the language (any language) well,
particularly to manage projects being written in it.
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.
>
templates. Templates can be exploited such that maintainability of
code
is
reduced. Maybe do containers the C way and turn off templates.
Exceptions
And unmaintainable code can be written is just about any language.
It's much easier in C++ (to write unmaintainable code)!
I dont know of any other language that has an obfuscated code contest -
no,
wait, that's C.
C, without classes, overloading, or templates. :-)
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....
>
would be a bit harder to eliminate: how about defining "exception"
as
an
abort condition and use it only when required (constructors,
operators)
using other handling elsewhere. It would require some thought, but
it
may
be
plausible (?).
So if one could axe "just" templates and exceptions as easily as I
wrote
it,
how much easier would it be to program maintainable code?
Not very, if instead of using the template-based classes one had to
resort
to writing the collection classes themselves.
I didn't say axe the container library, just templates. Other
non-template
containers would replace the template ones. But then, without templates
being available to the programmers, they can't exploit the template
machinery.
Microsoft had a set of non-template containers, IIRC. In order to be
used
didn't they have to all deive from CObject or some such?
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.
>
And without templates being available to the programmers, it'd be
difficult
for 'em to come up with their own generic classes that fit their needs.
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?
>
It can also lead to very elegant code too - e.g. the IOStream
operations
or
if one is defining math library.
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!).
Hm.....lets see...no generics, overloading may be axed as well.....
Consider C as your base, instead of C++?
At least "C with classes". ;)
But then you're still at risk having your programmers writing obfuscated
code contest entries.
At least they won't be trained to do it and think that is good coding for
production software.
And who thinks that? :)
Dennis
SasQ wrote:
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
Dnia Sat, 17 Mar 2007 15:22:00 +0100, Bo Persson napisał(a):
>I dont' see any bits there...
The minimum size comes (indirectly) from 18.2.2 saying that
the <climitsheader 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
--
SasQ
SasQ wrote:
Dnia Sat, 17 Mar 2007 15:22:00 +0100, Bo Persson napisał(a):
>>I dont' see any bits there...
The minimum size comes (indirectly) from 18.2.2 saying that
the <climitsheader 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.
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/mainf...ifications.htm
36-bit words, and everything. :-)
Bo Persson
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?
--
SasQ
"SasQ" <sa***@go2.plwrote in message
news:pa****************************@go2.pl...
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.
36-bit words, and everything. :-)
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
"Ian Collins" <ia******@hotmail.comwrote in message
news:56*************@mid.individual.net...
JohnQ wrote:
>"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:da**************************@KNOLOGY.NET.. .
But STL requires templates and that could lead to unmaintainable code if
the
manager can't keep the programmers on a leash.
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.
>>
>>>
Far too extreme. Code reviews are a good, useful technique - can even
find
problems before they get into the code base.
And you can get tools that can analyze a cde base for compliance to code
standards.
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).
>>
Ouch, I sure wouldn't want to be the one to examine microscopically all
that
template code the programmers wrote.
>>>And a manager is either micromanaging becase they doesn't trust their
developers to do the right thing, or they do.
The manager needs to be able to control the product. It shouldn't be at
the
whim of any/all of the programmers.
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.
>>
>>>Code reviews, even on just a few projects, can provide "spot-checks".
Again, too labor intensive.
>>>That's a personnel/management issue though.
It is with C++ because there is no way to harness it.
What?
Nevermind the answer to your "what?".
John
"SasQ" <sa***@go2.plwrote in message
news:pa****************************@go2.pl...
Dnia Fri, 16 Mar 2007 22:40:01 +0000, JohnQ napisał(a):
What does "napisal(a)" mean?
>
>>Shortly after I graduated I was working in a data procesing
center. We got a tape from a company that used 6-bit characters,
instead of the 8-bit EBCDIC our system used. We had a conversion
chart, but I had to write program in COBOL to do the conversion.
Ugly code. Wouldve been much cleaner in C++.
I can't think of all the things that C++ doesn't take for granted,
such as 8-bit bytes
(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?
>
>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 ;)
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.
>
>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.
>
>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
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).
>
>>And unmaintainable code can be written is just about any language.
It's much easier in C++ (to write unmaintainable code)!
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?
>
>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?
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 (?).
>
>>What about operator overloading? That can lead to messy
code as well.
Indeed! Use with caution (mostly, don't use).
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).
>
>>It can also lead to very elegant code too - e.g. the IOStream
operations or if one is defining math library.
See? :>
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.
>
>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,
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
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:2c**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:4E*****************@newssvr13.news.prodigy.ne t...
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:da**************************@KNOLOGY.NET.. .
"JohnQ" <jo***********************@yahoo.comwrote in message
news:51*****************@newssvr13.news.prodigy.ne t...
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:23**************************@KNOLOGY.NET.. .
"JohnQ" <jo***********************@yahoo.comwrote in message
news:%4****************@newssvr29.news.prodigy.net ...
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:a5***************************@KNOLOGY.NET. ..
<snip>
Just because its there doesn't mean you have to use it.
Yeah, but how do you control a wild team of C++ programmers? Also,
what
if
Same way you do a wild team of Java, Eiffel, Lisp, Fortran or COBOL
programmers.
the IT managers are up to running a project with a milder
subset/higher
level toolchain but don't have the years of C++ project management
skill
to
embark on such a project? Well then they either job it out/get
consultants,
don't do it, or use something else. That's how C++ gets pushed out
of
the
picture.
Is C++ project management really that different from managing a Java
project?
Not for a seasoned software development project manager. But for an IT
department manager who manages everything, either one of those may be
tough.
So its the IT manager experience/competence level that's more
important?
Thats kind of what I was thinking.
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. ;-)
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.
>
<snip>
>
It also shows Win32 as having a shrinking user base. :-)
Scripting and HTML had the greatest increase.
From the article, the reason was the reduction in application
complexity,
such as automatic garbage collection.
There are garbage collecting systems for C++, IIRC, and looks like
it'll
be
in the version 2.0 of the standard.
http://www.infoworld.com/article/05/...html?s=feature
Now, memory leaks are a problem, surely. Though realistically any
resource
can fail to be managed properly, not just memory.
Manage these resources through classes, se STL collections and string
objects.....is it really that much more complex than Java?
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.
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.
>
>>
>
<snip>
Shortly after I graduated I was working in a data procesing center.
We
got
a
tape from a company that used 6-bit characters, instead of the 8-bit
EBCDIC
our system used.
We had a conversion chart, but I had to write program in COBOL to
do
the
conversion. Ugly code.
Wouldve been much cleaner in C++.
I can't think of all the things that C++ doesn't take for granted,
such
as
8-bit bytes, but if a language was more platform-specific, it would be
easier to program in also.
And if it were more platform-specific it would be much more difficult
to
move programs to different platforms when they came out.
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.
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.
>
>>
I'm pretty sure an IT department would find generic collection
classes
useful, so templates would be there
And a bunch of C++ programmers exploiting all the possibilities of
templates
is a scary thought to the IT manager.
<shrugsounds like the IT manager isn't managing then.
Maybe/probably can't, but we should he have to micro-manage and assume
everyone is on their honor to follow the coding standard (which would
probably be way too intricate if all the ways templates could be used
were
excluded... well, maybe not: just list hot they CAN be used). Still,
switching them off is one method of control, though extreme.
Far too extreme. Code reviews are a good, useful technique - can even
find
problems before they get into the code base.
And you can get tools that can analyze a cde base for compliance to
code
standards.
Ouch, I sure wouldn't want to be the one to examine microscopically all
that
>template code the programmers wrote.
And a manager is either micromanaging becase they doesn't trust their
developers to do the right thing, or they do.
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.
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.)
>
>>
Code reviews, even on just a few projects, can provide "spot-checks".
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.
Are you actually arguing that a nuclear reactor should be used for brewing
coffee?
;) (OK, no more analogies).
>
<snip>
>
Yes, one should know how to use the language (any language) well,
particularly to manage projects being written in it.
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.
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.)
>
>>
>templates. Templates can be exploited such that maintainability of
code
is
reduced. Maybe do containers the C way and turn off templates.
Exceptions
And unmaintainable code can be written is just about any language.
It's much easier in C++ (to write unmaintainable code)!
I dont know of any other language that has an obfuscated code contest -
no,
wait, that's C.
C, without classes, overloading, or templates. :-)
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....
OK. Well try to stay on topic then from now on, OK? :P
>
>>
>would be a bit harder to eliminate: how about defining "exception"
as
an
abort condition and use it only when required (constructors,
operators)
using other handling elsewhere. It would require some thought, but
it
may
be
plausible (?).
So if one could axe "just" templates and exceptions as easily as I
wrote
it,
how much easier would it be to program maintainable code?
Not very, if instead of using the template-based classes one had to
resort
to writing the collection classes themselves.
I didn't say axe the container library, just templates. Other
non-template
containers would replace the template ones. But then, without
templates
being available to the programmers, they can't exploit the template
machinery.
Microsoft had a set of non-template containers, IIRC. In order to be
used
didn't they have to all deive from CObject or some such?
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?
Non-C++ templates?
This container class should invoke the appropriate methods on the class
for
assignment, copy construction, etc.
>>
And without templates being available to the programmers, it'd be
difficult
for 'em to come up with their own generic classes that fit their needs.
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?
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.)
>
>>
It can also lead to very elegant code too - e.g. the IOStream
operations
or
if one is defining math library.
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!).
Hm.....lets see...no generics, overloading may be axed as well.....
Consider C as your base, instead of C++?
At least "C with classes". ;)
But then you're still at risk having your programmers writing
obfuscated
code contest entries.
At least they won't be trained to do it and think that is good coding for
production software.
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
SasQ wrote:
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.
>
>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?
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
Dnia Sun, 18 Mar 2007 00:31:43 -0500, JohnQ napisał(a):
>Dnia Fri, 16 Mar 2007 22:40:01 +0000, JohnQ napisał(a):
What does "napisal(a)" mean?
"wrote" in Polish.
>>I can't think of all the things that C++ doesn't take for granted,
such as 8-bit bytes
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.
>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?
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 ;)
>It depends on who is learning it and from what book/person ;J
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.
?
>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).
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
>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.
And who's telling you that you don't? :)
>>>And unmaintainable code can be written is just about any language.
It's much easier in C++ (to write unmaintainable code)!
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
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.
>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
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.
>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?!).
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.
>>>It can also lead to very elegant code too - e.g. the IOStream
operations or if one is defining math library.
See? :>
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].
>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
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.
--
SasQ
"JohnQ" <jo***********************@yahoo.comwrote in message
news:K8*****************@newssvr19.news.prodigy.ne t...
>
"SasQ" <sa***@go2.plwrote in message
news:pa****************************@go2.pl...
Dnia Fri, 16 Mar 2007 22:40:01 +0000, JohnQ napisał(a):
What does "napisal(a)" mean?
>Shortly after I graduated I was working in a data procesing
center. We got a tape from a company that used 6-bit characters,
instead of the 8-bit EBCDIC our system used. We had a conversion
chart, but I had to write program in COBOL to do the conversion.
Ugly code. Wouldve been much cleaner in C++.
I can't think of all the things that C++ doesn't take for granted,
such as 8-bit bytes
(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.
<snip>
>
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 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).
>
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?
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.
>
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 ;)
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?
>
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".
>
>And unmaintainable code can be written is just about any language.
It's much easier in C++ (to write unmaintainable code)!
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
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?
>
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?
Meaningless, since Small C++ doesn't exist?
>
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?
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?
>
>What about operator overloading? That can lead to messy
code as well.
Indeed! Use with caution (mostly, don't use).
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
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.
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).
So you're out of touch then?
<snip>
>
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
"JohnQ" <jo***********************@yahoo.comwrote in message
news:K8*****************@newssvr19.news.prodigy.ne t...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:2c**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:4E*****************@newssvr13.news.prodigy.ne t...
>
<snip>
>
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. ;-)
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.
Werll, right now in an exclusive competition, C++ would be used since
Small-C++ doesn't exist.
No...wait...it does for the most part. Just avoid using features that aren't
needed for that project.
<snip>
>
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.
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.
Indeed. And that is the desired result regardless of language used, yes?
>
>
<snip>
Shortly after I graduated I was working in a data procesing
center.
We
got
a
tape from a company that used 6-bit characters, instead of the
8-bit
EBCDIC
our system used.
We had a conversion chart, but I had to write program in COBOL to
do
the
conversion. Ugly code.
Wouldve been much cleaner in C++.
I can't think of all the things that C++ doesn't take for granted,
such
as
8-bit bytes, but if a language was more platform-specific, it would
be
easier to program in also.
And if it were more platform-specific it would be much more difficult
to
move programs to different platforms when they came out.
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.
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.
Ahh...well...according to the survey I posted, one of the reasons for the
rise of Java and C# was the "reduction in application development
complexity" due to these being "managed environments' - primarily automatic
garbage collection.
And since one of your goals was reduction of complexity......?
C++ will survive, and evolve as needed.
<snip>
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.
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.)
Yeah, we do. I'll point out, again, that
a) C++ comes from C
b) C is the language that has an obfuscated code contest
c) Small-C++ derives from C++, which leaves it open to obfuscation as well.
>
>
Code reviews, even on just a few projects, can provide "spot-checks".
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.
Are you actually arguing that a nuclear reactor should be used for brewing
coffee?
;) (OK, no more analogies).
How does reviewing changes going into a released product equate to nuclear
reactors and brewing coffee?
>
<snip>
Yes, one should know how to use the language (any language) well,
particularly to manage projects being written in it.
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.
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.)
I'm suggesting that C++ is a powerful language. Are you suggesting it isn't?
:-)
>
>
templates. Templates can be exploited such that maintainability
of
code
is
reduced. Maybe do containers the C way and turn off templates.
Exceptions
And unmaintainable code can be written is just about any language.
It's much easier in C++ (to write unmaintainable code)!
I dont know of any other language that has an obfuscated code
contest -
no,
wait, that's C.
C, without classes, overloading, or templates. :-)
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....
OK. Well try to stay on topic then from now on, OK? :P
Ok, what topic would that be?
C++ vs small-C++? well...in order to discuss this in a bit more detail we'd
have to see something more concrete on what exactly small-C++ is.
Complexity in software development?
Complexity in implementing languages?
The role and responsibilities of a software development manager?
Management of software development projects?
>
>
<snip>
>
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?
Non-C++ templates?
So you just want a different syntax for templates?
>
This container class should invoke the appropriate methods on the class
for
assignment, copy construction, etc.
>
And without templates being available to the programmers, it'd be
difficult
for 'em to come up with their own generic classes that fit their
needs.
>
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?
Obviously you are asking if they will be gold plated. Overkill will be
avoided.
Such as?
>
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.)
Actually, I've yet to see a specification. :-)
>
>
It can also lead to very elegant code too - e.g. the IOStream
operations
or
if one is defining math library.
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!).
Hm.....lets see...no generics, overloading may be axed as well.....
Consider C as your base, instead of C++?
At least "C with classes". ;)
But then you're still at risk having your programmers writing
obfuscated
code contest entries.
At least they won't be trained to do it and think that is good coding
for
production software.
And who thinks that? :)
Probably every C++ programmer before his fifth year of using the language.
<shrugI didn't. If they think that,then they've really not been paying
attention in their classes.
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).
Yes, as well as experienced folks.
Dennis
Dnia Sun, 18 Mar 2007 13:29:30 +0100, Bo Persson napisał(a):
>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. :-)
Yes. But even then some subjects are broken on several chapters.
Like those built-in types definitions: what they are and what to
use them for, is in one chapter, but the size restrictions are
on another chapter, so someone [like me ;J] might overlook that.
Oh, I forgot to mention that it will be good also if the standard
would be accessible online to everyone interested. Now it's
accessible for a fee as a PDF or printed copy. Look on the WWW
Consortium: they release every technical document online in
HTML format for free.
If a language should be accessible for most users, its documentation
and definition also should be accessible for everyone interested.
>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.
Yeah I know, and that's a real flaw of those environments.
I've mentioned it only for the reason of the accessibility
and maintenance of their libraries.
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.
Huh, and people say that Java runs on everything... :PPP
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.
So there 'int' might be that "most convenient" 32 bits,
and there is still a 'long' type for those who want more ;)
So why 'long long int'?
I only wonder how the current standard deals with new 64-bit
platforms and if something is about to change in new C++0x
standard, or maybe precised. Because we've come to situation
that different compiler vendors use different "self-made
standards" for new 64-bit platforms and it's getting more
cloudy for programmers that it was when there was only 32-bit.
--
SasQ
JohnQ wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
news:56*************@mid.individual.net...
>>JohnQ wrote:
>>>"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:da**************************@KNOLOGY.NET.. .
But STL requires templates and that could lead to unmaintainable code if
the
manager can't keep the programmers on a leash.
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.
Wow, you are so stuck in the 90s....
>
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.
Make that the 80s.
--
Ian Collins.
Ian Collins wrote:
>
EC++ removed templates, stripping the language of one of its core
components and forcing users to reinvent everything in the C++ standard
library.
I think standard library is not the same as templates. Templates is C++
language stuff (enough useful in comparison with nothing), but stdlib is
just implementation of concrete interface.
There are many other libraries in the world, with different interfaces and
some of them has appeared befor stdlib has been made, and many of them at
least not worse than stdlib (especially if you have seen some
implementations of stdlib early from 2000 year).
It is good, when C++ has well-known data types as list, array and algorithms
to work with them in standard manner (at least code will be more portable),
but for OOP, interface is one of easy changing thing, so it is always easy
to make adapter of concrete interface, adapting implementation from stdlib
as well as from other libs.
There are no inventions in the adaptors, because the trivial algorithms and
data types from stdlib has been defined not by C++.
--
Maksim A. Polyanin http://grizlyk1.narod.ru/cpp_new
"In thi world of fairy tales rolls are liked olso"
/Gnume/
I'm a bit under the weather this week. I'll try to respond to posts later in
the week.
John
Grizlyk wrote:
Ian Collins wrote:
>>EC++ removed templates, stripping the language of one of its core
components and forcing users to reinvent everything in the C++ standard
library.
I think standard library is not the same as templates. Templates is C++
language stuff (enough useful in comparison with nothing), but stdlib is
just implementation of concrete interface.
The C++ standard library uses templates, don't forget it started life as
the Standard *Template* Library. EC++ removed templates, denying users
the C++ standard library and it did not provide an alternative. Big
mistake.
--
Ian Collins.
"JohnQ" <jo***********************@yahoo.comwrote in message
news:5q****************@newssvr23.news.prodigy.net ...
I'm a bit under the weather this week. I'll try to respond to posts later
in
the week.
Hope you get to feeling better soon.
Dennis
"Ian Collins" <ia******@hotmail.comwrote in message
news:56*************@mid.individual.net...
JohnQ wrote:
>"Ian Collins" <ia******@hotmail.comwrote in message
news:56*************@mid.individual.net...
>>>JohnQ wrote:
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:da**************************@KNOLOGY.NET. ..
But STL requires templates and that could lead to unmaintainable code if
the
manager can't keep the programmers on a leash.
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.
Wow, you are so stuck in the 90s....
>>
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.
Make that the 80s.
Foundational principles never "go out of style". OTOH, the flavor-of-the-day
programming processes are just that: fads.
John
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:34**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:K8*****************@newssvr19.news.prodigy.ne t...
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:2c**************************@KNOLOGY.NET.. .
"JohnQ" <jo***********************@yahoo.comwrote in message
news:4E*****************@newssvr13.news.prodigy.ne t...
<snip>
>>
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. ;-)
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.
Werll, right now in an exclusive competition, C++ would be used since
Small-C++ doesn't exist.
No...wait...it does for the most part. Just avoid using features that
aren't
needed for that project.
That doesn't help someone who wants to take apart the compiler and implement
features differently or add features.
>
<snip>
>>
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.
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.
Indeed. And that is the desired result regardless of language used, yes?
It's hard to get that confidence with C++. Certainly with new programmers
but probably even with a lot of the gurus.
>
>>
>
<snip>
Shortly after I graduated I was working in a data procesing
center.
We
got
a
tape from a company that used 6-bit characters, instead of the
8-bit
EBCDIC
our system used.
We had a conversion chart, but I had to write program in COBOL
to
do
the
conversion. Ugly code.
Wouldve been much cleaner in C++.
I can't think of all the things that C++ doesn't take for granted,
such
as
8-bit bytes, but if a language was more platform-specific, it would
be
>easier to program in also.
And if it were more platform-specific it would be much more
difficult
to
move programs to different platforms when they came out.
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.
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.
Ahh...well...according to the survey I posted, one of the reasons for the
rise of Java and C# was the "reduction in application development
complexity" due to these being "managed environments' - primarily
automatic
garbage collection.
And since one of your goals was reduction of complexity......?
The complexity that I started out talking about was the compiler
implementation complexity.
I furthered at some point (surely) that just moving complexity away from the
programmer while increasing greatly the compiler complexity is lame
non-solution.
>
C++ will survive, and evolve as needed.
<snip>
>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.
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.)
Yeah, we do. I'll point out, again, that
a) C++ comes from C
b) C is the language that has an obfuscated code contest
c) Small-C++ derives from C++, which leaves it open to obfuscation as
well.
Faulty reasoning.
>
>>
>
Code reviews, even on just a few projects, can provide
"spot-checks".
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.
Are you actually arguing that a nuclear reactor should be used for
brewing
coffee?
;) (OK, no more analogies).
How does reviewing changes going into a released product equate to nuclear
reactors and brewing coffee?
C++ == nuclear reactor.
>
>>
>
<snip>
Yes, one should know how to use the language (any language) well,
particularly to manage projects being written in it.
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.
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.)
I'm suggesting that C++ is a powerful language. Are you suggesting it
isn't?
:-)
Nope.
>
>>
>
templates. Templates can be exploited such that maintainability
of
>code
is
reduced. Maybe do containers the C way and turn off templates.
Exceptions
And unmaintainable code can be written is just about any
language.
It's much easier in C++ (to write unmaintainable code)!
I dont know of any other language that has an obfuscated code
contest -
no,
wait, that's C.
C, without classes, overloading, or templates. :-)
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....
OK. Well try to stay on topic then from now on, OK? :P
Ok, what topic would that be?
C++ vs small-C++? well...in order to discuss this in a bit more detail
we'd
have to see something more concrete on what exactly small-C++ is.
Complexity in software development?
Complexity in implementing languages?
The role and responsibilities of a software development manager?
Management of software development projects?
The language pretty much makes the requirements on the process controls. If
it's overkill, you'll spend more time than necessary doing busy work.
>
>>
>
<snip>
>>
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?
Non-C++ templates?
So you just want a different syntax for templates?
Apparently the D guy said he was able to reduce the implementation
complexity greatly by changing it. It may be a start.
>
>>
This container class should invoke the appropriate methods on the class
for
assignment, copy construction, etc.
And without templates being available to the programmers, it'd be
difficult
for 'em to come up with their own generic classes that fit their
needs.
>>
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?
Obviously you are asking if they will be gold plated. Overkill will be
avoided.
Such as?
I don't know. Probably partial specialization (?). Concepts... etc.
>
>>
>
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.)
Actually, I've yet to see a specification. :-)
>>
>
It can also lead to very elegant code too - e.g. the IOStream
operations
or
if one is defining math library.
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!).
Hm.....lets see...no generics, overloading may be axed as well.....
Consider C as your base, instead of C++?
At least "C with classes". ;)
But then you're still at risk having your programmers writing
obfuscated
code contest entries.
At least they won't be trained to do it and think that is good coding
for
>production software.
And who thinks that? :)
Probably every C++ programmer before his fifth year of using the
language.
<shrugI didn't. If they think that,then they've really not been paying
attention in their classes.
>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).
Yes, as well as experienced folks.
Not that experienced folks don't still use every nook and cranny in C++
though.
John
"JohnQ" <jo***********************@yahoo.comwrote in message
news:lx*****************@newssvr13.news.prodigy.ne t...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:34**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:K8*****************@newssvr19.news.prodigy.ne t...
>
<snip>
Werll, right now in an exclusive competition, C++ would be used since
Small-C++ doesn't exist.
No...wait...it does for the most part. Just avoid using features that
aren't
needed for that project.
That doesn't help someone who wants to take apart the compiler and
implement
features differently or add features.
Welcome back - glad you're feeling better.
I'm pretty sure GCC has been mentioned before in this thread.
That could foirm your starting point.
>
<snip>
>
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.
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.
Indeed. And that is the desired result regardless of language used, yes?
It's hard to get that confidence with C++. Certainly with new programmers
but probably even with a lot of the gurus.
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>
Shortly after I graduated I was working in a data procesing
center.
We
got
a
tape from a company that used 6-bit characters, instead of the
8-bit
EBCDIC
our system used.
We had a conversion chart, but I had to write program in COBOL
to
do
the
conversion. Ugly code.
Wouldve been much cleaner in C++.
I can't think of all the things that C++ doesn't take for
granted,
such
as
8-bit bytes, but if a language was more platform-specific, it
would
be
easier to program in also.
And if it were more platform-specific it would be much more
difficult
to
move programs to different platforms when they came out.
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.
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.
Ahh...well...according to the survey I posted, one of the reasons for
the
rise of Java and C# was the "reduction in application development
complexity" due to these being "managed environments' - primarily
automatic
garbage collection.
And since one of your goals was reduction of complexity......?
The complexity that I started out talking about was the compiler
implementation complexity.
I furthered at some point (surely) that just moving complexity away from
the
programmer while increasing greatly the compiler complexity is lame
non-solution.
And then starting talking about how one can writ hard-to-maintain code in
C++.
>
<snip>
>
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.)
Yeah, we do. I'll point out, again, that
a) C++ comes from C
b) C is the language that has an obfuscated code contest
c) Small-C++ derives from C++, which leaves it open to obfuscation as
well.
Faulty reasoning.
Feel free to point out why you think its faulty.
>
>
Code reviews, even on just a few projects, can provide
"spot-checks".
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.
Are you actually arguing that a nuclear reactor should be used for
brewing
coffee?
;) (OK, no more analogies).
How does reviewing changes going into a released product equate to
nuclear
reactors and brewing coffee?
C++ == nuclear reactor.
Really? Ok. then what langauge is "brewing coffee?"? I'm guessing Java?
>
>
<snip>
Yes, one should know how to use the language (any language) well,
particularly to manage projects being written in it.
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.
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.)
I'm suggesting that C++ is a powerful language. Are you suggesting it
isn't?
:-)
Nope.
Good deal.
<snip>
>
>
<snip>
>
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?
Non-C++ templates?
So you just want a different syntax for templates?
Apparently the D guy said he was able to reduce the implementation
complexity greatly by changing it. It may be a start.
Well, there ya go.
>
>
This container class should invoke the appropriate methods on the
class
for
assignment, copy construction, etc.
And without templates being available to the programmers, it'd be
difficult
for 'em to come up with their own generic classes that fit their
needs.
>
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?
Obviously you are asking if they will be gold plated. Overkill will be
avoided.
Such as?
I don't know. Probably partial specialization (?). Concepts... etc.
Well, partial specialization of templates has a nice, concrete need.
<snip>
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).
Yes, as well as experienced folks.
Not that experienced folks don't still use every nook and cranny in C++
though.
And newbies do?
Although, if you look at the code experienced folks write, using the
template linraries, they will use a good bit of what you'd consign to the
dustbin.
:-)
Dennis
"SasQ" <sa***@go2.plwrote in message
news:pa****************************@go2.pl...
Dnia Sun, 18 Mar 2007 00:31:43 -0500, JohnQ napisał(a):
>>Dnia Fri, 16 Mar 2007 22:40:01 +0000, JohnQ napisał(a):
What does "napisal(a)" mean?
"wrote" in Polish.
>>>I can't think of all the things that C++ doesn't take for granted,
such as 8-bit bytes
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.
>>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?
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!
[snip]
Is it anymore clrear now? :)
It didn't answer the question of how specifying that bytes have 8 bits can
simplify compiler implementation and to what degree. A few more simplifying
assumptions and maybe even _I_ would be able to implement a compiler.
>
>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".
But I want to gas weld only and I'm sure I'll never want or need to arc
weld. If so, then the super duper weld-O-matic is overkill for my purposes.
>
>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 ;)
Sounds like a lot of effort for fringe cases.
>
>>It depends on who is learning it and from what book/person ;J
No it doesn't. It's hard.
Hard for you doesn't mean hard for everyone.
It wasn't hard for me. But surely for most people who can't sort out the
chaff from the wheat in the language, it must be nightmarish.
>
>>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).
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
See, that's exactly the problem! I don't want a dozen cowboy coders doing
their own things all their own ways and then have to maintain that mess.
>>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
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.
>>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?!).
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 ;)
Signs that a C++ is an ultra gearhead type of which most women are not.
Though there probably would be a few more (maybe 10 instead of the 5 you saw
once) with a language more easily used at a higher level since women have
the potential to be better designers IMO, partly because they think more
abstractly (umm, I think they do... once I figure out C++, I'll tackle
figuring out the other thing ;) ).
>
>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.
And once you begin doing that implementation, you mind quickly reverts to
thinking about all the corner cases and the like. The more features a
language has and the more of them you use, the more time your mind spends in
the solution space.
>
>>>>It can also lead to very elegant code too - e.g. the IOStream
operations or if one is defining math library.
See? :>
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].
In this day of the GUI, how much do you need Std IO anyway.
>
>>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
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.
Thoroughly evaluated and trying to avoid based on that evaluation. It was a
lot easier at first to use C++ blindly, but after years of using it and
realizing what is required to get that funcitonality, it becomes easy to
reject.
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 ;)
Surely they would if I was producing such a language. I started with D&E in
the early nineties. That and Coplien's book moved me from C to C++. I've
read at least part of most C++ texts (the parts that interest me). After a
decade and a half, some major parts of the standard are getting a bit long
in the tooth, along with the rationales for some of them. C++ is overly
general probably rather than "general purpose". It takes generality to the
extreme at the expense of being immediately useful in a lot of domains and
it's evolution is slow for the same reason. It's easy to say it is "a good
language" if you already know it and have used it for a decade, but
obviously that long training path is not a good goal if it can be avoided.
Again, there's probably things that could be done with a new language that
would make it greatly more accessible than C++ which is hampered with
backward compatibility. If there were such a new designed-to-be-accessible
language, maybe it would be chosen over C++ where C++ is and isn't now being
chosen.
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).
John
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:cf**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:K8*****************@newssvr19.news.prodigy.ne t...
>>
"SasQ" <sa***@go2.plwrote in message
news:pa****************************@go2.pl...
Dnia Fri, 16 Mar 2007 22:40:01 +0000, JohnQ napisał(a):
What does "napisal(a)" mean?
>
Shortly after I graduated I was working in a data procesing
center. We got a tape from a company that used 6-bit characters,
instead of the 8-bit EBCDIC our system used. We had a conversion
chart, but I had to write program in COBOL to do the conversion.
Ugly code. Wouldve been much cleaner in C++.
I can't think of all the things that C++ doesn't take for granted,
such as 8-bit bytes
(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.
<snip>
>>
>
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 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".
Apparently, Java and C# are filling a void. So much for C++ everywhere.
>
>>
(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?
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.
And maybe a language that defines a byte as 8 bits would be less "general
purpose" but more useful and accessible to those not concerned about the
fringe cases. (And of course a boon to the would-be compiler developers who
cannot fathom doing that with C++).
>
>>
>
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 ;)
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?
For the myriad of reasons given since this thread started.
>
>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?
>
>>
>
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.).
>
>>
>
And unmaintainable code can be written is just about any language.
It's much easier in C++ (to write unmaintainable code)!
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
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.
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.
>
>>
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?
Yes, because he confused "the possibility of" with "the probability of". He
was pointing out the former while I was talking about the latter.
>
>>
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?
Meaningless, since Small C++ doesn't exist?
It does though. Just not in an evolved or complete form. EC++ could be said
to be a "Small C++" of sorts, for instance. A strict subset to start from.
Then add a few ingredients, change some (8-bit bytes anyone?) and voila!
>
>>
>
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?
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?
They're not built yet (if it will have them). But D has them in a
simpler-to-implement form than C++, so I hear anyway (probably too
"powerful" for my tastes though also).
>
>>
>
What about operator overloading? That can lead to messy
code as well.
Indeed! Use with caution (mostly, don't use).
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
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?
Nope. You must be in India?
>
>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).
So you're out of touch then?
With that abhorant environment, yes. I hypothesize that it still happens the
same way. The same ads run in the papers and on the boards.
>
<snip>
>>
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.
I don't ever forsee using it in production code. Only during
development/debug. See, now there's another thing on the chopping block
maybe: C++ IO. (It seems we're making progress: templates and IO to be the
first to go after the 8-bit byte and guaranteed width integers are
formalized :) ).
John
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:20***************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:5q****************@newssvr23.news.prodigy.net ...
>I'm a bit under the weather this week. I'll try to respond to posts later
in
>the week.
Hope you get to feeling better soon.
Thank you. I'm back, but I do feel that I've been spending too much time
having fun "inventing a new language" rather than on more immediately
important things (building software with what is currently available: C++).
So, this thread will hopefully wind down if it hasn't been beat to death
already.
John
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:ac*************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:lx*****************@newssvr13.news.prodigy.ne t...
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:34**************************@KNOLOGY.NET.. .
"JohnQ" <jo***********************@yahoo.comwrote in message
news:K8*****************@newssvr19.news.prodigy.ne t...
<snip>
Werll, right now in an exclusive competition, C++ would be used since
Small-C++ doesn't exist.
No...wait...it does for the most part. Just avoid using features that
aren't
needed for that project.
That doesn't help someone who wants to take apart the compiler and
implement
>features differently or add features.
Welcome back - glad you're feeling better.
Thanks.
I'm pretty sure GCC has been mentioned before in this thread.
That could foirm your starting point.
I think I've already said that starting with a full C++ compiler would be
too hard. That's why I brought up EC++ I believe: starting with a compiler
that does only that subset, or the cfront subset may be a good starting
point (starting point for further stripping? 8-bit bytes anyone?).
>
>>
>
<snip>
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.
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.
Indeed. And that is the desired result regardless of language used,
yes?
It's hard to get that confidence with C++. Certainly with new programmers
but probably even with a lot of the gurus.
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.
>
>>
>
<snip>
Shortly after I graduated I was working in a data procesing
center.
We
got
a
tape from a company that used 6-bit characters, instead of the
8-bit
EBCDIC
our system used.
We had a conversion chart, but I had to write program in
COBOL
to
do
the
conversion. Ugly code.
Wouldve been much cleaner in C++.
I can't think of all the things that C++ doesn't take for
granted,
>such
as
8-bit bytes, but if a language was more platform-specific, it
would
be
easier to program in also.
And if it were more platform-specific it would be much more
difficult
to
move programs to different platforms when they came out.
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.
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.
Ahh...well...according to the survey I posted, one of the reasons for
the
rise of Java and C# was the "reduction in application development
complexity" due to these being "managed environments' - primarily
automatic
garbage collection.
And since one of your goals was reduction of complexity......?
The complexity that I started out talking about was the compiler
implementation complexity.
I furthered at some point (surely) that just moving complexity away from
the
>programmer while increasing greatly the compiler complexity is lame
non-solution.
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!".
>
>>
<snip>
>>
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.)
Yeah, we do. I'll point out, again, that
a) C++ comes from C
b) C is the language that has an obfuscated code contest
c) Small-C++ derives from C++, which leaves it open to obfuscation as
well.
Faulty reasoning.
Feel free to point out why you think its faulty.
"possibility of" and "probability of" are different. Combine this with what
I just said above.
>
>>
>
Code reviews, even on just a few projects, can provide
"spot-checks".
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.
Are you actually arguing that a nuclear reactor should be used for
brewing
coffee?
;) (OK, no more analogies).
How does reviewing changes going into a released product equate to
nuclear
reactors and brewing coffee?
C++ == nuclear reactor.
Really? Ok. then what langauge is "brewing coffee?"? I'm guessing Java?
Hehe. I didn't even intend that pun. No, I wasn't suggesting Java. Nor any
other existing language. I hesitated to say Small C++ because I didn't want
it to be on the extreme end of coffee brewer (which sounds more like RAD
tool).
>
>>
>
<snip>
Yes, one should know how to use the language (any language) well,
particularly to manage projects being written in it.
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.
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.)
I'm suggesting that C++ is a powerful language. Are you suggesting it
isn't?
:-)
Nope.
Good deal.
<snip>
>>
>
<snip>
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?
Non-C++ templates?
So you just want a different syntax for templates?
Apparently the D guy said he was able to reduce the implementation
complexity greatly by changing it. It may be a start.
Well, there ya go.
I meant a starting place to look for how to implement templates. D is too
much language just like C++ is to be Small C++. It's probably even bigger:
garbage collected, nixed preprocessor (both of which I would not want in
Small C++: I want the preprocessor, I don't want garbage collection
built-in).
>
>>
>
This container class should invoke the appropriate methods on the
class
for
assignment, copy construction, etc.
And without templates being available to the programmers, it'd be
difficult
for 'em to come up with their own generic classes that fit their
needs.
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?
Obviously you are asking if they will be gold plated. Overkill will be
avoided.
Such as?
I don't know. Probably partial specialization (?). Concepts... etc.
Well, partial specialization of templates has a nice, concrete need.
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.
>
<snip>
>
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).
Yes, as well as experienced folks.
Not that experienced folks don't still use every nook and cranny in C++
though.
And newbies do?
What, program by the examples they see in books? Yes they do.
Although, if you look at the code experienced folks write, using the
template linraries, they will use a good bit of what you'd consign to the
dustbin.
Probably, but because they are so enamoured with templates that they overuse
the paradigm. Maybe template use should be restricted (by coding standard or
whatever) to containers/algorithms only.
John
"Walter Bright" <wa****@digitalmars-nospamm.comwrote in message
news:BM******************************@comcast.com. ..
I don't believe that deleting a bunch of standard features in DMC++ (or
any other C++ compiler) is going to make it a more attractive product. It
runs contrary to all my experience in this business.
There have been two major attempts at reengineering C++: Java, which tries
to improve things by removing the hard stuff, and D, which tries to
redesign the hard stuff so it isn't hard anymore.
That sounds reasonable. But you took away my preprocessor and added garbage
collection. :( I think your goals with D are to have everything including
the kitchen sink in it (C++ is a bit like that already): you'll have
concepts, partial specialization... etc. I'm not convinced all that is
necessary and if not, it complicates the general case for the fringe cases.
It's the more-is-more language. Small C++ is envisioned as the less-is-more
language. The advantage that Small C++ would have over D (in addition to
ease of use) would be that "anyone" could "trivially" implement it.
Infrastructure buildout would not have to proceed at the traditional snail's
pace since one would essentially be one's own compiler system provider
directly from the rawest material.
John
"JohnQ" <jo***********************@yahoo.comwrote in message
news:Zl************@newssvr22.news.prodigy.net...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:ac*************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:lx*****************@newssvr13.news.prodigy.ne t...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:34**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:K8*****************@newssvr19.news.prodigy.ne t...
<snip>
Werll, right now in an exclusive competition, C++ would be used since
Small-C++ doesn't exist.
No...wait...it does for the most part. Just avoid using features that
aren't
needed for that project.
That doesn't help someone who wants to take apart the compiler and
implement
features differently or add features.
Welcome back - glad you're feeling better.
Thanks.
I'm pretty sure GCC has been mentioned before in this thread.
That could foirm your starting point.
I think I've already said that starting with a full C++ compiler would be
too hard. That's why I brought up EC++ I believe: starting with a compiler
that does only that subset, or the cfront subset may be a good starting
point (starting point for further stripping? 8-bit bytes anyone?).
>
<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.
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.
<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".
>
>
<snip>
>
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.)
Yeah, we do. I'll point out, again, that
a) C++ comes from C
b) C is the language that has an obfuscated code contest
c) Small-C++ derives from C++, which leaves it open to obfuscation as
well.
Faulty reasoning.
Feel free to point out why you think its faulty.
"possibility of" and "probability of" are different. Combine this with
what
I just said above.
So with C, no possibility of programmers writing obfuscated code. Only with
C++ does obfuscation come into the picture?
<snip>
<snip>
>
Apparently the D guy said he was able to reduce the implementation
complexity greatly by changing it. It may be a start.
Well, there ya go.
I meant a starting place to look for how to implement templates. D is too
much language just like C++ is to be Small C++. It's probably even bigger:
garbage collected, nixed preprocessor (both of which I would not want in
Small C++: I want the preprocessor, I don't want garbage collection
built-in).
Well, in the survey results I posted, they emphasised the "managed"
environment in reducing application complexity.
>
>
This container class should invoke the appropriate methods on the
class
for
assignment, copy construction, etc.
And without templates being available to the programmers, it'd
be
difficult
for 'em to come up with their own generic classes that fit
their
needs.
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?
Obviously you are asking if they will be gold plated. Overkill will
be
avoided.
Such as?
I don't know. Probably partial specialization (?). Concepts... etc.
Well, partial specialization of templates has a nice, concrete need.
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.
>
<snip>
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).
Yes, as well as experienced folks.
Not that experienced folks don't still use every nook and cranny in C++
though.
And newbies do?
What, program by the examples they see in books? Yes they do.
Uhm...."(And newbies do) use every nook and cranny in C++"?
>
Although, if you look at the code experienced folks write, using the
template linraries, they will use a good bit of what you'd consign to
the
dustbin.
Probably, but because they are so enamoured with templates that they
overuse
the paradigm. Maybe template use should be restricted (by coding standard
or
whatever) to containers/algorithms only.
And therein lies a problem.
If you have a header file, which allows the definition of templates in
Small-C++, then a developer will be able to use the same syntax.
Or will these headers be "marked" in some way which lets them use templates,
but nothing else?
Dennis
"JohnQ" <jo***********************@yahoo.comwrote in message
news:DO************@newssvr22.news.prodigy.net...
>
"SasQ" <sa***@go2.plwrote in message
news:pa****************************@go2.pl...
<snip>
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].
In this day of the GUI, how much do you need Std IO anyway.
John, there are these neat things called "files".
They're a sequence of bytes sitting out on persistent storage.
InputFule >MyObject;
OutputFile << MyObject;
<snip>
>
Surely they would if I was producing such a language. I started with D&E
in
the early nineties. That and Coplien's book moved me from C to C++. I've
read at least part of most C++ texts (the parts that interest me). After a
decade and a half, some major parts of the standard are getting a bit long
in the tooth, along with the rationales for some of them. C++ is overly
general probably rather than "general purpose". It takes generality to the
extreme at the expense of being immediately useful in a lot of domains and
it's evolution is slow for the same reason. It's easy to say it is "a good
language" if you already know it and have used it for a decade, but
obviously that long training path is not a good goal if it can be avoided.
Again, there's probably things that could be done with a new language that
would make it greatly more accessible than C++ which is hampered with
backward compatibility. If there were such a new designed-to-be-accessible
language, maybe it would be chosen over C++ where C++ is and isn't now
being
chosen.
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?
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. :-)
Dennis
"JohnQ" <jo***********************@yahoo.comwrote in message
news:EO************@newssvr22.news.prodigy.net...
>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:cf**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:K8*****************@newssvr19.news.prodigy.ne t...
>
<snip>
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".
Apparently, Java and C# are filling a void. So much for C++ everywhere.
It pretty much is everywhere.
Not so Java or C#.
>
>
(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?
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.
And maybe a language that defines a byte as 8 bits would be less "general
purpose" but more useful and accessible to those not concerned about the
fringe cases. (And of course a boon to the would-be compiler developers
who
cannot fathom doing that with C++).
And such a langauge can restrict itself out of existence.
Think of how many laguages that defined pointers as 16-bit addresses would
still be in use in desktop apps since we've moved into 32-bit years ago, and
are now embracing 64-bit.
>
>
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 ;)
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?
For the myriad of reasons given since this thread started.
Ok, so why do you use it?
>
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++?
>
>
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?
:-)
So you have int as 32-bit exclusively, then it performs poorly on 16-bit
CPUs compared to ones that use the "native type".
>
>
And unmaintainable code can be written is just about any language.
It's much easier in C++ (to write unmaintainable code)!
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
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.
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.
>
>
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?
Yes, because he confused "the possibility of" with "the probability of".
He
was pointing out the former while I was talking about the latter.
Ahh...so you think a given deveoper has a lower probability of writing
obfuscated code in C, vs C++?
:-)
>
>
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?
Meaningless, since Small C++ doesn't exist?
It does though. Just not in an evolved or complete form. EC++ could be
said
to be a "Small C++" of sorts, for instance. A strict subset to start from.
Then add a few ingredients, change some (8-bit bytes anyone?) and voila!
Ok, so there ya go.
Have fun :-)
>
>
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?
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?
They're not built yet (if it will have them). But D has them in a
simpler-to-implement form than C++, so I hear anyway (probably too
"powerful" for my tastes though also).
Yeah, probably so.
>
What about operator overloading? That can lead to messy
code as well.
Indeed! Use with caution (mostly, don't use).
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
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?
Nope. You must be in India?
No, the states. You?
<snip>
<snip>
>
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.
I don't ever forsee using it in production code. Only during
development/debug. See, now there's another thing on the chopping block
maybe: C++ IO. (It seems we're making progress: templates and IO to be the
first to go after the 8-bit byte and guaranteed width integers are
formalized :) ).
Well , best get started on it.
Dennis
JohnQ wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
news:56*************@mid.individual.net...
>>JohnQ wrote:
>>>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.
Make that the 80s.
Foundational principles never "go out of style". OTOH, the flavor-of-the-day
programming processes are just that: fads.
Autocracy or teamwork, I know which I prefer.
--
Ian Collins.
"Ian Collins" <ia******@hotmail.comwrote in message
news:56*************@mid.individual.net...
JohnQ wrote:
>"Ian Collins" <ia******@hotmail.comwrote in message
news:56*************@mid.individual.net...
>>>JohnQ wrote:
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.
Make that the 80s.
Foundational principles never "go out of style". OTOH, the
flavor-of-the-day
programming processes are just that: fads.
Autocracy or teamwork, I know which I prefer.
The bizaar/design-by-committee-environment over the cathedral apparently.
John
"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...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:lx*****************@newssvr13.news.prodigy.ne t...
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:34**************************@KNOLOGY.NET.. .
"JohnQ" <jo***********************@yahoo.comwrote in message
news:K8*****************@newssvr19.news.prodigy.ne t...
<snip>
Werll, right now in an exclusive competition, C++ would be used
since
Small-C++ doesn't exist.
No...wait...it does for the most part. Just avoid using features
that
aren't
needed for that project.
That doesn't help someone who wants to take apart the compiler and
implement
features differently or add features.
Welcome back - glad you're feeling better.
Thanks.
I'm pretty sure GCC has been mentioned before in this thread.
That could foirm your starting point.
I think I've already said that starting with a full C++ compiler would be
too hard. That's why I brought up EC++ I believe: starting with a
compiler
that does only that subset, or the cfront subset may be a good starting
point (starting point for further stripping? 8-bit bytes anyone?).
>
<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.
>
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.
>
<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.
>
>>
>
<snip>
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.)
Yeah, we do. I'll point out, again, that
a) C++ comes from C
b) C is the language that has an obfuscated code contest
c) Small-C++ derives from C++, which leaves it open to obfuscation
as
well.
Faulty reasoning.
Feel free to point out why you think its faulty.
"possibility of" and "probability of" are different. Combine this with
what
>I just said above.
So with C, no possibility of programmers writing obfuscated code. Only
with
C++ does obfuscation come into the picture?
C++ has more potential for obfuscation because it has more mechanisms and
exploitation of them seems to be encouraged.
>
<snip>
<snip>
>>
Apparently the D guy said he was able to reduce the implementation
complexity greatly by changing it. It may be a start.
Well, there ya go.
I meant a starting place to look for how to implement templates. D is too
much language just like C++ is to be Small C++. It's probably even
bigger:
garbage collected, nixed preprocessor (both of which I would not want in
Small C++: I want the preprocessor, I don't want garbage collection
built-in).
Well, in the survey results I posted, they emphasised the "managed"
environment in reducing application complexity.
Implementation complexity of the compiler is where the 'complexity' word
entered this thread.
>
>>
>
This container class should invoke the appropriate methods on the
class
for
assignment, copy construction, etc.
And without templates being available to the programmers, it'd
be
difficult
for 'em to come up with their own generic classes that fit
their
needs.
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?
Obviously you are asking if they will be gold plated. Overkill will
be
>avoided.
Such as?
I don't know. Probably partial specialization (?). Concepts... etc.
Well, partial specialization of templates has a nice, concrete need.
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".
>
>>
>
<snip>
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).
Yes, as well as experienced folks.
Not that experienced folks don't still use every nook and cranny in
C++
though.
And newbies do?
What, program by the examples they see in books? Yes they do.
Uhm...."(And newbies do) use every nook and cranny in C++"?
>>
Although, if you look at the code experienced folks write, using the
template linraries, they will use a good bit of what you'd consign to
the
dustbin.
Probably, but because they are so enamoured with templates that they
overuse
>the paradigm. Maybe template use should be restricted (by coding standard
or
>whatever) to containers/algorithms only.
And therein lies a problem.
If you have a header file, which allows the definition of templates in
Small-C++, then a developer will be able to use the same syntax.
Or will these headers be "marked" in some way which lets them use
templates,
but nothing else?
TBD.
John
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:d7**************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:DO************@newssvr22.news.prodigy.net...
>>
"SasQ" <sa***@go2.plwrote in message
news:pa****************************@go2.pl...
<snip>
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].
In this day of the GUI, how much do you need Std IO anyway.
John, there are these neat things called "files".
They're a sequence of bytes sitting out on persistent storage.
InputFule >MyObject;
OutputFile << MyObject;
There's no need for C++ IO though to read/write data. Just wrap the (better)
platform APIs into a nicer "std library".
>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.
>
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
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:2b*************************@KNOLOGY.NET...
"JohnQ" <jo***********************@yahoo.comwrote in message
news:EO************@newssvr22.news.prodigy.net...
>>
"Dennis (Icarus)" <no********@ever.invalidwrote in message
news:cf**************************@KNOLOGY.NET.. .
"JohnQ" <jo***********************@yahoo.comwrote in message
news:K8*****************@newssvr19.news.prodigy.ne t...
<snip>
>
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".
Apparently, Java and C# are filling a void. So much for C++ everywhere.
It pretty much is everywhere.
Not so Java or C#.
>>
>
(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?
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.
And maybe a language that defines a byte as 8 bits would be less "general
purpose" but more useful and accessible to those not concerned about the
fringe cases. (And of course a boon to the would-be compiler developers
who
>cannot fathom doing that with C++).
And such a langauge can restrict itself out of existence.
Think of how many laguages that defined pointers as 16-bit addresses would
still be in use in desktop apps since we've moved into 32-bit years ago,
and
are now embracing 64-bit.
>>
>
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 ;)
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?
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).
>
>>
>
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!
>
>>
>
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.
>
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.
then it performs poorly on 16-bit
CPUs compared to ones that use the "native type".
>>
>
And unmaintainable code can be written is just about any language.
It's much easier in C++ (to write unmaintainable code)!
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
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.
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.
>
>>
>
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?
Yes, because he confused "the possibility of" with "the probability of".
He
>was pointing out the former while I was talking about the latter.
Ahh...so you think a given deveoper has a lower probability of writing
obfuscated code in C, vs C++?
:-)
Yes.
>
>>
>
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?
Meaningless, since Small C++ doesn't exist?
It does though. Just not in an evolved or complete form. EC++ could be
said
>to be a "Small C++" of sorts, for instance. A strict subset to start
from.
Then add a few ingredients, change some (8-bit bytes anyone?) and voila!
Ok, so there ya go.
Have fun :-)
It could happen, maybe.
>
>>
>
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?
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?
They're not built yet (if it will have them). But D has them in a
simpler-to-implement form than C++, so I hear anyway (probably too
"powerful" for my tastes though also).
Yeah, probably so.
>
What about operator overloading? That can lead to messy
code as well.
Indeed! Use with caution (mostly, don't use).
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
>
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?
Nope. You must be in India?
No, the states. You?
Same.
>
<snip>
>
<snip>
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.
I don't ever forsee using it in production code. Only during
development/debug. See, now there's another thing on the chopping block
maybe: C++ IO. (It seems we're making progress: templates and IO to be
the
first to go after the 8-bit byte and guaranteed width integers are
formalized :) ).
Well , best get started on it.
At least I'm thinking about it.
John
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?
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?
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.
Bo Persson
JohnQ wrote:
:: "Dennis (Icarus)" <no********@ever.invalidwrote in message
:::
::: 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".
When you write a compiler for a machine with 8-bit bytes, you don't have to
care that someone else might be writing for 9-bit bytes, or 32 bit bytes.
There is no added complexity for you!
On the other hand, if you specify 8-bit bytes only in your language, the
9-bit guy will be in A LOT of trouble. What do you gain from that?
Here is another example, where a supposedly "very portable" language
specifying a particular floating point format, requires VERY expensive
hardware extensions on mainframes. http://www-03.ibm.com/systems/z/zaap/
Bo Persson
"Bo Persson" <bo*@gmb.dkwrote in message
news:56*************@mid.individual.net...
JohnQ wrote:
:: "Dennis (Icarus)" <no********@ever.invalidwrote in message
:::
::: 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".
When you write a compiler for a machine with 8-bit bytes, you don't have
to care that someone else might be writing for 9-bit bytes, or 32 bit
bytes. There is no added complexity for you!
Well I don't know that as I've never written a compiler.
On the other hand, if you specify 8-bit bytes only in your language, the
9-bit guy will be in A LOT of trouble. What do you gain from that?
Ease of writing internet protocols.
Here is another example, where a supposedly "very portable" language
specifying a particular floating point format, requires VERY expensive
hardware extensions on mainframes.
http://www-03.ibm.com/systems/z/zaap/
John
"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.
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.
John
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.
--
Salu2
"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 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.
>
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.
>
<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.
<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.
<snip>
Dennis
"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.......
>
>
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.
>
>
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.
>
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.
<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.
<snip>
Ok, so there ya go.
Have fun :-)
It could happen, maybe.
Good luck.
<snip>
>
I don't ever forsee using it in production code. Only during
development/debug. See, now there's another thing on the chopping block
maybe: C++ IO. (It seems we're making progress: templates and IO to be
the
first to go after the 8-bit byte and guaranteed width integers are
formalized :) ).
Well , best get started on it.
At least I'm thinking about it.
Yep.
Dennis This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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:
...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
