cocos2dx3.10 TiledMap超大显示

891次浏览

cocos2dx支持TiledMap的加载和显示,挺方便的。不过方便之余也有诸多的限制,如一个图集不能放在两个层上,还有就是当格子数超过一定数量时就不显示了。

图集问题就不说了,做的时候小心一点就可以了。下面来说说超大地格的显示问题。基本思路是当地图移动的时候,重新计算层的VBO。具体代码请下载查看,这里就不贴了。

以下是应用示例:

1
2
3
4
5
6
7
8
9
10
auto tiledMap = tmx::EasyTMXTiledMap::create("map.tmx");
tiledMap->setAnchorPoint(Vec2(0.5, 0.5));
tiledMap->setPosition(tiledMap->getContentSize() * 0.5);
auto scroll = cocos2d::ui::ScrollView::create();
scroll->setContentSize(getContentSize());
scroll->setInnerContainerSize(tiledMap->getContentSize());
scroll->setDirection(cocos2d::ui::ScrollView::Direction::BOTH);
scroll->addChild(tiledMap);
scroll->jumpToPercentBothDirection(Vec2(50, 50));
addChild(scroll);

代码下载:
EasyTXMTiledMap.zip

面向对象是个骗局?!

1800次浏览

网上有一篇文章《Object Orientation Isa Hoax》——面向对象是一个骗局,标题很有煽动性。其中收集一些关于“面向对象的反动言论”,很多言论竟出自众多大师之口。酷壳个人网站版主陈皓对这些言论发表了一篇博文,对其中一些大师的对话摘录下来并对他们做了翻译。现把全文转载于此。全文如下:

今天在网上看到网页叫“Object Orientation Isa Hoax”——面向对象是一个骗局,标题很有煽动性(注:该网站上还有一个网页叫Object Orientation Is Dead),好吧,打开看看上面有些什么,发现这个网页是在收集一些关于“面向对象的反动言论”,没想到的是,很多言论出自很多大师之口。比如:Alexander Stepanov和Bjarne Stroustrup。这些言论挺有意思的,所以,我摘两段在下面:

第一段是Alexander Stepanov的(不要告诉我你不知道这个人,STL之父,关于他的故事,可以到这里看看)。他N年前作过一段采访,原文在这里(我非常建议大家去读一下这篇采访,相当过瘾),译文在这里(不过有地方把原意都译反了,我重译了一下),其中有一个问答被上述的那个面向对象反动言论的网页收录了:


Question:

28_100929092635_1I think STL and Generic Programming mark a definite departure from the common C++ programming style, which I find is almost completely derived from SmallTalk. Do you agree?

提问:

我认为STL和泛型编程标志着非同一般的C++编程风格,而这种风格几乎完全是从SmallTalk派生过来的。你同意吗?

Answer:

Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. In a sense, I am unfair to AI: I learned a lot of stuff from the MIT AI Lab crowd, they have done some really fundamental work: Bill Gosper’s Hakmem is one of the best things for a programmer to read. AI might not have had a serious foundation, but it produced Gosper and Stallman (Emacs), Moses (Macsyma) and Sussman (Scheme, together with Guy Steele). I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras – families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting – saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms – you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.

回答:

是的。STL不是面向对象的。我认为面向对象和人工智能差不多,都是个骗局。我至今仍然没有从那些OO编程的人那里看到一丁点有意思的代码。从某种意义上来说,我这么说对人工智能(AI)并不公平:因为我听说过很多MIT(麻省理工大) AI实验室里一帮人搞出来的东西,而且他们的确直正干了一些基础性的工作:Bill Gosper的Hakmem是程序员最好的读物之一。AI或许没有一个实实在在的基础,但它造就了Gosper和Stallman(Emacs), Moses(Macsyma)和Sussman(Scheme, 和Guy Steele一起)。

我发现OOP在技术上是荒谬的,它企图把世界解构成不同的单一类型的接口,为了处理实际问题,你需要多种代数方法——横跨多种类型的接口族;

我发现OOP在哲学上是荒谬的,它声称一切都是对象。即使这是真的也不是很有趣——因为说一切都是对象跟什么都没说一样;

我发现OOP的方法论是错误的,它从类开始,就好像数学要从公理开始一样。你不从公理开始,你就要从证明开始。直到你找到了一大堆相关证据后你才能归纳出公理,然后以公理结束。在程序设计方面存在着同样的事实:你要从有趣的算法开始。只有很好地理解了算法,你才有可能提炼出接口以让其工作。


下面,我们再来看C++的发明者Bjarne Stroustrup,在1998年IEEE采访时的一段话(全篇见这里),下面是其中的几段话:(我的翻译如下)

