Orchid Win7 v1 <voi### [at] devnull> wrote:
> Basically, last time I read a book on C++, it said to never use pointers 
> and always use references.

References aren't going to magically solve the problems that pointers
have.

> I'm using an iterator to keep track of where I am in a collection. 
> ("Pattern" is actually a trivial alias to std::vector.) But as soon as 
> you value-copy a container, all the iterators suddenly stop being valid. 
> Ergo, I have to somehow avoid copying the vector at any cost.

> What I would *actually* like to do is just throw iterators around. 
> However, for reasons beyond my comprehension, nobody thought to include 
> an "is_at_end()" method in the standard iterators. So without access to 
> the original container, it's impossible to know if you've reached the 
> end. If it weren't for this annoying detail, I wouldn't need references 
> at all!

I don't really understand what it is that you are trying to do, but it
sounds to me like you are trying to do it in a much more complicated
manner than it probably needs to.

If you have your elements in a vector, and you are only adding elements
to it, then try using indices instead of iterators/pointers.

> I always find it slightly surprising when C++ actually does stuff for 
> you automatically. Everything seems to manual most of the time...

Why is it surprising? That's the whole point for the existence of RAII.
(The name pretty much implies it.)

> Yeah. I figured that out eventually. Not, of course, that you can ask 
> the IDE to trap a segfault and pop up the line of code it was trying to 
> run when the crash happened. I had to laboriously step through the code 
> line by line until I discovered the problem.

There exist programs that can track the execution of your program and
notify you of such errors. (valgrind is one example in Linux, but there
are others for Windows. I don't know if there are any free ones.)

> > Does 'ThePattern' need to point to some other object, or can it simply
> > contain a *copy* of that object?

> As I say, copying it stops all the iterators working.

Why do you need iterators in the first place? Having iterators pointing
to a data container inside some object which gets passed around is not
only a very bad idea, it's highly confusing from a program design point
of view. It just sounds to me like you are making the program a lot more
complicated than it needs to be.

This isn't Haskell.

> >> Today it's references. Last time it was
> >
> >>     catch (std::exception e)
> >>     {
> >>       std::cout<<  e.what();
> >>     }
> >
> >> which *always* says std::exception, even if that wasn't the exception
> >> thrown.
> >
> > I don't understand where you are getting at.

> Apparently you have to say "std::exception & e", otherwise whatever the 
> exception was gets type-cast to a plain std::exception. (In particular, 
> I was throwing std::runtime_error with an explanatory message, and 
> tearing my hair out trying to figure out why the hell I can't see the 
> message in the debug logs...)

Well, if you are taking an object by value, you will get a value of
that particular type...

> The memory leak was due to some code that does actual run-time 
> polymorphism. As I understand it, it's impossible to do dynamic dispatch 
> in C++ without pointers.

You can use references as well in many cases. For example

  void foo(const MyClass& obj)
  {
      // If 'func()' is virtual and 'obj' is of a derived type, the derived
      // class implementation will be called:
      obj.func();
  }

> The code I'm fiddling with today doesn't contain *any* dynamic 
> allocation at all. I'm merely trying to use references to avoid copying 
> stuff, to keep iterators valid, and to allow a function to alter 
> variables in the caller (i.e., "out parameters").

It just sounds like you are implementing a kludge to get around the
problems of a needlessly complex design.

Iterators are effectively pointers. (In the case of std::vector, they
may well be *literally* pointers.) They have all the same problems as
pointers.

> As an amusing aside, the other day I got to read some code where a guy 
> did the opposite of what you accuse me of: he wrote C# as if it was C++. 
> It was ugly! I especially enjoyed how EVERY SINGLE CLASS had an explicit 
> destructor like this:

"As if it was C++" is a bit... off. I seldom write any destructors myself.
I don't need to.

-- 
                                                          - Warp

Post a reply to this message