Christopher Coale wrote: > Thomas Hruska wrote: >> >> >> Christopher Coale wrote: >>> Thomas Hruska wrote: >>>> I'm probably the most guilty party here. My view is that pointers are >>>> an _advanced topic_. It doesn't mean you shouldn't learn how to use >>>> them nor use them at all. >>>> >>> I'm moreso referring to this question by Paul Herring, "Why are you >>> using pointers in C++?" That seems to imply that we should not use >>> pointers in C++. I agree with you that pointers should not be taught >>> right away, and most formal curricula do not teach it right away (in >>> fact, you'll probably go at least half a semester before reaching them). >> Because exposed pointers at the Application layer almost always shows a >> lack of understanding of what templates and classes are for. >> > > I don't see the connection. Can you not have a pointer based on a > template? Can you not have an object-pointer?
Sure? (Not really sure what you are wanting here.) If in reference to new and delete: IMO, 'new' and 'delete' belong in the Library layer and you should be able to count on one hand how many times new/delete are used in the entire application (including the Library layer) - no matter how big the application gets. The application could be 50 lines or a million lines. >>> In a formal curriculum, C++ is not the first language you take. >>> Generally you start with "Computer Logic" (which is an introduction >> to a >>> language like Java, VB.net, etc.), followed by C/pascal, then C++. So >>> generally, all they need to do is carry over the same logic but >> adapt to >>> the C syntax (which is really just memorization, the logic is the >> same). >>> They won't be "learning" basic code structures, but rather learning the >>> C++ syntax and how to adapt their logic to it. But if you are talking >>> about simple tutorials to learn C++, then I agree. >> You must be living in a completely different world from the one I live >> in. >> > Well that is for damn sure. If you started with C++ at school, then you > went to a horrible school. I am a paid tutor at my college and see how > well it works when you teach the student logic prior to teaching them a > low-level language. And even beyond that, teaching them C before > teaching them C++ (which is debatable and besides the point of this > topic). So, you must be living in a different world than I. I taught myself how to program in the 80's. And later taught myself C. And mostly taught myself C++. I didn't have the luxury of going to school to learn the C language or have support groups like this one or even really good books let alone Internet access (yes, there used to be a time of no Internet). For a while when I was at college C/C++ were the "first languages" taught. The "first language" alternatives at the time across the board were Pascal, C, C++, or LISP. And some places were teaching Assembler (still). You have it rather easy. >> Most educational institutions I'm aware of that teach C/C++ start >> with C/C++ with _optional_ starter courses in another language. >> > > Rarely will you see a C/C++ course without prerequisites in a logic > course, introduction to computer science course, etc. So, as I said > before, if they throw you into C++ then either it is a terrible > school/curriculum. Well, if that is now the landscape, then things have certainly improved _significantly_ over the past two years (I've been kind of out of touch). It buys a couple semester's worth of time to let the basics sink in. Then again, colleges COULD be seeing C++ to be a dying language (which you already agreed to is the general feeling) and the attitude surrounding dying languages in college is generally to teach them later on (if at all). >>>> C++ makes it possible to defer teaching pointers until MUCH later on. >>>> >>> I agree. >>> >>> So here is my conclusion: you should *not* avoid pointers in C++. If >>> they consistently cause your program to develop memory leaks and >>> crashes, then you need to go back and re-learn how pointers work. I >>> agree that pointers should not be taught too early when learning C++ >>> (and they usually aren't in a formal curriculum). >> By "much later on", I mean several years, not half a semester. >> > > I dare you to mention that to any real computer science/engineering > professor. The problem doesn't lie within the difficulty of pointers - > it lies in the student's lack of understanding of how the computer > actually works (hence leading to not actually understanding what a > pointer is). My former professors had the same problem. And still do. We've moved beyond wires and circuits to a box. A magical box. Pointers are not relevant to people. They can't comprehend them because they are too low-level. Some people are fascinated by how stuff works. They like to dig into things like pointers, how memory is mapped from kernel space to user space, how each pin on a CPU works, etc. I don't. I want the job to get done. I happen to know the nitty-gritty details in many areas but I don't like working with nitty-gritty. This boils down to my personality. I take very specific things and then generalize them. However, I don't generalize past the point of usability. There is a point where something becomes so generic it isn't usable any more. The beauty of my approach is the ability to reuse the code again later. I try to generalize the code just enough to maybe make it useful again somewhere down the line but not so general that it is unusable. The most generic code I've got involves sockets and I don't really care for it. The reason is because that section of code has the ability to dynamically jump from a TCP/IP socket to a SSL-wrapped one (the same code for HTTP can suddenly do HTTPS with a single line of code that transforms the TCP/IP socket into a SSL-wrapped socket - the HTTP code doesn't notice anything different). >> And I am extremely well-versed in pointers. They may be useful but are >> advanced and dangerous. Improper use causes crash bugs, memory leaks, >> memory corruption, _security vulnerabilities_, etc. >> > > *Improper use*, exactly. I used pointers "properly" for years and years and years (I was allocating arrays of pointers 4 levels deep quite successfully)...and STILL managed to write unstable software. My experience showed me that I could be the best programmer in the whole world with the best understanding of pointers and STILL find the brick wall for smacking my head against after 8 hours of unnecessary debugging dealing with them. It also took three years of working with them for the light to turn on (full comprehension). Even after the light turned on, the above still applied. I spent the next bunch of years trying to figure out how to improve my process of working to get rid of my pesky bugs. The second light dawned when I switched to C++ and realized that I could (ab)use pass-by-reference, 'virtual', and classes and templates to bury pointers in a Library layer and I was able to bury most pointers even further inside two key objects I use everywhere (more on these below). Each Application layer has been incredibly stable since. (I've always had a common Library layer - even in C, but was always casting pointers to strange types. Only with C++ was I able make a very specific distinction between the two layers, eliminate casts, and eliminate pointers from the Application layer.) >> I read that as "programmers can't write stable software to >> save their lives." >> > > Therefore, to accommodate the stupid programmer, we should ban the use > of pointers? Good idea. Not ban. Just consider them to be an advanced topic and something to very rarely use at the Application layer. >> Migrating pointers to a Library layer and then not using pointers at the >> Application layer introduces a level of stability to the Application >> layer not otherwise achieved. Libraries are viewed as reusable code >> that generally stabilize over time. Even within my own Library layer, I >> prefer to migrate pointer use to templates only (specifically, Block and >> BString handle almost everything I need). So, if the same Library is >> used from year to year with enhancements and fixes as the students go >> along, it becomes possible to create incredibly powerful, yet stable >> programs WITHOUT using pointers in the Application layer. >> > I understand, and also agree with you (to an extent). However, pointers > should not be avoided for that sole purpose. It is illogical to write a > wrapper around a library simply to avoid using a pointer in your > "Application layer". When I think of using a pointer, I try to figure out what could be made into common code for potential reuse. There is always something there. I have two objects I use almost exclusively to wrap up what would otherwise be a mess of pointers: Block and BString. Block is similar to std::vector and BString is similar to std::string but both are WAY more powerful and fit better with how I write code. I can do, for instance, Block<Socket::Client::HTTP> and get access to a chunk of sockets that talk to HTTP servers. Not a pointer in sight. And I only have to write HTTP code one time. (And the HTTP code uses Socket::Client::TCPIP - I only have to write generic client socket code one time. Which can be reused for FTP, SMTP, POP3, etc. And, as already mentioned, I can hot-swap an active TCP/IP socket for a SSL-wrapped TCP/IP socket with a single line of code.) What can't be done with Block can almost always be done with BString. As I said, I still use pointers at the Application layer. But only for performance critical code. And ONLY after I've profiled the code to determine where the slow sections are. And, in many quick-n-dirty programs, I could care less about the performance and more about getting it done. >> I'd love to >> see first-year students leveraging files, databases, sockets, and GUIs >> in C++ without having to worry about silly things like pointers, crash >> bugs, memory bounds, etc. >> > I would hate to see first-year students doing any of that in C++. They > shouldn't be in C++ (unless they have tested out of prerequisite > courses). What you are doing is dumbing down the language so it suits a > dumbed down society. My view is that without these things readily available to the average programmer in a business environment, C++ is headed to dead-language status very quickly. This is why I say first-year students (or is it now second-year now due to aforementioned climate shift?) should be doing these sorts of things in C++ and doing them easily. Why does Ruby and Python and C# get all the love? Hint: Ruby wouldn't be on ANYONE'S radar if it wasn't for Rails. Ruby without Rails is utterly worthless. (IMO, Ruby even with Rails is terrible because it is a horrible, horrible language, but people use it anyway. Meh. But those same people agree that Ruby wouldn't be any good without Rails.) -- Thomas Hruska CubicleSoft President Ph: 517-803-4197 *NEW* MyTaskFocus 1.1 Get on task. Stay on task. http://www.CubicleSoft.com/MyTaskFocus/
