为Coo改进gcc
http://sourceforge.net/projects/coo/
gcc -fms-extensions就可以支持Coo,但不完美
1. union默认初始化,gcc初始化第一个,而EXTENDS2却用第一来覆盖
旧虚表指针,所以union默认初始化最好躲开---初始化最后一个,本来
原来C标准就不应只优待第一个。
2. Coo很少使用强制类型转化,这样可以充分利用类型检查来保障Coo的
健壮,但有一个例外,在虚表初始化时为了性能和简洁使用了强制类型
转化函数指针,int (*)(CThis*)强制转化为int (*)(CBase*),这里存在
出错隐患,但又是合理要求。只要对gcc稍加改进即可,判断CThis中包含
以CBase命名(或类型)的成员,并且偏移为0,就认为参数兼容。此逻辑是
严谨兼容的,决不会影响以前程序,也不会有副作用。
其实我觉得C标准做这些改进最好。当然改标准就不能只为Coo,函数参数
兼容判断就不要用CBase命名,而是用CBase类型。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
just for fun
LZ居然问clang成熟了吗?
看来你想做的Coo也不会成熟到哪里去……
不是我故意打击你,其实我也在做新语言。
所以不愿意看到像你这样有想法有行动的人走错方向(当然也有可能是我错不是你错)
但是不跟进软件工业的趋势,很难有人愿意跟你做。
All right. Play with yourself.
clang吗?现在成熟了吗?
Coo并不复杂http://bbs.chinaunix.net/thread-1715134-1-1.html
我熟悉另一个工业级的compiler,但是不了解你的Coo。
Coo不是新的语言,也不是新的编译器.是C向OO的一个扩展
现在gcc加个参数后就可以支持Coo,但不完美.
我将贴子发到这里,是希望哪位认可Coo又能熟练修改gcc的
高手帮忙做些改进,如果怕影响别人,可以全归到
-fms-extensions参数下.这件事我也可以做,但一来确实很
忙,二来没修改gcc经验.gcc那么大实在让我发怵,但修改tcc
的经验告诉我应该会者不难.
Coo比GCC改进了哪些
支持一下