28_100929092934_1So what is OO? Certainly not every good program is object-oriented, and not every object-oriented program is good. If this were so, “object-oriented” would simply be a synonym for “good,” and the concept would be a vacuous buzzword of little help when you need to make practical decisions. I tend to equate OOP with heavy use of class hierarchies and virtual functions (called methods in some languages). This definition is historically accurate because class hierarchies and virtual functions together with their accompanying design philosophy were what distinguished Simula from the other languages of its time. In fact, it is this aspect of Simula’s legacy that Smalltalk has most heavily emphasized.

那么,什么是OO面向对象?当然,不会是所有的程序都是面向对象的,而且,也不是所有的面向对象程序就是好的。如果面向对象是好的,那么“Object-Oriented”应该成为“Good”的同义词,并且,OO概念只会成为一个假大空的口号,在你需要做出实际决定时只可能帮你那么一丁点。我倾向于把OOP等价于大量使用继承类和虚函数(某些语言的调用方法)。从历史上来说,这个定义是精确的,因为,在那个时候,只有类的继承和虚函数一起存在的设计哲学,才能把Simula和其它语言分别开来。事实上,Smalltalk相当地强调着这种Simula的遗留问题。

Defining OO as based on the use of class hierarchies and virtual functions is also practical in that it provides some guidance as to where OO is likely to be successful. You look for concepts that have a hierarchical ordering, for variants of a concept that can share an implementation, and for objects that can be manipulated through a common interface without being of exactly the same type. Given a few examples and a bit of experience, this can be the basis for a very powerful approach to design.

用继承类和虚函数来定义OO在实际上可以让很多OO指导性的东西更能成功一些。在解决问题时,寻找的那些有层级次序的对象,以应对不同对象也可以重用同一个实现,并且对象可以被某个共同的接口来操作而不需要完全相同的类型。在你了解了一些示例和拥有了一些经验后,OO可以成为Design的一个强有力的基础。

However, not every concept naturally and usefully fits into a hierarchy, not every relationship among concepts is hierarchical, and not every problem is best approached with a primary focus on objects. For example, some problems really are primarily algorithmic. Consequently, a general-purpose programming language should support a variety of ways of thinking and a variety of programming styles. This variety results from the diversity of problems to be solved and the many ways of solving them. C++ supports a variety of programming styles and is therefore more appropriately called a multiparadigm, rather than an object-oriented, language (assuming you need a fancy label).

然后,并不是每一个对象都自然地有效地适合继承,并不是每一个对象间的关系都是继承,也并不是每一个问题的最佳解决途径需要主要地通过对象。例如,很多问题主要是算法问题(译注:如业务逻辑,数据流等)。我们知道,一个一般性的编程语言都应该有能力支持不同的思路和不同的编程风格。这样,对于问题的多样性,我们可以使用许许多多不同的的方法去解决他们,这就产生了很多的不同解法。C++支持编程风格的多样性,因此,C++叫做“多范式  multi-paradigm”会更合适一些,而不是一个面向对象语言。

我个人在看过这些言论后,我先不管“面向对象是不是一个骗局”,不过从某种角度上来看的确是有些问题的,C++、OO、XML、SOA、网格计算等等诸如此类的东西的确被挂上了神圣的光坏。这些东西出来的时候总是只有一种赞美的声音。无论好坏,只有一种声音总是令人恐怖的,无论好坏,有不同的声音总是好的,每当这个社会或是我们的IT界大张旗鼓地鼓吹或是信仰某些东西,却没有任何一点不同意见的时候,我就会感到一种莫名的恐慌。我知道,这是我们从小受到的那种“非黑即白”的价值观教育所致,事物要么全是好的,要么全是不好的。其实任何事物都是有好有不好的,C++,敏捷开发,CMMi,OO,设计模式,重构,等等等等,他们都有好的也有不好的,关键看你怎么来使用。这个世界只有适合不适合的东西,不会出现放之四海皆准的东西,也不可能出现一种可以解决所有问题的东西,如果有,那么这种东西必然是一种宗教性质的用来洗脑的东西。

所以,每当在我身边看到或听到那些只有一种声音有如“电视购物”或是“新闻联播”之类的宣传或是鼓动的时候,我就感到很一种莫名的反感…… 不多说了,还是交给大家来评价吧。我仅以此篇文章献给那些OO-Oriented,Design Pattern-Oriented,Agile-Oriented,Process-Oriented,等等有着宗教信仰一般的人和事。

 

原文链接:http://coolshell.cn/articles/3036.html#more-3036

c/c++中关于struct内存对齐问题

718次浏览

题:

struct st1{                                       struct st2{
          int i;                                                 char c;
          char c;                                             int i;
          short s;                                            short s;
       };                                                   };

上述两结构体在内存中占用字节是多少,即sizeof(struct st1)=?, sizeof(struct st2)=?
解:8, 12

