>> In a similar vein, today I tried giving a variable the same name as a
>> class. VS didn't care; it compiled and ran my code just fine. GCC gave
>> me an utterly baffling error message which took me some considerable
>> while to figure out. Renaming the variable made it happy again.
>
> I suppose I'd have to see an actual example to give an informed opinion.

   struct Side
   {
     Pattern & Pattern;
     Pattern::iterator Iterator;
   }

The error message was something like "cannot change meaning of 'class 
Pattern' to 'Pattern'" or something equally cryptic. Renaming the first 
field fixed the problem.

>> Not that VS is perfect, of course. Yesterday it gave me the dreaded
>> C2512 error: "no appropriate default constructor available".
>
> Again, I'd have to see an actual example...

   struct Side
   {
     Pattern & Pattern;
     Pattern::iterator & Iterator;
   }

   struct State
   {
     Side & LeftSide;
     Side & RightSide;
     std::stringstream Buffer;
     bool Success;
   }

Every single line that declares a State variable gives me C2512. As you 
can see, I clearly *have not* defined any constructors, so that isn't 
the reason for a default constructor not existing.

>> Speaking of which... I think I may be fundamentally misunderstanding
>> what references actually *do*. I had thought they were like pointers,
>> just that you can't make them null. But some sources claim they're like
>> pointers who's value can never change. So what, pray tell, does the
>> following do?
>
>>     std::vectpr<int>  foo;
>>     std::vector<int>  bar;
>>     std::vector<int>  &  baz = foo;
>>     baz = bar;
>
>> I had imagined that the final line changes baz from pointing to foo and
>> to instead point to bar. But... if a reference can never change... then
>> what the hell am I changing?? O_O
>
> "A reference can never change" means that you can't make it point to some
> other object after initialization. It doesn't mean you can't change
> whatever it's referencing.
>
> In the above example "baz = bar;" is doing the exact same thing as
> "foo = bar;" (because 'baz' is an "alias" to 'foo' via the fact that
> it's a reference to it.) In other words, you are assigning the 'bar'
> object to the 'foo' object by value (via the 'baz' reference.)

So what you're saying is, a reference is a pointer where you can't ever 
change the *address* it points to, but you can change what's *at* that 
address?

Does that also mean that assigning one vector to another actually 
*copies* the entire vector? As in, a deep copy??

>> It's times like these that make me want to step away from the keyboard
>> and go for a walk outside for a while. This stuff is just too
>> complicated to be left to mere mortals. It should only be touched by
>> people with a PhD in the official language spec.
>
> I don't think it's that hard. A reference is basically an "alias" to
> whatever it's referring to. Whatever you are doing to the reference
> you are doing to the original.

I didn't mean references specifically. I just meant the entire language. 
Nobody would try to claim that C++ is small or simple or free of 
surprises. For example,

    struct Side
    {
      Pattern & ThePattern;
      Side(Pattern p) : ThePattern(p) {}
    }

Guess what? This segfaults when I run it. *You* probably see the problem 
immediately, but it took me 24 hours to figure out that there's a single 
missing character there...

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. The time before that, it was a memory leak due to an (empty) 
destructor not being virtual. There's so many buts and gotchas. And 
they're not the sort of thing where your program gives you the wrong 
answer; they're the sort of thing where you have a native crash and 
you're left utterly bewildered as to how the *hell* to discover what the 
problem was...

Post a reply to this message