Let's Code Like it's Nineteen Ninety Five!

Language butchery by Mr Rich on  15.3.10 @ 00:16

So I've taken two quarters of C++ now and I realize that I haven't made much use of C++. Oh sure -- I've used class and new/delete, but that's about the extent of it. Oh yeah -- I can declare a variable wherever I want (ooo!) But, one eventually realizes (although it was pointed out to me) that the difference between a struct and a class is semantical.
  • The default protection for a struct is public;
  • the default protection for a class is private;
  • both can have public and private members.
That said, I don't want to bash an instructor, nor an institution. Both know far more about writing code than I do. But my point is "this" (that's a C joke, BTW):
  • If you want to teach programming using C -- great! ...Use C.
  • If you want to teach programming using C++ -- great! ...Use C++.
  • But for fsck's sake: if you are going to teach C++ like it's C -- please.... at least teach us how to use malloc(), realloc(), and free()!
For the life of me, I cannot understand why we need to spend two quarters dealing with C-Strings. Yes... I get it: we need to terminate a string with '\0'. But even Bjarne says that the Standard Library is there so that we don't have to reinvent the wheel! Isn't C++ supposed to be a better C?

Function ponters: Here's my favorite quote about their use in classes:
"..The operator ::* is used to point to a member of a class. ..... The syntax for ponters to member is a little convoluted and not terribly useful. Ive only seen it once used by an *extremely clever* programmer [ed: not a compliment from this author]. ... and the first maintenance programmer who got the code immediately ripped it out"
- Steve Oualline, Practical C++ Programming, 2nd ed.
... Do we need to understand how to use them? Maybe. One other person put it in terms of "this is actually a good use for a macro..." But using them to point to static functions to a class? Where is the gain? Why not just declare a function w/o a function pointer? Isn't it better to be fscking explicit than to be clever?

Oh well... on to Finals.

 0 comments links to this post

C++ Lesson: That Which Owns the Pointer to the Heap Gets to delete[].

Language butchery by Mr Rich on  14.3.10 @ 13:04

Again, stuff that you don't learn in school, but thanks to the power of the Internet your answers become solved. I'm charged with making a class that reads in a file, parses strings from the file and allocates memory on the heap for those strings. I must use cstrings, new, and delete. Here's the gist of the program:
  1. Main creates a class variable "Dictionary."
  2. The constructor for the Dictionary class:
    • Reads an input file
    • Creates an array of "Entries" on the heap
      ("Entry" is another class consisting of pointers to two dynamically allocated strings)
  3. A menu is presented
  4. etc.. etc..

So what did I find out that was so novel? Thanks to this post on stackoverflow, (yes... that's my post), I realized that I had a memory leak with my Entry Class. I was storing the pointer to the dynamic memory in the entry, but not deleting it when I was done.

A new commandment: That which owns the pointer to the heap gets to delete[]

 0 comments links to this post

C++ Lesson: Don't Mix >> and getline()

Language butchery by Mr Rich on  ;@ 12:13

Compounded logic problems in code are a pain in the arse. Consider the following:


int m_numEntries; // stores the number of entries in the data file
char tempLine[INPUT_LINE_MAX_LEN] = {NIL}; // templine
ifstream dataFile(filename, ios::in ); // the data file
...

dataFile >> m_numEntries; // first line in the file is Number entries
dataFile.getline(tempLine, 256); // get the first line



What was weird was that the read in line wasn't reading in. However, changing to the following got everything to read in correctly:


/* variables the same */
....
// dataFile >> m_numEntries; // < that didn't work
dataFile.getline(tempLine, INPUT_LINE_MAX_LEN);
m_numEntries = atoi(tempLine);
dataFile.getline(tempLine, 256); // get the first line



So now I know not to mix the stream input operator and getline()... But why?

 0 comments links to this post

This page is powered by Blogger. Isn't yours?