思考:这是struct结构的内存对齐问题,结构体的内存布局依赖于CPU、操作系统、编译器及编译时的对齐选项。其主要有:

1)结构体内部成员对齐
对于结构体内部成员,通常会有这样的规定:各成员变量存放的起始地址相对于结构的起始地址的偏移量必须为该变量的类型所占用的字节数的倍数。但是也可以看到,有时候某些字段如果严格按照大小紧密排列,根本无法达到这样的目的,因此有时候必须进行padding。各成员变量在存放的时候根据在结构中出现的顺序依次申请空间,同时按照上面的对齐方式调 整位置,空缺的字节编译器会自动填充也就是padding。如下图所示:

662029145240471388

图中st1,第一个为int型,占用4个字节,第二个为char型,其偏移量为4,char所占的字节数为1,则偏移量是其占用字节数的倍数,则仅列其后,第三个为short型,占用字节数为2,前面已有字节为5,不是2的倍数,所以char后面padding一个字节,使得short的其实地址为6,所以对齐后,共占用8个字节。同理可得str2占用12个字节

2)结构体之间对齐(此并不是考虑结构体内部的对齐,而是一组结构体的对齐,在计算单个结构体占用字节时并不考虑)

考虑整个结构体的对齐需求。ANSI C标准规定结构体类型的对齐要求不能比它所有字段中要求最严格的那个宽松,可以更严格。实际上要求结构体至少是其中的那个最大的元素大小的整数倍。因为有时候我们使用的是结构体数组,所以结构体的大小还得保证结构体数组中各个结构体满足对齐要求,同时独立的结构体与结构体数组中单个结构体的大小应当是一致的。


每个特定平台上的编译器都有自己的默认“对齐系数”(也叫对齐模数32位机上是8)。程序员可以通过预编
译命令#pragma pack(n),n=1,2,4,8,16 来改变这一系数,其中的n 就是你要指定的“对齐系数”。

指定对齐:
一般的,可以通过下面的方法来改变缺省的对齐条件:
使用伪指令#pragma pack(n),编译器将按照n个字节对齐;
使用伪指令#pragma pack(),取消自定义的字节对齐方式;
注意:如果#pragma pack(n)中指定的n大于结构体中最大的成员的size,则其不起作用,结构体仍然按照size最大的成员进行对齐。

c/c++ struct按位分配成员

204次浏览

一个普通的c/c++中的struct如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
struct A
{
int d1;
int d2;
int d3;
int d4;
bool b1;
bool b2;
bool b3;
bool b4;
bool b5;
bool b6;
bool b7;
bool b8;
};

如果这里有一个大数组,如100万个A结构数组,肯定会想节省内存的。数据结构在固定的时候,还有什么办法吗?当然有了,就是按位分配成员。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
struct A
{
int d1;
int d2;
int d3;
int d4;
bool b1:1;
bool b2:1;
bool b3:1;
bool b4:1;
bool b5:1;
bool b6:1;
bool b7:1;
bool b8:1;
};

在成员名后面添加冒号和数字,就代表这个成员占用多少bit位。这样原来的一个bool是占一个字节8bit位的,现在就只占了1bit位了,而8个bool才占一个字节,是不是节省了N多内存了呢。
bool完全可以这么做的原因,是因为bool只有两个值true(1)、false(0),一个bit位完全可以表示并不失真。当然,任意类型在语法上都是可以这么指定位的。如d1、d2你明显知道取值是在0-1000以内,用short都太浪费,用char又不足。那么就可以分配11个bit位(高位符号位,也可以用unsigned d1:10),以次类推。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
struct A
{
int d1:11;
int d2:11;
int d3;
int d4;
bool b1:1;
bool b2:1;
bool b3:1;
bool b4:1;
bool b5:1;
bool b6:1;
bool b7:1;
bool b8:1;
};

这么做优点很明显了,节省内存,尤其是在大数组的情况下,可以节省很多。唯一不确定的是,大家都知道有一个struct内存对齐的东东。

亲有疾,药先尝;昼夜侍,不离床

623次浏览

亲有疾,药先尝;昼夜侍,不离床。简单的说就是父母亲病了,吃的药要自己先尝,看看是不是太苦、太烫;父母亲病倒在床上,要日夜护理,不离开他们的身边。

一开始没有太在意,可在儿子病后,深有感受。每次医生开的新药,都要尝一尝,是苦是甜。苦了有多苦,儿子会不会吃,吃后有什么反应。甜了是不是正常的甜,会不会有怪味(一般会有点甜中带苦,或带麻,薄荷味)。然后有什么反应,吃下去会不会吃第二口。为了让他顺利的喝下去,每次都像花了很多心思。更多的时候是要自己先喝一点,引他喝。跟他说爸爸喝一口,你喝一口,或者不让你喝了什么的,引起他的逆反心理来喝。喝一口后说真好喝,真棒等刺激他继教喝。直到把药喝完或者喝一些浪费一些,心总算落下来了。

