#C++ &-Referencing
32 messages in this thread
Re Books:
Simpler/intro/neo C++ learning suffices with Bruce Eckel's "Using C++"
(Osborne/McGraw-Hill). More complicated stuff is covered by Stanley
Lippman's "C++ Primer" (Addison-Wesley) and Dewhurst & Stark's "Programming
in C++" (Prentic Hall). For non-tutorials get a hold of Stroustrup's text
(very hard to read) as well as the C++ 2.0 Language Reference Manual (you
can get this from AT&T be calling 800-432-6600, product code is 307-146,
price I think is $25).
Thanks for clearing up the 'const' thing. I have Stroustrup's book. Maybe
he should have let K&R do his writing for him. Right now its a toss up
between Dewhurst/Stark and Lippman. If I buy anything else I'll bust
the bank. -Bob
great! Maybe now I can get
serious about C++ without having to worry about compiler bugs!
Thanks again for your time. -Bob
In the new version, he got a co-author.
I never had any trouble with the C++ Reference Manual. I guess I'm used to
textbook style.
–John
Well, Stroustrup's book was strictly meant as a hard core reference manual.
He suceeded in that. These days things are better though. Along with the
books I've mentioned there are others. Also, AddisonWesley will soon be
releasing Bjarne's "The Annotated C++ Reference Manual". ZIllion time
better than his 1.x based book.
Well, maybe with some better books (such as the ones you have mentioned)
and some more compilers, C++ will finally go into widespread use. One
question: Whenever people speak of OOPs they go on and on about how the
code is reusable. I can't figure out why C++ code is any more reusable
than a good C library. -Bob
One way C++ code is more reusable is that you can alter it without
modifying the original source files. Makes it easy to take something and
incorperate it with changes, and you don't have multiple almost-same code
to maintain.
Also, safty features so if code is being used by someone other than its
author the compiler can chack for incorrect usage.
–John
I think until there is some sort of standard class library for C++,
reusability is sort of a joke. For example, I've written my own String
class and I use it extensively in other classes I write. I am getting a
lot of personal reusability out of the code. However, if I want to send
you one of the other classes I've written, you can't use it without String
and the other supporting classes I've written. Quite probably you've
written you're own String class (and maybe even called it String), and
probably have similar classes to the other support classes I've written.
So you can't reuse my code without taking a lot of stuff you don't want, or
substabtially rewriting it for your environment.
The promise of reusability is there, and on a personal level I've seen it
work, but in a general sense it can't happen without standard classes. I
think the creation of standard class libraries ought to be an issue of
equal importance to the standardization of the language.
.gurujees khalsa
Seriously? A standard class library is only part of the problem. Also, to
do things right is hard. For instance, I was speaking with Bob Swarm of
Zortech (hey, competitors can be friends, right?) and we were discussing
the String issue itself. Turn out that String is not actually an accurate
starting point since many of us (myself included) work with the wrong
definition of what a string is in many senses. These are the kind sof
things that needs to be address in a standard library. This is not to say
I don't want to see one, or see a String class, or even perhaps "bad"
classes (since they'd allow us to see were we need to go), but that isn't
the end of it. For instance, I've got lots of people doing scientific,
numerical, controllers, etc with C++. To them, they can stay in their own
niche of reusibility since their trait is their trait. They need not never
even come need or have the desire to use something in a standard library. I
do think a C++ standard lib would be benefical. Not sure how stardization
of it should occur though. This will most certainly be discussed (again)
next week at the 1st tech meeting of ANSI C++.
Have you gotten the adjenda yet? The idea thus far (in the goals
workgroup) is to standardize the core language in a draft asap, and then
work on libraries and language extensions. That will give compiler writers
something to work with the fastest.
I think (personally) that a standard lib will be much different from C's.
Use overloading and classes in designing such a lib. I almost wrote a book
on that– a C++ library that did all the same stuff as the C lib only in
C++ ways. But I did not think I had enough expertese in the area (since I
rarely use the standard lib myself) and Mitch's offer was way to low
anyway.
Also, take a look at the Gnu C++ library. I've got a copy around
somewhere, but I don't know what version it is for. Probably pre 2.0.
–John
Yes, in fact I think I got 2 potential agendas and 1 final agenda list.
Notwithstanding that I'm almost positive something will happen next week in
a postive fashion in terms of coring the DRM or DARM.
What's in the GNU C++ libraries? I've been reluctant to even think of
looking at it to date out of priniciples….
last week I got the official adgenda for the meeting. Also included was
the report from the goals work group. I'm sure all the members have gotten
it by now.
Have not looked at the GNU code really. Just used it as a compiler
breaker. What have your principles got against GNU libs? I hear there is
some interesting stuff there, like the string class that includes regexp
abilities.
–John
My principles got against the GNU libs that I am not in tune with the GNU
philosphies and would rather have nothing to do with it. (I can give you a
much more lengthy answer next week if you remind me about it while Tiemann
isn't looking ;-))
Good question. It's one that blows a lot of people's minds for a long
time and also a statement that seems so nonchalant radiating from those
saying it that you're convinced it's just hype.
At the lowest level, a library is a library, and that's the
end of that. The gist of the difference is that in OOP/C++/etc a
few additional things occur. First data and functions (or the operations
that can be performed on and returned from the data) can be encapsulated
and therefore modularized instead of what I call "random functions and
random data working together by accident". In other words, a method
to the madness can be presented and furthermore in can occur in a more
natural way. Once this is done, certain side-effects can happen that
make it better feasible than a mere function sitting naked in a library.
The thing is that in general a function library, although very nice,
is a collection of routines each promising to do say one thing good
(which is good of course). However, what do you do if you want that
routines to do something almost like the way you did it the last but,
but with this deletion or that addition? Your only choice is to rewrite
is from scratch. But then that means you've got to give it a name,
perhaps a "funny" one since it might do the same thing as the original one,
with with a slight twist. With the modular approach mentioned above, that
need not be the case and it can be representitive of a building/deletion
block. You just can't do this with a library. Also, let's say we've
got a sort routine. What you want to do is to be able to say in your
code: sort(something). You don't want to be concerned necessarily about the
types of the things you want sorted. In C, something like qsort() might
solve this in part, but what it you've got maybe structures with 'char *'
pointers or something as its elements that you want sorted? Where do
you go from there?
(Continues)
(Continued)
Also, depending upon various characteristics of
the data (length, type, etc), you may not necessarily want to run the
same sort algorithm even if on the same 'something'. There also might
be other concerns like are we sorting something on disk, or something in
core, etc. There is also the question of dealing with different 'something's.
Similarly, extending the functionality (or the operations mentioned earlier),
say something as simple as ascending or descending sorts needn't always
interefere. And more… With the function library approach things
are much flatter and specific. With proper modularization, things are at
levels, if you will, and can be build up slowly and surely. Also things
are more general. What all this leads to also is that your so called
main-line code needn't be concerned about this. In essense: change something
is the modularized package and don't toy with the flow/logic in the mainline
much if ever. Wouldn't it be nice to be able to create a brand new type
with it's own specialties and literally not have to change absolutely
one single line of code in your application (not excluding the desciption
of that type) to make it useable? Say adding a triangle to a list of
shapes that can be rotated, scaled, drawn, moved, etc. Well, it is possible
believe it or not. You just can't inherit, extend, subtract features with
plain old functions. This is the kind of reuse that's being discussed.
No different than say, oh, I dunno, say an electric circular hand saw.
If you've got different materials to be cut, then you don't go out and
buy a whole new saw, you use the same base saw, but you change the
blade to match it to your needs. Or say in the case of some drills,
not only can you change the bits, but you can also get variable speeds,
reversible direction drills, and even rechargeable drills. Therefore,
you don't necessarily need an explicit fast drill, slow drill, counter-
clockwise, drill, cordless drill, metal drillling bit, wood drilling bit, etc.
Also, at some level all you know is that you want to drill, so you wantta
reach into the air, have a drill placed in it without your needing to look for
the right one, and get a hole into the medium. The hole is your goal,
not all the extraneous other stuff.
Reminds me of a joke: Hear about the insane object oriented programmer?
He had madness in his methods.
I like the bumber sticker: C++ Programmers do it with class.
A while back I was working on my editor, in C. It is possible to be object
oriented in any language, since it is just a state of mind. I thought it
would be neet to be able to view the scrap buffer. It was easy to put
together. And vola! I saw a window into the scrap. When I cut a
different block, the contents of the window changed. I never put in code
to do that; rather, the objects pretty much new what they were doing
already. It drove home the adage: Take care of the dog and the bark will
take care of itself. See, I was freed from the myrid details about how such
objects can interact. That is all taken care of by the objects themselves.
–John
>It is possible to be OO in any language, since it is just a state of mind
I think the statement is: it is possible to be somewhat OO in any language.
As to 'just' a state of mind, yes that's a big part, but I'm not sure I'd
say just. I beleive I mentioned natural at least once in my message. To
me, that's the key of it all and the naturalness is what makes is
legitimitely OO IMO. Also, so long as one is finding that they're fighting
with the language, they're not doing OO. Now, maybe they're trying to, and
maybe they are in part, but the language doesn't want to have anything to
do with it. As an analogy: I can use a dime as a screwdriver, and that
dime can help me unscrew quite a variety of screws, but the dime is a coin,
and the screwdriver is a screwdriver.
True, having the language directly support the concepts is a _huge_
benifit. But once you start OOPing, it affects everything you do. That is
why you should know a viriety of languages– it helps you think better in
_any_ language.
Ever notice how many C++ programmers _don't_ program use OOP? The language
is only part of the issue. There will always be those who write FORTRAN in
every language as well as those who write polygot in any language.
–John
True, true, and true. The question being asked was why code resuse was
semngly being talked about in a different way. The thing is with "normal"
programming reuse exists. The next level up is using the OOP technique on
any given language. This increases code reuse but with constraints. And
then the next is using OOP techniques with an OOP language. That gives
maximal code reusabllity.
Yes, the fact that many C++ programmer don't use OOP or that a given
application or even part of an application doesn't need it illustrates the
point well. It ain't always needed. In the cases, where it is needed
though, I would though, regardless of having the right mindset or not. I
see it as not necessarily only getting the job done but doing is within
reason as well as using the best tools acessible if they are right for the
job. I'd say, even though a big help, doing OOP is say C, would be for the
most part a big fudge and would fall apart in some places and/or get
unnecessarily tedious.
yes, working in C does get tedious. I can't wait to get this finished and
jump into my C++ book. Moving back and forth bothers me a little too,
since they are so similar.
I found that translating some of my C stuff to C++ was trivial. I had
something like:
lned_addkey (struct lned_data *d, char c);
lned_delkey (struct lned_data *d);
lned_move (struct lned_data *d, int newpos);
etc. Converting this stuff to C++ was just a matter of hammering on the
delete key. I think one reason I liked C++ so well at first blush was that
I had been programming in it all along! State-Machine modules turned into
classes with trivial work. ADT code was rarer in C.
–John
The real point, IMHO, is that the most important part of almost any good
software design is proper decomposition. If a class library has not been
properly decomposed it can be almost worthless because of the myriad
interdependencies between the various methods. Find the right one to
override and what instance variables (not to mention EGADS globals) can be
torture.
Some are looking to OOPS as a panacea, but we are still learning how to
design good class libraries. My own experiences with OOPS have shown me
the benefts, particularly in long term maintenance and reusability are
valid. Existing commercial libraries, like MacAPP however, leave a lot to
be desired.
It sure is an exciting time to be programming!
Decomposition is indeed a big (and hard) part of it, and any programming
for that matter. Even with a shop with a few good class writers or decent
commercial class libraries, we will still not see a panacea though…
How true.
Greg,
Thanks for you very complete answer to a long-standing question of mine. I
wanted to digest it a bit before replying, so, sorry for my delay.
I appreciate the "neatness" of encapsulating functions with their associated
data. The other features of OOP you discussed seem to stem from the
availability of function and operator overloading, no? That is where I
see the "reusability" of OOP code (for instance, your 'sort' example). It
has always irritated me that there are separate functions in the C math
library for labs() and fabs() (and that *f*abs() expects a *double*!). Maybe
my FORTRAN roots are showing. Anyhow, I'm sure all these concepts will
become more clear as I use them. Again, I appreciate your taking the time
to write such a detailed explanation. -Bob
that is a big difference I expect in a C++ library. Just have _one_
function name!
float abs (float&);
double abs (double&);
int abs (int);
long abs (long);
void abs (unsigned); //to trigger a compiler error
etc.
–John
Hey– I like that void abs( unsigned ); bit you did!
Continuing with C++ a little, the Zortech readme file states:
> Variadic Pascal and C++ functions that return structures return them in a
> static temporary rather than on the stack…..
What? More nomenclature?!? What are "variadic" functions?? and what
does this all mean?
I do a lot of vector mathematics, so naturally, my first C++ project was a
vector class, complete with operator overloading and all. When I went
through the program with the debugger I found all these vector objects
called _TEMxx, where xx=15 to 55 or so. Are these vectors the result of
the above lines in the readme file?
-Bob
A variadic function is one like printf, where the number and types of
argument are not know till execution time of the program.. they're function
declared with ellipsis notations 'type func(type arg1 etc, …);'
Yes…again I let the jargon get the best of me. I figured that out just
a little after posting the my message. Thanks. -Bob
The _TEMxx is the hidden parameter for the answer area. The caller tells
the function where to put the result.
Variadic functions will have a static buffer in them and the function
returns a pointer to that buffer, which contains the result. The caller
than immediatly copies it back out again.
Variadic comes from APL where "mododaic" and "diadaic" are used instead of
unary and binary. Variadic is what we commonly call n-ary. But it is used
to signal that the function has an unknown and variable number of params.
If he just said n-ary you would think "any old function that has
parameters"
Read my articel "improving generated C++ code" in the Programmer's Journal
a few months back. It is the "OOP" issue, I don't remember the month. It
includes assembly code samples.
–John
John,
> The _TEMxx is the hidden parameter for the answer area. The caller
> tells the function where to put the result.
Is this "answer area" required when *not* using variadic functions? I have a
vector class which looks (more or less) like this:
class vector {
int x, y, z ;
public:
vector( int xx=0, int yy=0, int zz=0 ) ; // constructor
vector operator+( vector& v ) ; // addition
} ;
vector vector::operator+( vector &va )
{
return vector( x+va.x, y+va.y, z+va.z ) ;
}
Here operator+() returns a vector (structure). It seems that Zortech is
first stuffing the return value (vector) into one of these _TMP variables
and returning a pointer. My understanding is that this should not require an
answer area since it is not a variadic function, and that the return value
should be returned on the stack. Am I wrong? I can't write serious vector
math equations when the compiler keeps chewing up the data area with _TMPs.
BTW, I have called Zortech about this to ask, but everyone is out
promoting the product.
Sounds like your article is just what I need. I'll try to find it.
Thanks, Bob.
The hidden parameter is used for normal functions. The static area (no
hidden parameter) is used for variadic functions.
No temps? You've got to put intermediate results _somewhere_. Consider
c=a+b+c; the result from a+b has to be stored somewhere (won't fit in a
register!) and that object then used as a paramter when adding in c. And
yes, the temp is on the stack. And a pointer to that temp is passed in to
the function so it know where to put it. Tale a look at the disassembled
code.
–John
Yes, function overloading can be very powerful. Ditto for operator
overloading but only within reason (it can be easily abused and lead to
cryptic programs). And yes, your abs example deals with some aspects of all
this. That is why I'm a C++ enthusiant now, having been a die-hard C
programmer for the longest time. C++ not only lets you have your cake and
eat it too, but you also get to choose the piece you want and the type of
cake. Not many other languages come close to this. And certainly when one
sees this, the limits of something as good as C shines clear and loud.
<<have your cake and eat it too>> I keep wanting to review version control
systems so I can use that line in an article.
–John