The C/C++ 'Did You Know?' Thread

Started by
144 comments, last by graveyard filla 19 years, 4 months ago
I thought it would be a nice idea to start a thread where us programmers can simply write true 'Did You Know?'s about the more intermediated and advanced aspects of C/C++. Stuff that others may not know, and would help with their programming. Here's mine: Did you know that when corperations and companies write library files for their own APIs etc, they surround their classes with a namespace with the name of their company URL, but backwards. For example: Supposing two companies wrote their own versions of the bubble sort and for whatever reason another company wanted to include both of the libraries that this bubble sort was part of, into their own project. Supposing both companies called their bubble sort classes 'bSort', there would be compilation and linking errors. So what they do is this:

namespace COM_COMPANYA_WWW
{
   class bSort
   {
      ...
   }
}

namespace COM_COMPANYB_WWW
{
   class bSort
   {
      ...
   }
}

Also placing the same namespace around the methods in the CPP file. Obviously this works since all URLs are unique. This ensure a far higher likeliness of compilation and also if for whatever reason they still happened to be the same, u can simply change the name of the namespace slightly. If you have any 'Did You Know?'s please post them! :) ace
Advertisement
Ddi you know that your "Did You Know" has its origins in Java's package nomenclature guidelines?
class B{public:    int iPublic;protected:    int iProtected;};class A : public B{    void usePublic( B* p )        { p->iPublic = 1; }     // fine, A can access B's public members    void useProtectedA( A* p )        { p->iProtected = 1; }  // fine, A can access B's protected members    void useProtectedB( B* p )        { p->iProtected = 1; }  // oops!  but only through a pointer to A...};


...or a reference to or object of A. That one threw me when I first ran into it, since it seemed so counter-intuitive. I must admit, I still do not understand the reasoning behind this rule.
Didya know that your "Did You Know" guideline is the ugliest freaking use of namespaces ever? My company certainly doesn't do that. Actually the C++ used by many companies is circa-1995 oftentimes.

My personal did you know:
Visual Assist X sucks. Badly.
--God has paid us the intolerable compliment of loving us, in the deepest, most tragic, most inexorable sense.- C.S. Lewis
Well i was told my Did You Know by a professional so ill go with it. makes perfect sense to me.
For what it's worth, I think it looks ugly.

namespace Company {    namespace Product {        namespace Module {        }    }}


[Edited by - petewood on November 21, 2004 4:38:50 PM]
Where in the hell did i say about 3 namespaces? 1 is enough
I'm a professional as well and have worked at a number of game companies and have never seen or heard of this zany backwards URL thing. The namespace scheme petewood showed is much more reasonable. But, I like the idea of your thread. So, instead of just bagging on your namespace scheme, I'll try to add something useful :)

Did you know that when you overload operator=, you should make sure that you handle self assignment correctly? Otherwise you can run into some REALLY hard to track down bugs. This page explains all the details:

Self assignment

-John
- John
Quote:Original post by LastUnicron
I must admit, I still do not understand the reasoning behind this rule.


class A
{
};

Any function of class A can access any other instances of class A within itself. It makes sense because A should always have access to its own data, even if its within another instance of the class.

When you pass in a B* and try to access it's private/protected data you don't know that its an instance of class A. You could have a third class D that is derived from B. And done B* = new D; and then pass it into the function as a pointer to B, if the function was allowed to change it, it would break encapsulation by allowing class A to modify class D's member variables.

so

class A : public B{    void useProtectedB( B* p )        { p->iProtected = 1; }  // Am I class A instance, or class D instance, or class B instance?};


Hope that makes it clear.
Quote:Original post by ph33r
Hope that makes it clear.


Ok, it makes perfect sense when you bring in D. I had been focusing on the interaction between B and A. Thanks!

This topic is closed to new replies.

Advertisement