让我想到,在我小的时候,父母是不是也是同样的照顾我们呢?亲有疾,药先尝;昼夜侍,不离床。64af63cd83ee47e2b07aacf096b7de54

夫妻间要多赞美

828次浏览

有一个可怕的逻辑,常见于失败的夫妻关系之中:由于对方的某种原因,以至于我受到某些影响,所以我们夫妻经常闹矛盾。夫妻之间,几乎无一例外都会吐槽伴侣哪里不够好,哪里做错了,并坚信对方是问题的始作俑者。用这样的逻辑思考婚姻问题,大有一种责任在对方,我做什么都是徒劳的态度,最后导致对经营婚姻失去耐心,甚至破罐子破摔。

其实,夫妻是一个整体,婚姻问题一个巴掌拍不响,双方都要负责任。如果双方都有意识地做一些事情来改善关系,那对婚姻关系的维护、夫妻二人的幸福都是大有益处的。

日常生活中,或产生矛盾后,夫妻双方要避免相互吐槽,学会自省并解决问题。指责、挖苦、嘲讽对方,只会激化矛盾,有时骂得过分了,甚至破镜难重圆。所以,不要轻易责备对方,多进行自我反省。当我们开始反思“我能做些什么”,而不是一味要求对方怎么做的时候,关系的改善就出现契机。记得多发现对方的优点,并学会赞美。婚姻就意味着相互依赖、相互付出,付出多了总会累。别以为伴侣的好记在心里就行,你不说出来没人知道。一句暖心而真诚的赞美能让对方感觉到自己的付出得到肯定,就像打了鸡血,再苦再累都值得。请记住在重大节日犒劳你的伴侣。情人节、结婚纪念日、生日,很多老夫老妻都已不再重视。婚后生活总会归于平淡,柴米油盐的计较里,慢慢就让彼此忘了爱的初心。其实每年就那么几个重要节日,利用它作为犒劳彼此的机会,平时的不愉快也许在欢乐的日子里被淡忘。节日,就像漫漫婚姻路里的小驿站,短暂休憩之后又可以继续前行。

总之,用心去爱你的另一半,用生活的细节去滋养爱情,别让生活的细节打败了爱情。

宝宝咳嗽好几天了

1260次浏览

宝宝略有点咳嗽,平均1-2小时间咳一次,一次咳几下。晚上发烧了,吃了点退烧的药,晚上也没反复。

早上,带他去儿童中心医院,人好多排队等待。总之还行,下午2点看上了,开了药。结果回家一样药都不吃,唉~虽然药都带甜味的。

第二天强灌一次,结果吐了,再也不敢强喂了。咳嗽有点加重了,饭也不好好吃了。

第三天早上起来喝了几大口昨晚的凉水,咳嗽的更厉害,饭基本一天吃几口的样子。

赶紧去医院,换了个小医院,打了点滴,晚上好了点。第二天早上起来又咳的厉害,继续打点滴,晚上好多了,做了儿童面条,吃了小半碗,心里踏实些。但同时也担心第二天咳嗽又加重。晚上咳醒几次,好像有痰,咳出来又咽下去,自己恶心的想吐,又吐不出来,难受!

早上起来,又跟晚上一样,咳,恶心,想吐。宝妈教他吐,结果吐出一大块痰来,然后好多了。网上查了下,早上咳是因为攒了一晚上的痰,要咳出来,所以咳的厉害。后面观察,好像好了很多,但饭还是不怎么好,拉屎的情况来看,好像是不消化。给他做了生姜红糖大蒜水,去寒化咳的,不喝。

继续去医院复查。。。

易到打的,充返100%,算是帮我省了不少路费,看个医生花钱如流水呀!!

c/c++结构相同但名字不同的的struct如何转换

258次浏览

比如一个struct1和struct2,里面的成员都是一样的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
struct struct1
{
int a;
int b;
float c;
};
 
struct struct2
{
int a;
int b;
float c;
};
 
struct1 T1;
struct2 T2;

现在如何把T2转换为struct1类型的?

试试

1
struct1 t1 = *(struct1*)&T2

不过这实际调用了struct1的copy构造函数,T2并未实际变为struct1类型,而是做为参数构造出一个全新的t1

c++形参int与const int等价

236次浏览

在c++形参中 int 等价于 const int。

因为如果你的函数的参数是int类型变量,那么实参传给形参的是值,所以函数内不管如何去改变该参数都不会影响实参。

如果你在这个形参前加以const修饰,那么形参值在你函数内将不能被改变。

不过由于函数参数的类型限定总是针对调用者而言的,因此对于int参数前面加不加const对于调用者而言都一样。所以加const反而会显得有些冗余。

64af63cd83ee47e2b07aacf096b7de54