Proposal for v3.0: Changing namespace from "cocos2d" to "cc"

cocos2d-x C++
#1

Hi all,
I’m James Chen, one of the maintainers of cocos2d-x. I have something to discuss with you guys about cocos2d-x 3.0.

After releasing the final version(2.1.4) of cocos2d-x 2.x, we are preparing cocos2d-x 3.0.
Ricardo Quesada * , the author of cocos2d-iphone, will spend his whole time in the development of cocos2d-x 3.0. I think cocos2d-x will be better and polished. :slight_smile: Thanks @Riq.
You could get the message in the thread.
To make Cocos2d-x better, there are lots of things need to be done.
But first of all, we need a more CPP friendly version of cocos2d-x.
As Riq’s suggestion, we need to removeCC* prefix in cocos2d-x classes and use as many as c++ patterns rather than Objective-C patterns, like copyWithZone which is Objective-C stuff will be deprecated.
I did agree!

Old way:

    using namespace cocos2d;      // ---- 1
    CCSprite* sp = CCSprite::create("filename.png");   // Since we are using the namespace of cocos2d, why do we need CC prefix?

New way:

    using namespace cocos2d;
    Sprite* sp = Sprite::create("filename.png");     // more concise

However, I also decide to change the namespace from “cocos2d” to “cc”.

It’ll be

    using namespace cc;
    Sprite* sp = Sprite::create("filename.png");

and when there are conflicts with other libraries, we could

   cc::Sprite* sp = cc::Sprite::create("filename.png");

Why?

It’s shorter and more compatible with JS, with objective-C, and with old version of cocos2d-x.
If not doing this, it’ll be:

   cocos2d::Sprite* sp = cocos2d::Sprite::create("filename.png");  // Namespace is too long.

What’re your opinions about removing the CC prefix and changing the namespace from cocos2d to cc ?

cocos2d-x v3.1-alpha1 released
#2

Excellent idea!
It is a real joy to see more objective-c style functions changed to cpp style, eg, ‘shared…’ change to ‘getInstance’.
And for me, the retain() and release() is the real nightmare!:slight_smile:

#3

I’m afraid manually retain(), release() will be still there in v3.0, while autorelease pull will be removed.

#4

This is a great idea. Are you going to rename the class files as well though (e.g., CCSprite.h to Sprite.h)? I’m only asking because there could be naming collisions between cocos2d and other libraries.

#5

Nick Verigakis wrote:

This is a great idea. Are you going to rename the class files as well though (e.g., CCSprite.h to Sprite.h)? I’m only asking because there could be naming collisions between cocos2d and other libraries.

No, we will not remove CC prefix of file name.

#6

I completely agree with removing the CC prefix because it was not needed in the first place as all Cocos2d-related stuffs live under the same namespace cocos2d. Name collision should not be an issue because when you mix cocos2d-x with another library with colliding names then you can easily avoid it by specifying the namespace instead of using namespace cocos2d;, which is actually the recommended way to use namespaces “in all your C*+ code“:http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Namespaces.
However, I somewhat disagree with renaming namespace from cocos2d to cc even when I see its advantages. The simplicity and convenience can be also achieved by”namespace alias“:http://msdn.microsoft.com/en-us/library/chwe1tc8(v=vs.80).aspx”feature of C**”:http://stackoverflow.com/a/1211402 and I personally think it is better to keep the namespace aliasing as an option to developers, instead of library providing it for them. I heavily use JS binding in my projects and I avoid using namespace XXX; in my C*+ code, so cc::Class will make my code simpler. But for more complex projects with lots of library dependencies, cocos2d gives more clarity than cc. The namespace cocos2d is clear and unique enough to avoid any namespace collision or confusion, and who knows someday some other derivative project like cocos3d may be ported to C++ and it’ll have a trouble picking its own namespace when cc is taken.

#7

Pilwon Huh wrote:

I completely agree with removing the CC prefix because it was not needed in the first place as all Cocos2d-related stuffs live under the same namespace cocos2d. Name collision should not be an issue because when you mix cocos2d-x with another library with colliding names then you can easily avoid it by specifying the namespace instead of using namespace cocos2d;, which is actually the recommended way to use namespaces “in all your C*+ code“:http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Namespaces.
>
However, I somewhat disagree with renaming namespace from cocos2d to cc even when I see its advantages. The simplicity and convenience can be also achieved by”namespace alias“:http://msdn.microsoft.com/en-us/library/chwe1tc8(v=vs.80).aspx”feature of C**”:http://stackoverflow.com/a/1211402 and I personally think it is better to keep the namespace aliasing as an option to developers, instead of library providing it for them. I heavily use JS binding in my projects and I avoid using namespace XXX; in my C*+ code, so cc::Class will make my code simpler. But for more complex projects with lots of library dependencies, cocos2d gives more clarity than cc. The namespace cocos2d is clear and unique enough to avoid any namespace collision or confusion, and who knows someday some other derivative project like cocos3d may be ported to C++ and it’ll have a trouble picking its own namespace when cc is taken.

good point. We could use namespace aliasing for that. I agree with you that `cocos2d` is more descriptive. While `cc` is shorter, and possibly easier for developers, it could also lead to confusion.
Perhaps keep using `cocos2d` is a good idea, a developers could use `cc` as a namespace alias.

namespaces in other engines:
GamePlay uses the `gameplay` namespace
Ogre3D uses the `Ogre` namespace

#8

Changjun Shuai wrote:

Excellent idea!
It is a real joy to see more objective-c style functions changed to cpp style, eg, ‘shared…’ change to getInstance

yep. getInstance looks more C*+ friendly.

And for me, the retain and release is the real nightmare!:slight_smile:
So we discussed a lot of the benefits of using our own Reference counting , or using the c**11 smart pointers.
Own ref counting:
: faster, not sure by how much, but a bit faster
: backward compatible. The API will be the same
: incompatible with STL containers
smart pointers:
: compatible with STL containers
: more C*+ friendly
[]: slower
: API needs to change.
eg:
<pre>
// v2.1
CCSprite sprite = CCSprite::create;
// v3.0 with own ref counting
Spritesprite = Sprite::create;
// v3.0 with smart pointers
std::shared_ptr<Sprite*> sprite = Sprite::create;
// of course we could use ‘auto’, and the API will be the same
auto sprite = Sprite::create;
// by using smart pointers, I could use the STL contianers
vector.append;
// by using our own ref counting I should use our own data structures
dictionary>setObject(“key”, sprite);

// but I also could use a custom shared_point for our objects.
cc_shared_ptr shared_sprite(sprite);
vector.append(shared_sprite);

I think using our own ref counting is faster (something important on a game engine), and easier to understand… but I do not discard shared\_pointers yet. I want to do more research.
#9

More on shared_ptr vs own ref counting.

// with shared_ptr
class MyClass {
  std::shared_ptr _sprite;
};
void MyClass::saveSprite( std::shared_ptr sprite )
{
  _sprite = sprite;
}
~MyClass()
{
  // nothing
}

// with own ref counting
class MyClass {
  Sprite* _sprite;
};
void MyClass::saveSprite( Sprite *sprite )
{
  _sprite = sprite->retain();
}
~MyClass()
{
  _sprite->release();
}

So, I think the code is more readable/maintainable, (and also faster) with “own ref counting”.

#10

I never use “using namespace Xxx” in my code. cocos2d::Sprite is good enough to identify the class.
Is it better to discuss another suggestions/ideas in a new thread? maybe with a poll

#11

I also think namespace alias will be the best solution. Thanks.

Pilwon Huh wrote:

I completely agree with removing the CC prefix because it was not needed in the first place as all Cocos2d-related stuffs live under the same namespace cocos2d. Name collision should not be an issue because when you mix cocos2d-x with another library with colliding names then you can easily avoid it by specifying the namespace instead of using namespace cocos2d;, which is actually the recommended way to use namespaces “in all your C*+ code“:http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Namespaces.
>
However, I somewhat disagree with renaming namespace from cocos2d to cc even when I see its advantages. The simplicity and convenience can be also achieved by”namespace alias“:http://msdn.microsoft.com/en-us/library/chwe1tc8(v=vs.80).aspx”feature of C**”:http://stackoverflow.com/a/1211402 and I personally think it is better to keep the namespace aliasing as an option to developers, instead of library providing it for them. I heavily use JS binding in my projects and I avoid using namespace XXX; in my C*+ code, so cc::Class will make my code simpler. But for more complex projects with lots of library dependencies, cocos2d gives more clarity than cc. The namespace cocos2d is clear and unique enough to avoid any namespace collision or confusion, and who knows someday some other derivative project like cocos3d may be ported to C++ and it’ll have a trouble picking its own namespace when cc is taken.

#12

My opinion:
# namespace cocos2d {}; #define cc cocos2d
# use manual retain/release like gameplay.
# add our implementation of:
#* cc::SharedPtr https://github.com/cocos2d/cocos2d-x/pull/2542
#* cc::WeakPtr https://github.com/cocos2d/cocos2d-x/pull/2481 This implementation of weak ptr is very expensive.

#13

Zhe Wang wrote:

My opinion:
# namespace cocos2d {}; #define cc cocos2d

yes, but without the #define :slight_smile: I guess it should be:
namespace cc = cocos2d;

#14

Ricardo Quesada wrote:

yes, but without the #define :slight_smile: I guess it should be:
namespace cc = cocos2d;

Great.

And how about
* cc::Ref
* cc::WeakRef, only used in dispatchers
* cc::SharedRef, only used in STL containers
Then users won’t be confused on try using std::shared_ptr APIs on cc::shared_ptr class.
Since we only operate cc::Ref in WeakRef & SharedRef, it will NO using c++ templates in WeakRef & SharedRef.

#15

And for me, the retain() and release() is the real nightmare!
I use boost::intrusive_ptr for such stuff.
Like this:
boost::intrusive_ptr<Sprite> m_sprite

I think, removing retain and release maybe painful for existing code.

#16

That new naming would be a great improvement!

I’d also like to see the using macros removed and add a NS_CC macro that only defines its name. Code would be like:
namespace NS_CC { /*code here*/ }
NS_CC::Sprite* spritePointer;
using namespace NS_CC;

See more here: http://www.cocos2d-x.org/boards/6/topics/28785?r=28915

CCArray could also be implemented in terms of std::vector, like CCSet. And could be iterated in the C++11 way.
CCArray is not copiable, while std::vector is. Implementing it in terms of std::vector should make it easy to support copiability.

#17

For what it’s worth, I think removing the CC prefix is fine (although not really needed), but changing the namespace from cocos2d to cc is needlessly confusing. I think the trade off between typing a few extra characters is worth it for the increased readability for newbies to the library.

I’m glad to hear that the retain/release stuff is staying for 3.x. I think it’s a really nice way to manage memory.

Ben

#18
  1. Please remove CC prefixes
  2. Please do not change cocos2d to cc. It’s nice to have an explicit name space. cc is too short and not really descriptive. If you go cc, why not go c2d or something.
#19

Zhe Wang wrote:

My opinion:
# namespace cocos2d {}; #define cc cocos2d
# use manual retain/release like gameplay.
# add our implementation of:
#* cc::SharedPtr https://github.com/cocos2d/cocos2d-x/pull/2542
#* cc::WeakPtr https://github.com/cocos2d/cocos2d-x/pull/2481 This implementation of weak ptr is very expensive.

Why roll your own stuff. Why not std:: or boost:: ?

#20

CC prefix and cocos2d namespace denote the same thing, omitting CC looks quite logical. And two letter prefix is an ObjC convention if I’m not mistaken. With namespace aliases one can choose the appearance: cocos2d::Sprite, cc::Sprite, CC::Sprite or simply Sprite - and that’s cool.

As for using manual retain/release - in my projects I almost never release and retain manually, the only exception is CCArrays. I think STL containers and easy-to-get thread safety is important, so I vote for shared_ptrs. And for real speed tests we need two game prototypes - one with manual retain/release and another with shared_ptrs, the speed difference between these two approaches may turn out to be vanishingly small compared to other things like game logic related calculations.