[prog] Questions on my first attempt at C++

Robert J. Hansen rjh at sixdemonbag.org
Mon Apr 14 10:38:57 EST 2003


> 1) I am trying to sort out how to use the string class;  when I declare a 
> variable of this class is it best done by declaring it std::string?  ie with 
> the scope name.     Is it used in the same way as the return type for a 
> function?

Depends on how your code is set up.  The string class lives in the std
namespace, so unless you've got a "using" statement, you're going to
need to fully qualify the name--i.e., std::string.

For example:

#include <string>

std::string foo; // name must be fully qualified here

int main()
{
   using std::string; // but in this scope, we can just use string
   string bar("Baz Quux!");
   foo = bar;
   return 0;
}

> 2) How do i put numbers (eg int double) into a string object?

You can't, not directly.  You need a stringstream object.  It's in
either strstream or sstream, depending on how standards-conformant your
compiler is--the strstream header is deprecated and all compilers should
be using sstream, but some don't.  Fortunately, GCC 3.2 is pretty
conformant and you don't need to worry about it.  :)


#include <string>
#include <sstream>
#include <iostream>

using std::string;  // throughout our file, we can refer to string and
using std::stringstream; // stringstream without std:: qualification

int main(void)
{
   stringstream foo;
   string bar;
   foo << 3.14159;
   foo >> bar;
   // Note that we _didn't_ have "using std::cout;" and
   // "using std::endl;" in our using statements, above,
   // so we've got to fully qualify these names.
   std::cout << bar << std::endl;
   return 0;
}

> 3) In construcing my own class when do I need a destructor?  What do I need to 
> put into it?

You need a destructor if your class has resources that need to be
deallocated before the object goes poof.  For instance:


struct BadStruct {
   char *ptr;
   BadStruct() { ptr = new char[1048576]; } // allocate 1Mb memory
};

Now whenever BadStruct is created, it'll allocate 1Mb of memory.  But
when the object is destroyed, it'll fail to reclaim that memory.  So
every BadStruct is a 1Mb memory leak just waiting to happen.  (And yes,
I've seen errors like this in production code.)

struct BetterStruct {
   char *ptr;
   BetterStruct() { ptr = new char[1048576]; }
   ~BetterStruct() { delete[] ptr; }
};

Whenever BetterStruct is destroyed, it'll remember to return the 1Mb of
memory to the system.

struct BestStruct {
   std::auto_ptr<char> ptr;
   BestStruct() { ptr = new char[1048576]; }
};

BestStruct uses a C++ object, an auto_ptr, which has a lot of
deallocation magic.  Warning: auto_ptrs are __NOT__ a beginner's
technique.  They have a lot of sharp edges and you can lose your arms if
you touch it the wrong way.  But sometimes, they make things much
easier, and I think it's sometimes a good idea to show beginners simple
examples of more advanced techniques they'll come across later.  :)

> Is there a convention for naming writters and readers?  

These tend to be called "accessors".  There is a convention, yes, but a
lot of people choose to disregard the convention.  The convention is as
it's shown in Bjarne Stroustrup's _The C++ Programming Language_:


struct AccessorExample {
   private:
      int _x; // common convention is to prefix private vars with _
   public:
      AccessorExample() { _x = 0; }
      const int x() { return _x; } // get-accessor
      void x(const int newval) { _x = newval; } // set-accessor
};


int main()
{
   AccessorExample foo;
   std::cout << "foo.x() = " << foo.x() << std::endl;
   foo.x(5);
   std::cout << "foo.x() = " << foo.x() << std::endl;
}


... I.e., the Stroustrup style of accessors is to use the same methods
both for getting and setting.  Call it with no arguments and it's a get
accessor.  Call it with arguments and it's a set accessor.

That said, the Stroustrup style hasn't seemed to have caught on.  Most
of the C++ code I see uses Java-style accessors (where you'd do
"foo.get_x()" and "foo.set_x()").

-- 
Robert J. Hansen <rjh at sixdemonbag.org>



More information about the Programming mailing list