what I am trying to figure out: call by value - call by reference - calling a function or to call a function. to call by value or call by reference do you use a pointer * or do you use & I think 'value' is the copy of and 'reference' is the address of bob
Thomas Hruska <[EMAIL PROTECTED]> wrote: Christopher Carver wrote: > On Sat, 2007-12-22 at 23:20 -0700, Thomas Hruska wrote: >> Christopher Carver wrote: >>> I think I'm straight forward and I find to many cooks in the kitchen >>> arguing what to call s spoon, that they forget to make the soup. >> Call it >>> half a dozen or six and it's the same thing. >>> >>> For the original poster, strings in C and strings in C++ can be >>> different depending on who and what train of thinking they have and >> what >>> context the two are talking about. But basically it's nothing more >> than >>> a series of bytes with a terminating character at the end. That's >> not >>> 100% true all the time, but usually the case. >> Wrong. I don't use null-terminators for in-memory data storage. I >> haven't done that for almost a decade (since 1998). Using a special >> character to signify the end of a chunk of data was and still is one >> of >> the worst ideas _ever_. That alone has caused WAY more problems >> (buffer >> overflows, etc.) than I care to count. >> > > I quote: > > A byte with all bits set to 0, called the null character, shall exist in > the basic execution character set; it is used to terminate a character > string literal. > - ANSI/ISO 9899:1990 (the ANSI C standard), section 5.2.1 > > A string is a contiguous sequence of characters terminated by and > including the first null character. > - ANSI/ISO 9899:1990 (the ANSI C standard), section 7.1.1 > > It's not the worst idea ever, because without a null termination > character you are forced to use a storage data type to specify the > length of the data. If the data length is beyond that of the storage > data can hold, the code behavior will become unknown or the coder has to > compensate. Buffer overflows is writing past the allocated storage and > has nothing to do with null terminators. If a coder doesn't compensate > for the null termination, then that's the coders fault, not the > methodology. If you don't use null terminators, then I can safety assume > you just use C++ strings. And that's great, but don't disparage C as a > lessor extent. Is _one_ of the worst ideas ever (I never said 'the worst'). I know what a buffer overflow is. You seem to think there is a difference between ANSI C and ANSI C++ with regards to the underlying usage of memory. There isn't. Using a special character to signify the termination of data has and always will be a bad idea inherited from the DOS days of yore. C is outmoded and outdated. All new software programs (and even existing ones) should be [re]written in C++ even if classes and templates are not used. However, the specific class/template features of C++ offer methods of eliminating the possibility of buffer overflows in the first place. Something that C simply can't offer. > The poster needed away to copy one string to another without the use of > strcpy() functions, so we are talking about ANSI-C strings; though K&R > strings are the exact same; hence a null terminator. I provided helpful > information without giving a blatant answer or a canned non-helpful > response. I think most folks can Google or go to bookstores. Giving some > actual helpful pointers (haha, pointers) is not only more helpful, but > friendlier than cut and paste canned responses. The canned response was WAY more helpful than your recommendation of a non-ANSI Standard book that will lead the OP astray. And my response included a list of books that they should be reading by authors who adhere to the ANSI Standard. > The "Understanding Pointers In C" by Yashavant is all standard C > operations, so it will run on all C compilers on any platform. Show me a > snippet from the book I mention that does not work on any platform or > compiler. The same rules apply from C89 to C99 compliant compilers. I > can not comment on his other works. But this is an excellent book that > takes great care in explaining and showing all the different aspects of > memory handling. Far more than most C books and far greater than most C > ++ books will ever tread. > > After reading your response, I know you have not read this book. http://www.linuxbazar.com/index.php?main_page=product_info&products_id=5697 One of the topics in the list is: "Near, far and huge pointers." That's all I need to know. That's not only non-ANSI Standard, it is badly outdated (16-bit days of Turbo C). Yashavant causes more damage than not. Maybe he's fixed it in some newer edition but I seriously doubt it and his older editions populate the world like a plague. Even Wikipedia confirms that his books (including the one you recommend) are Non-Standard: http://en.wikipedia.org/wiki/Yashavant_Kanetkar I now have even less reason to read that book and you should still not be recommending it. There is a list of recommended books that this list uses and I generally trust the judgment of the people here who have put that list together. -- Thomas Hruska CubicleSoft President Ph: 517-803-4197 *NEW* MyTaskFocus 1.1 Get on task. Stay on task. http://www.CubicleSoft.com/MyTaskFocus/ --------------------------------- Never miss a thing. Make Yahoo your homepage. [Non-text portions of this message have been removed]
