try to stump me on C++

Quote:

---

Originally Posted by aljodav

Maybe, you don't like me but ... ;) .

---

Stay in line.

Quote:

---

Originally Posted by Ejaz

Stay in line.

---

I'm sorry, I should know ***********************? OMG, I'm definitely OFF THIS LINE!

Quote:

---

Originally Posted by aljodav

I'm sorry, I should know ************************** OMG, I'm definitely OFF THIS LINE!

---

No need to be sorry, I'm putting you to the place where you belong.

How do handle agression in interviews! Great derail! Discuss!! :D :thumb:

Quote:

---

Originally Posted by Zaccheus

How do handle agression in interviews! Great derail! Discuss!! :D :thumb:

---

Actually, handling agression can definately be a part of a job interview. Especially if you are going to be in a client (internal or external) facing role.

I have been on both sides (interviewee and interviewer) where "role playing" involved dealing with a very angry "customer".

Interviewing tech people for their "soft" skills is becoming more and more common.

Quote:

---

Originally Posted by Zaccheus

Mitsukai, I was talking about the following technique:

Code:

---

MyClass& MyClass::operator=(const MyClass& other)
{
  // use copy constructor to create a copy.
  // If an exception happens, then 'this will remain unchanged.
  MyClass temp(other); 

  // Use a member function called swap to exchange the internal representations of 'this' and temp, just like std::vector<T>::swap does.
  swap(temp);  // Cannot throw exceptions!

  return *this;
}

---

---

Ok, I can't resist the temptation to enliven the discussion about this technique for implementing the assignment operator.

Exception safe though it may be, IMHO it can be brutally inefficient. Not because of the call to swap() (that can usually be implemented very efficiently), but because creating the temporary object can force memory allocation that would in many cases be unnecessary for the assignment.

Just think, for example, if std::vector or std::string's assignment operators were implemented in this way. Normally, so long as the size of the RHS vector/string does not exceed the capacity of the LHS vector/string, no reallocation is necessary for the assignment. If implemented using this technique, however, then a new piece of memory would be allocated on every assignment, and an old one thrown away: that's an unnecessary call to each of new[] and delete[] on every assignment. Considering how expensive memory allocation can be, I'd advise caution when choosing to use this technique.

Feel free to disagree, this is just my two cents. :)

Quote:

---

Originally Posted by HighCommander4

Feel free to disagree, this is just my two cents. :)

---

Glad to. :D :D

For the mjority of objects, the guarantee that the state will always be 100% consistant overrides the memory concerns and even the time concerns.

If the object happens to be large, then implementing the "bulk" as an independant object eliminates this situation.

About the only place I would agree with your concerns is on (very small) embedded systems.

Quote:

---

Originally Posted by TheCPUWizard

If the object happens to be large, then implementing the "bulk" as an independant object eliminates this situation.

---

Out of curiosity, how so?

Quote:

---

Originally Posted by HighCommander4

Out of curiosity, how so?

---

Very Over Simplified

Code:

---

class Bulky
{
  private:
    BigData *m_Bulk;
    static bool s_SuppressBulk;
  public:
    Bulky(Bulky const &src)
    {
        if (!s_SuppressBulk)
            m_Bulk = src.m_Bulk;
    }
    Bulky operator =(Bulky const &src)
    {
          s_SuppressBulk = true;
        Bulky  temp(src);
          s_SuppressBulk = false;
          Swap(temp);
          return *this;
    }
}

---

Quote:

---

Originally Posted by TheCPUWizard

Very Over Simplified

Code:

---

class Bulky
{
  private:
    BigData *m_Bulk;
    static bool s_SuppressBulk;
  public:
    Bulky(Bulky const &src)
    {
        if (!s_SuppressBulk)
            m_Bulk = src.m_Bulk;
    }
    Bulky operator =(Bulky const &src)
    {
          s_SuppressBulk = true;
        Bulky  temp(src);
          s_SuppressBulk = false;
          Swap(temp);
          return *this;
    }
}

---

---

:eek:

But, assuming that all Swap() does is swap pointers, then this is now a shallow copy...

Am I missing something?

EDIT: Wait a minute, I misread your code. As it stands now, no copying is done at all! temp's m_Bulk will be uninitialized, and when Swap() is called, the LHS object will end up with an uninitialized m_Bulk member!

Quote:

---

Originally Posted by HighCommander4

:eek:

But, assuming that all Swap() does is swap pointers, then this is now a shallow copy...

Am I missing something?

---

The code is actually missing quite a bit, and was merely intended to illustrate a means where the "cost" of creation of the temporary has been measured to cause a significant application level overhead.

In the 10+ years that Ihave used exception safe assignment, I have had to implement a solution based on the above concept exactly twice. And in one of those cases the code was re-factored within weeks (during the next sprint) to eliminate the need by refining the object model.

Quote:

---

Originally Posted by TheCPUWizard

Very Over Simplified

Code:

---

class Bulky
{
  private:
    BigData *m_Bulk;
    static bool s_SuppressBulk;
  public:
    Bulky(Bulky const &src)
    {
        if (!s_SuppressBulk)
            m_Bulk = src.m_Bulk;
    }
    Bulky operator =(Bulky const &src)
    {
          s_SuppressBulk = true;
        Bulky  temp(src);
          s_SuppressBulk = false;
          Swap(temp);
          return *this;
    }
}

---

---

I'm afraid this over-simplification makes the point unclear. If s_SuppressBulk is true, then the copy constructor is basically a no-op and m_Bulk is left uinitialized. If s_SuppressBulk is false then the copy constructor performs a shallow copy. Are there other key statements being omitted from your implementation of the copy constructor and assignment operator? Can you elaborate on them? Otherwise I cannot imagine any definition for BigData and Swap that would make this code function correctly.

I would also also create a separate, private constructor rather than use a static flag to alter the behavior of the regular copy constructor. The static variable thing is a bit ugly and makes thread-safety more difficult than it has to be.

Quote:

---

Originally Posted by Zaccheus

"Is it at all possible to create a local function inside a function in C++? If so, how?"

---

Yes. You create a local

Code:

---

struct/class

---

, and override

Code:

---

operator()

---

.

Why would you want to do this:
'Local' gives you encapsulation. If you modify the 'local function', you only have to re-test the encapsulating function.

Just my two bits,
Pablo.

Quote:

---

Originally Posted by HighCommander4

Just think, for example, if std::vector or std::string's assignment operators were implemented in this way. Normally, so long as the size of the RHS vector/string does not exceed the capacity of the LHS vector/string, no reallocation is necessary for the assignment. If implemented using this technique, however, then a new piece of memory would be allocated on every assignment, and an old one thrown away: that's an unnecessary call to each of new[] and delete[] on every assignment. Considering how expensive memory allocation can be, I'd advise caution when choosing to use this technique.

---

That's a very good point, one of many special cases where the copy/swap technique can be improved upon. For the bulk of classes, though, I think the copy/swap technique is a good default option.

Lots of thing to learn here! A very good thread ( except aljodav's posts :P )

Well, how about this one?

Suppose we have a template class

Code:

---

template <unsigned long N>
class Something
{
        typedef ...... unsigned_type_according_to_n;
};

---

The question is : Make "unsigned_type_according_to_n" to be
- unsigned char, if 0 <= N < 256
- unsigned short, if 256 <= N < 65536
- unsigned long, if 65536 <= N

Sorry if too easy ^_^