By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,564 Members | 1,070 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,564 IT Pros & Developers. It's quick & easy.

views on this book

P: n/a
pretty much what the header says:

http://www.brpreiss.com/books/opus4/html/page9.html

i checked ACCU, this book is not there and i don't trust amazon
reviews. wasted to much money by trusting amazon reviews,always wrong
(except for SF books)

-- arnuld
http://arnuld.blogspot.com

Feb 7 '07 #1
Share this Question
Share on Google+
12 Replies


P: n/a
arnuld wrote:
pretty much what the header says:

http://www.brpreiss.com/books/opus4/html/page9.html

i checked ACCU, this book is not there
How did you "check"? I just searched for the author's name and
ACCU came up with this:

http://accu.org/index.php/book_revie...review=d001903

So, it _is_ there, AFAICT.

I have no opinion on that book myself.
[..]
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Feb 7 '07 #2

P: n/a
arnuld wrote:
pretty much what the header says:
http://www.brpreiss.com/books/opus4/html/page9.html
i checked ACCU, this book is not there

How did you "check"? I just searched for the author's name and
ACCU came up with this:

http://accu.org/index.php/book_revie...review=d001903

YES, that is why i removed my post. actually that is because ACCU has
some trouble. whenever i search something, it shows me the white-
page :-(

On left-side & right side, there are ACCU's colums of links and in the
center BLANK-WHITE page, after i do a search.

i just clicked on "view by subject" link and it did show the books
then
So, it _is_ there, AFAICT.

I have no opinion on that book myself.
ACCU really hates that book.

Feb 7 '07 #3

P: n/a
In article <11**********************@v45g2000cwv.googlegroups .com>,
ge*********@gmail.com says...
pretty much what the header says:

http://www.brpreiss.com/books/opus4/html/page9.html

i checked ACCU, this book is not there and i don't trust amazon
reviews. wasted to much money by trusting amazon reviews,always wrong
(except for SF books)
My immediate impression is not (even slightly) positive. My advice would
be to sort out what you really want. This attempts to teach a little
C++, something about algorithms/data structures, a little bit about
design patterns, and mostly fails at all of them. What you need is a
book (or maybe more than one) that decides what it's really going to
teach, and then does that well. But the first step is your's: decide
what kind of book you really need/want.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Feb 7 '07 #4

P: n/a
"arnuld" <ge*********@gmail.comwrote in message
news:11**********************@v45g2000cwv.googlegr oups.com...
http://www.brpreiss.com/books/opus4/html/page9.html
I looked into the text at random and it didn't take me long to find
something I consider dubious.

Look at this page:

http://www.brpreiss.com/books/opus4/...00000000000000

It talks about implementing a stack. Leave aside the semantics of class
Object, which the ACCU review criticizes, and consider only the semantics of
the Pop member.

That member returns a reference to an Object, and also removes that object
from the stack as a side effect. So the question immediately came to mind:
Where is the Object to which the reference is referring, if it's not on the
stack?

The answer is that it's still on the stack; it's just that the variable that
keeps track of the size of the stack has been decremented so that the size
no longer includes the Object to which the reference is returned.

There's nothing wrong with this behavior so far: The object will persist as
long as the stack does and as long as the stack's size doesn't grow back to
where it was before the Pop was executed. But that means that if you call
Pop, save the reference that it returns, and call Push again, the object to
which Pop returned a reference will change its value.

This strikes me as hazardous behavior, which ought to be clearly documented.
As far as I can see, it isn't. So I would take a closer look at this book
before spending money on it.
Feb 7 '07 #5

P: n/a
On Feb 7, 9:20 am, "Andrew Koenig" <a...@acm.orgwrote:
"arnuld" <geek.arn...@gmail.comwrote in message

news:11**********************@v45g2000cwv.googlegr oups.com...
http://www.brpreiss.com/books/opus4/html/page9.html

I looked into the text at random and it didn't take me long to find
something I consider dubious.

Look at this page:

http://www.brpreiss.com/books/opus4/...ECTION00711300...
<snip>
Look at this page and you will see why:

http://www.brpreiss.com/books/opus5/...00000000000000

This is from the Java version of the book. There are also versions in
C#, Python and Ruby.

Each of the versions appear to be translations of each other, rather
than written idiomatically in each language, leading to code that is
at best poor style and at worst broken in ways likely to cause
debugging nightmares.

Best Regards,

David O.

Feb 7 '07 #6

P: n/a
On Feb 7, 7:20 am, "Andrew Koenig" <a...@acm.orgwrote:
"arnuld" <geek.arn...@gmail.comwrote in message

news:11**********************@v45g2000cwv.googlegr oups.com...
http://www.brpreiss.com/books/opus4/html/page9.html

I looked into the text at random and it didn't take me long to find
something I consider dubious.

Look at this page:

http://www.brpreiss.com/books/opus4/...ECTION00711300...

It talks about implementing a stack. Leave aside the semantics of class
Object, which the ACCU review criticizes, and consider only the semantics of
the Pop member.

That member returns a reference to an Object, and also removes that object
from the stack as a side effect. So the question immediately came to mind:
Where is the Object to which the reference is referring, if it's not on the
stack?
Most of the time the Pop as implemented should work without a problem.

If you do somehing like:

Object obj = SA.Pop();

a copy of the reference is assigned to obj.

Only if you go:

Object & obj = SA.Pop();

are you actually using the reference on the stack and therefore in
danger of the situation you described.
The answer is that it's still on the stack; it's just that the variable that
keeps track of the size of the stack has been decremented so that the size
no longer includes the Object to which the reference is returned.

There's nothing wrong with this behavior so far: The object will persist as
long as the stack does and as long as the stack's size doesn't grow back to
where it was before the Pop was executed. But that means that if you call
Pop, save the reference that it returns, and call Push again, the object to
which Pop returned a reference will change its value.

This strikes me as hazardous behavior, which ought to be clearly documented.
As far as I can see, it isn't. So I would take a closer look at this book
before spending money on it.

Feb 7 '07 #7

P: n/a
arnuld wrote:

YES, that is why i removed my post. actually that is because ACCU has
some trouble. whenever i search something, it shows me the white-
page :-(

You've learned something valuable then. Removing a post from Google
Groups only makes it unavailable from the archives. It doesn't even (as
far as I can tell) send a cancel message, which many news servers would
ignore anyway. There's little or no effect on the majority of newsgroup
participants which use traditional news services and newsreaders
(someone was offended elsewhere when I said "real newsreaders").

Brian
Feb 7 '07 #8

P: n/a
On Feb 7, 9:20 am, "Andrew Koenig" <a...@acm.orgwrote:
"arnuld" <geek.arn...@gmail.comwrote in message

news:11**********************@v45g2000cwv.googlegr oups.com...
http://www.brpreiss.com/books/opus4/html/page9.html

I looked into the text at random and it didn't take me long to find
something I consider dubious.

Look at this page:

http://www.brpreiss.com/books/opus4/...ECTION00711300...

It talks about implementing a stack. Leave aside the semantics of class
Object, which the ACCU review criticizes, and consider only the semantics of
the Pop member.

That member returns a reference to an Object, and also removes that object
from the stack as a side effect. So the question immediately came to mind:
Where is the Object to which the reference is referring, if it's not on the
stack?

The answer is that it's still on the stack; it's just that the variable that
keeps track of the size of the stack has been decremented so that the size
no longer includes the Object to which the reference is returned.

There's nothing wrong with this behavior so far: The object will persist as
long as the stack does and as long as the stack's size doesn't grow back to
where it was before the Pop was executed. But that means that if you call
Pop, save the reference that it returns, and call Push again, the object to
which Pop returned a reference will change its value.

This strikes me as hazardous behavior, which ought to be clearly documented.
As far as I can see, it isn't. So I would take a closer look at this book
before spending money on it.
Reading the example again, I got more horrified.

The Stack is actually an Array of Object pointers, requiring the user
performs all memory management correctly - with a lot of casts. A more
honest implementation would be a C-style function using explicit
pointers: using references does not make the code Object-Oriented
(though the book's title might imply that).

See the example of of a simple RPN calculator at
http://www.brpreiss.com/books/opus4/...tml#progapp01c
(which strangely only does single digit arithmetic!) to see the amount
of irrelevent baggage required by the user. The code is full of new
and delete - the latter being of the address of reference variables!
This code is extremely brittle - a single delete in the wrong place
would cause havoc.

A simple (templatized) stack of objects would be simpler (no casts)
and safer (no 'new's requiring matching 'delete's). If the objects in
question were large or complex and deserving of being managed on the
heap (hardly necessary for integers up to 9!), smart pointers would be
almost as simple.

If you look at the Java version (http://www.brpreiss.com/books/opus5/
html/page146.html#progAlgorithmsj), you will see how this mess came
into being: Java can only create non-primitive objects on the heap -
hence the 'new's - and does not have templates - hence the
proliferation of casts. Not being a Java expert, I guess this is
pretty idiomatic Java.

Java does not have pointers (or more precisely, all non-primitive
objects are garbage-collected pointers), so the naive C++ translation
uses references to look like the Java version, with C-style casts
(which are safe [c.f. dynamic_cast] in Java) kept unchanged.
Presumably the 'delete's were added to fix the memory leaks arising!

A well written, idiomatic C++ version would actually be much simpler
even than the Java original: there would be no casts or 'new's needed
at all, and no '*' except for multiplication. The resulting function
is 5 lines shorter, with 53 symbols pruned from the remaining lines,
for example the addition block becomes:
{
Int arg2 = stack.pop();
Int arg1 = stack.pop();
stack.push( arg1 + arg2 );
}

This code is pure algorithm (the Ints could even be replace by a
templatized type, to allow for complex<rationalcalculators to be
produced on demand) with no implementation showing, which is what good
OO facilities should be presenting to the user - who may not be a full-
time programmer by profession.

Best Regards,

David

Feb 7 '07 #9

P: n/a
"blangela" <Bo***********@telus.netwrote in message
news:11**********************@s48g2000cws.googlegr oups.com...
Most of the time the Pop as implemented should work without a problem.
As a general rule, I consider such behavior to be worse than code that never
works at all.

The trouble is that if it works most of the time, and I happen to use it
without realizing that it's not assured to work, it is likely that my tests
will happen to succeed even though my code is wrong.
Feb 8 '07 #10

P: n/a
On Feb 7, 3:20 pm, "blangela" <Bob_Langel...@telus.netwrote:
<snip>
Most of the time the Pop as implemented should work without a problem.
This is a like saying "most of the time when turning left, the
steering wheel will not unscrew and fall off in your hands".
If you do somehing like:

Object obj = SA.Pop();

a copy of the reference is assigned to obj.
Yes, a copy of the reference[d object] *would* be assigned to obj.
Unfortunately, the object pointed to by the stack is now inaccessible
- or deletable - by any of the provided interfaces - including Purge()
and Stack's destructor - so a memory leak is inevitable.

A straightforward implementation of Pop() using C++ idioms would have
the same syntax as this and would work as expected.
Only if you go:

Object & obj = SA.Pop();

are you actually using the reference on the stack and therefore in
danger of the situation you described.
This is actually the only "safe" way to use the class!

One way to look at the issue is to consider how the member functions
would be documented if done diligently.

For the idiomatic C++ version (ignoring underflow and overflow
problems, which can reasonably be separated out as an exception
specification), the documentation would be like this. It assumes only
common Computer Science knowledge:

void Push( const Object &object ); // Add a copy of 'object' to the
stack.
Object Pop(); // Remove the top Object from the
stack and return a copy of it.
Object Top() const; // Return a copy of the top
Object on the stack.

Many C++ programmers would consider the documentation to be stating
the obvious.

Conversely, reasonably complete documentation of the book's version
would look more like this:

// Add a pointer to 'object' to the stack.
// 'object' must have a lifetime which exceeds the time it is on the
stack.
// Normally this means that it is a reference to an Object allocated
on the heap,
// i.e. a dereferenced new Object.
void Push( Object &object );

// Remove the top Object pointer from the stack and return a
reference to the Object pointed to.
// Ownership of the Object reference returned is passed to the
caller.
// For heap allocated Objects, this means that delete must be
invoked on the
// address of the Object reference returned;
// otherwise the Object's destructor will not be invoked and memory
will leak.
Object &Pop();

// Return a reference to the Object pointed to by the top Object
pointer on the stack.
// Ownership of the Object reference returned is NOT passed to the
caller.
// For heap allocated Objects, this means that delete must NOT be
invoked on the
// address of the Object reference returned;
// otherwise a system crash or random behaviour will occur.
Object &Top() const;

There are situations where such complex interfaces are necessary - and
great care and unit testing is necessary to ensure user code adheres
to them. Complex interfaces should be dictated by the problem being
addressed, not the solution as here.

This documentation is akin to having the drivers manual of a car say:

Making a right turn: turn the steering wheel to the right and
straighten up when necessary, noting the number of time you have
turned right.

Making a left turn:
-- if you have made more right turns than left, turn the steering
wheel to the left and straighten up when necessary, noting the number
of time you have turned left.
-- otherwise turn right at the next three juctions [see "Making a
right turn" above].

This would work in all situations, and would be provably correct,
*providing* the driver always followed the instructions diligently.

I wouldn't sell such a car to anyone (I doubt a manufacturer's lawyers
would let them try). Providing code like this - while less likely to
kill anyone immediately - is just about as bad.

Best Regards,

David O.

Feb 8 '07 #11

P: n/a
Andrew Koenig wrote:
"blangela" <Bo***********@telus.netwrote in message
news:11**********************@s48g2000cws.googlegr oups.com...
Most of the time the Pop as implemented should work without a
problem.

As a general rule, I consider such behavior to be worse than code
that never works at all.

The trouble is that if it works most of the time, and I happen to use
it without realizing that it's not assured to work, it is likely that
my tests will happen to succeed even though my code is wrong.

Yeah, something that works 99 times out of 100 isn't much good if that
one time is when you demo it for your boss or the customer, or some
even worse situation.


Brian
Feb 8 '07 #12

P: n/a
On Feb 8, 2:53 pm, "Default User" <defaultuse...@yahoo.comwrote:
Andrew Koenig wrote:
"blangela" <Bob_Langel...@telus.netwrote in message
news:11**********************@s48g2000cws.googlegr oups.com...
Most of the time the Pop as implemented should work without a
problem.
As a general rule, I consider such behavior to be worse than code
that never works at all.
The trouble is that if it works most of the time, and I happen to use
it without realizing that it's not assured to work, it is likely that
my tests will happen to succeed even though my code is wrong.

Yeah, something that works 99 times out of 100 isn't much good if that
one time is when you demo it for your boss or the customer, or some
even worse situation.

Brian
*plonk*

Feb 8 '07 #13

This discussion thread is closed

Replies have been disabled for this discussion.