does some one want to have a look at the following code,
taken from "Data Structures with C++" by John Hubbard for Schaums outlines edition 1
I typed in this exact code example given on page 316 but it causes an unhandled exception...
p.s. this is a direct copy of the texted code in the book...
Code:
// testing the random_shuffle() Algorithm
// performs a random (but deterministic) shuffle on [pp,qq[
int main()
{ char* s="ABCDEFGHIJ" ;
cout << s << '\n' ;
for (int i=0; i<4; i++)
{ random_shuffle(s,s+10) ;
cout << s << '\n' ;
}
}
apparantly it works in the book, does it work for you,Im thinking not?
you must of cause #include <algorithm>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-10-31
>> you must of cause #include <algorithm>
Then why did you not include that in the post if this is "a direct copy of the texted code in the book"? It would have been simpler just to do that than to explain that it was needed! Very odd thinking. That is not all it needs to compile either.
Anyway, the code is nonsense. I don't have the book, but if this code is not intended as an example of bad code, then throw the book away. You always have to wonder about a book that no one has bothered to review at Amazon! ;-)
For starters s is a pointer to a literal string constant. You cannot modify a constant, but that is what random_shuffle will try to do. Secondly, the use of a magic number in the second parameter of random_shuffle is just bad practice.
include <algorithm>
include <iostream>
using namespace std ;
// testing the random_shuffle() Algorithm
// performs a random (but deterministic) shuffle on [pp,qq[
int main()
{
char s[] = "ABCDEFGHIJ" ; //****
cout << s << '\n' ;
for (int i = 0; i < 4; i++)
{
random_shuffle( s, s + sizeof(s) - 1 ) ; //******
cout << s << '\n' ;
}
}
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is a thought process (I went through it too) where one assumes that code examples
from "books" (as in "But I typed it straight out of the book!") are supposed to be
guaranteed to work.
Well, a couple of notes of context
(1) "Typo's" happen in the process, and not everything gets caught in the editing process.
Once something is in print, it has to wait for a later edition to be fixed. Sometimes there
are errata, printed or online, but those can get lost or go offline.
(2) The timescale for publishing books can be long on the scale of an evolving language.
There are still *plenty" of otherwise good (or not) books out there that pre-date the
ANSI standard, and, as a result, have examples that generate warnings or errors.
(3) Not every author actually checks / tries to compile their code.
(4) Even if they do check / compile their code, code that compiles on their favorite
compiler may not compile on yours, due to uneven standards compliance or ambiguities.
(5) Related to (3), there is also a school of thought among teachers and authors that
dealing with issues when compiling an example is a good way to learn, really long term
learn things about compiling. It is, in part, true. There are lessons I learned from
30 years ago that still stick in my head because I fought an issue for several hours.
It is not a "nice" way to do things, but it works. Understanding errors and error
messages, and finding and correcting the associated errors is ALWAYS going to be a
big part of the process that is programming. I have been doing this for over 30 years,
and it is a very rare event that I write code that works correctly from the get-go.
(Funny on me - I wrote some good C code yesterday, which was a problem only because I happened
to be working on a Python program at the time). Folks that are new to programming have
a reflex (I had it too) - that goes by the following flowchart
(1) Get an error
(2) See that its an error, but don't read it or think about it what it means in terms of
what you just did.
(3) Panic
Only by correcting this reflex can you become able to really program. Errors are a natural
part of this work - make peace with that.
In short - examples from books are just as likely to have errors as not, it is a mistake
to get frustrated, or blame the tool because they do not compile or run out of the
box.
Wayne
Tangential note: we see people who pass through here from time to time who seem to think a
viable approach to learning to program is typing in examples, compiling, and running
them, so they can learn "by example". The "Ahh, that's how you do that" folks. They
will usually justify it by stating something along the lines of "that's the way I
learn".
Well, I have never seen that work. It is like assuming one can learn to write music
by looking at a piece by Mozart as an example.
Programming is part problem solving, and part logical exercise, and actually not nearly
as much about syntax (or magical words) - and much of that process is subtle, and does
not hop out at one when they look at the code
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wayne's point about typos reminded me of a book I bought on writing games that came with a floppy disk (yes, it was last century) with all the source code described in the book. Even that had typos! I can understand typos in the hard copy, but you'd think they'd do a test compile of the soft copy. It had a line terminated with a colon instead of a semi-colon and some other bizarre stuff like that.
Also, just curious here, not trying to stick up for the author of the book, but is it possible that char* s="ABCDEFGHIJ" gets interpreted as char s[]="ABCDEFGHIJ" by the author's compiler since it's not explicitly declared const? Because that would work in the example I think.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Damn, my reflex did get the better of me.
Sorry people.
Thats a helpful post Wayne thanks,
and thanks Clifford for the reply.
Maybe Ill go get that book back!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-10-31
>> anyway, this John Hubburd bloke sounds like he knows his stuff,
>> still, out the * window with it and my 50 * bucks.
Well, perhaps I was over stating its deficiencies. It depends on the quality of the rest of it.
Maybe he does know his stuff, but the book has perhaps not been adequately technically vetted and proofed. You need to bear this in mind when using it and exercise caution. If the book is attempting to teach C++ I would worry, but it seems likely that its emphasis is rather on data structures, so take what it says on data structures, but treat what it has on programming with caution - use your own judgement - being in a book never makes it right in itself.
If it turns out that a high percentage of examples contain errors such that it slows down your progress, then you might consider throwing it out. That was a pretty fundamental error though!
This book appears to be out of print. What does that tell you perhaps?
Osito: >> ..is it possible that char* s="ABCDEFGHIJ" gets interpreted
Osito: >> as char s[]="ABCDEFGHIJ" by the author's compiler
Anything's possible. I think that the ability to declare a non-const pointer to a const string literal is deprecated in the latest ISO standard. If the author perhaps used a 16bit compiler without memory protection and access rights mechanisms, it would probably execute. But it would still be modifying data that it should not.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
does some one want to have a look at the following code,
taken from "Data Structures with C++" by John Hubbard for Schaums outlines edition 1
I typed in this exact code example given on page 316 but it causes an unhandled exception...
p.s. this is a direct copy of the texted code in the book...
Code:
// testing the random_shuffle() Algorithm
// performs a random (but deterministic) shuffle on [pp,qq[
int main()
{ char* s="ABCDEFGHIJ" ;
cout << s << '\n' ;
for (int i=0; i<4; i++)
{ random_shuffle(s,s+10) ;
cout << s << '\n' ;
}
}
apparantly it works in the book, does it work for you,Im thinking not?
you must of cause #include <algorithm>
The errata for this book is available at: http://www.mathcs.richmond.edu/~hubbard/Books.html
Unfortunately none for page 316! :-\
>> you must of cause #include <algorithm>
Then why did you not include that in the post if this is "a direct copy of the texted code in the book"? It would have been simpler just to do that than to explain that it was needed! Very odd thinking. That is not all it needs to compile either.
Anyway, the code is nonsense. I don't have the book, but if this code is not intended as an example of bad code, then throw the book away. You always have to wonder about a book that no one has bothered to review at Amazon! ;-)
For starters s is a pointer to a literal string constant. You cannot modify a constant, but that is what random_shuffle will try to do. Secondly, the use of a magic number in the second parameter of random_shuffle is just bad practice.
include <algorithm>
include <iostream>
using namespace std ;
// testing the random_shuffle() Algorithm
// performs a random (but deterministic) shuffle on [pp,qq[
int main()
{
char s[] = "ABCDEFGHIJ" ; //****
cout << s << '\n' ;
for (int i = 0; i < 4; i++)
{
random_shuffle( s, s + sizeof(s) - 1 ) ; //******
cout << s << '\n' ;
}
}
yeah, so thanks for the reply Clifford.
Like I said,thats the exact code from the book,
I didnt #include shit cause nor did the f*kin book alright.
anyway, this John Hubburd bloke sounds like he knows his stuff, still, out the * window with it and my 50 * bucks.
There is a thought process (I went through it too) where one assumes that code examples
from "books" (as in "But I typed it straight out of the book!") are supposed to be
guaranteed to work.
Well, a couple of notes of context
(1) "Typo's" happen in the process, and not everything gets caught in the editing process.
Once something is in print, it has to wait for a later edition to be fixed. Sometimes there
are errata, printed or online, but those can get lost or go offline.
(2) The timescale for publishing books can be long on the scale of an evolving language.
There are still *plenty" of otherwise good (or not) books out there that pre-date the
ANSI standard, and, as a result, have examples that generate warnings or errors.
(3) Not every author actually checks / tries to compile their code.
(4) Even if they do check / compile their code, code that compiles on their favorite
compiler may not compile on yours, due to uneven standards compliance or ambiguities.
(5) Related to (3), there is also a school of thought among teachers and authors that
dealing with issues when compiling an example is a good way to learn, really long term
learn things about compiling. It is, in part, true. There are lessons I learned from
30 years ago that still stick in my head because I fought an issue for several hours.
It is not a "nice" way to do things, but it works. Understanding errors and error
messages, and finding and correcting the associated errors is ALWAYS going to be a
big part of the process that is programming. I have been doing this for over 30 years,
and it is a very rare event that I write code that works correctly from the get-go.
(Funny on me - I wrote some good C code yesterday, which was a problem only because I happened
to be working on a Python program at the time). Folks that are new to programming have
a reflex (I had it too) - that goes by the following flowchart
(1) Get an error
(2) See that its an error, but don't read it or think about it what it means in terms of
what you just did.
(3) Panic
Only by correcting this reflex can you become able to really program. Errors are a natural
part of this work - make peace with that.
In short - examples from books are just as likely to have errors as not, it is a mistake
to get frustrated, or blame the tool because they do not compile or run out of the
box.
Wayne
Tangential note: we see people who pass through here from time to time who seem to think a
viable approach to learning to program is typing in examples, compiling, and running
them, so they can learn "by example". The "Ahh, that's how you do that" folks. They
will usually justify it by stating something along the lines of "that's the way I
learn".
Well, I have never seen that work. It is like assuming one can learn to write music
by looking at a piece by Mozart as an example.
Programming is part problem solving, and part logical exercise, and actually not nearly
as much about syntax (or magical words) - and much of that process is subtle, and does
not hop out at one when they look at the code
Wayne's point about typos reminded me of a book I bought on writing games that came with a floppy disk (yes, it was last century) with all the source code described in the book. Even that had typos! I can understand typos in the hard copy, but you'd think they'd do a test compile of the soft copy. It had a line terminated with a colon instead of a semi-colon and some other bizarre stuff like that.
Also, just curious here, not trying to stick up for the author of the book, but is it possible that char* s="ABCDEFGHIJ" gets interpreted as char s[]="ABCDEFGHIJ" by the author's compiler since it's not explicitly declared const? Because that would work in the example I think.
Damn, my reflex did get the better of me.
Sorry people.
Thats a helpful post Wayne thanks,
and thanks Clifford for the reply.
Maybe Ill go get that book back!
>> anyway, this John Hubburd bloke sounds like he knows his stuff,
>> still, out the * window with it and my 50 * bucks.
Well, perhaps I was over stating its deficiencies. It depends on the quality of the rest of it.
Maybe he does know his stuff, but the book has perhaps not been adequately technically vetted and proofed. You need to bear this in mind when using it and exercise caution. If the book is attempting to teach C++ I would worry, but it seems likely that its emphasis is rather on data structures, so take what it says on data structures, but treat what it has on programming with caution - use your own judgement - being in a book never makes it right in itself.
If it turns out that a high percentage of examples contain errors such that it slows down your progress, then you might consider throwing it out. That was a pretty fundamental error though!
This book appears to be out of print. What does that tell you perhaps?
Osito: >> ..is it possible that char* s="ABCDEFGHIJ" gets interpreted
Osito: >> as char s[]="ABCDEFGHIJ" by the author's compiler
Anything's possible. I think that the ability to declare a non-const pointer to a const string literal is deprecated in the latest ISO standard. If the author perhaps used a 16bit compiler without memory protection and access rights mechanisms, it would probably execute. But it would still be modifying data that it should not.
Clifford