First off let me express my deepest thanks to everyone that has critiqued the first tutorial. I have written a second tutorial trying to explain "cin" and "cout" so that a novice can add some interactivity to their applications. When critiquing, please remember, the target audience is complete novices or hobbyist, or people beginning. But once more would appreciate anyones critique, and of course, if your critique was used, you will be added to the tutorial under additional credits. Thanks, again, everyone! Find that tutorial at http://www.totalcoder.com if you haven''t read the first tutorial please do since that is still under development. Also an additional thought I thought about was developing a simple IDE to use Borland''s compiler. It would be a great excercise for beginners to watch and see the development of an application, plus it would give some added benefit to the visitors. Sam ----- TotalCoder http://www.totalcoder.com "Resources, tutorials, and articles for the novice, part-time, and hobbyist programmer"

- required platform: wrong, shoudl work with ANY c++ compiler.
- streams are not declared in ''iostream.h'' but in ''iostream''.
- yes, you need to address somewhere the namespace issues when discussion the STL.
- yes, streams are part of the STL.
- you need to explain what a stream is : an abstraction for a communication channel, be it console/file/string ... or socket (still looking for a good stream socket class)
- you''re jumping ahead too much.
- the explanation for char, byte and stuff doesn''t quit belong here and you should be using string instead : it works as well (or better) and you wouldn''t have to explain it until much later.
- second code example is broken : cout<<"Hello World! "< }

By the way, your code wont work, since your pointer is unallocated.

Hey,

First of all I suggest you don''t use pointers so soon as it can be a very confusing subject and most newbies seem to get confused with pointers.

To talk about "cin" you could rather use an "int " rather than a "char *".

I would suggest not to use pointers at all until you cover the pointer subject.

quote: Original post by Fruny
- streams are not declared in ''iostream.h'' but in ''iostream''.

Streams are declared in ''iostream.h'' and you can use it if you want, you just can''t use namespaces if you do it that way.


---
Make it work.
Make it right.
Make it fast.

Thanks for the input. Can for novices can I use std::string without bringing on too much confusion? It was hard enough trying to explain char* and then having to delve into bits and bytes. The reason I did this was to try and tell the novice no matter what you see the computer doing, no matter what application, no matter what game, it is all just a bunch of 1''s and 0''s. By doing this, I hoped to instill into them that no matter how complex the subject or portion may be it is just a matter of representing 1''s and 0''s.

Required platform change is correct and I''ll reflect that on both tutorials for C++. I was thinking of the platform that this compiler runs on which is Windows based. But since I''m trying to teach basic c++ in these tutorials, I''ll make the difference known.

Fruny I tested this code on the platform mentioned and it compiled and ran fine, and I don''t think there would be an issue of a memory leak since I did not create anything with new. But it worked. And I like flame warrior''s comment on pointers I forgot I can represent strings with other variable types at this point. Because pointers are very important and a hard concept to grasp.

I keep getting those damn HTML typos! See this is what happens when you code using MFC and a code correcting, syntax coloring, feature full IDE, you lose grasp of the basic concepts. Writing these tutorials has also helped me relearn a couple of basic issues.

I''ll make the revisions and repost on this thread when it''s done, and I assume everyone here won''t mind if I add them to the additional credit portion? Thanks once more for your valuable critique.

Sam
-----
TotalCoder
http://www.totalcoder.com
"Resources, tutorials, and articles for the novice, part-time, and hobbyist programmer"

I''m not talking about a memory leak, I''m talking about the fact that you do "cin >> FirstName;" without making sure that FirstName (a pointer) points to a valid address, corresponding to allocated memory. Which you failed to do. I assume you ran a debugging build of your code, and that bcc caught your error.

Fruny thanks for your help with this one, I just have to put you on the byline. Something interesting to note here. Using the Borland compiler no problem, no warnings got the code snippet to run fun, however, using Visual C++ I do have first chance exception error which is resolved by changing it to a explicit definition of a character arrays (i.e. char FirstName[20] as is mostly taught in text books, because I assume it is right.

However, I''m pondering A.)Why it works in one compiler/linker and not the other? B.) If this is the case which is more ANSI C++ compliant, and why one runs fine and not the other?

Intriguing questions I hope to have the answer to late tonight or tomorrow morning. For anyone jumping on the thread the code is

quote:
#include
using namespace std;

int main()
{
char* FirstName;

cout<<"Please enter your first name: ";
cin>>FirstName;
cout<<"Hello, "<
}

Works fine compiling under Borland, and executable runs, and does not work under Visual C++, compiles but First Chance exception error during the istream template code. This is an intriguing issue and if someone knows why it would work under one compiler and not the other, please share it with me :-)

Sam
-----
TotalCoder
http://www.totalcoder.com
"Resources, tutorials, and articles for the novice, part-time, and hobbyist programmer"

It shouldn''t work. Where is the data being stored? I''m rather surprised Borland lets that one through (it should compile, but referencing memory you haven''t allocated - via the cin>> FirstName statement - should cause an exception). It''s bad coding practice anyway, as doing things like that makes your code susceptible to buffer overruns and other exploits.

[ GDNet Start Here | GDNet FAQ | MS RTFM | STL | Google ]
Thanks to Kylotan for the idea!

Oluseyi thanks for the update. After reviewing the myriad of books and other references on the internet I have come to the same conclusion. Isn''t it funny how much Visual C++ and MFC hides so much from you, and you forget the most basic of concepts?

Bad coding practice, hmmmm. Wouldn''t it be bad to allocate a fixed array of characters, as most text books do in the beginning, and not instill into the programmer to check the upper and lower bounds of the string being passed in? This is cause for a buffer overrun as well. Is focusing on the concept of how it works more important than instilling good coding practice as most advanced books will teach eventually?

I mean why say do this one way for 2 semesters and 100 chapters, and eventually learn that you should have been checking the upper and lower bounds to avoid buffer overruns? Should I start instilling this from the beginning? Or is this a concept best introduced later, when the novice has more time to grasp the basic concepts? This is intriguing and something I did not think about in the beginning. Plus I''ll rewrite the sample so it can compile on both compilers.

Sam
-----
TotalCoder
http://www.totalcoder.com
"Resources, tutorials, and articles for the novice, part-time, and hobbyist programmer"