传说,微软永远不会支持C++标准.
传说VS2005以上都不会支持C99.
但我需要一个C99重要的特性,那就是动态数组,而微软永远给我C2466错误.

.......
BMP24bitRZ(mybmp,bmp);
unsigned int bmpsize=bmp.Height*bmp.Width*3;
unsigned char ibm[30000];//真实的数据量也许不会有这么多,但为了保险必须这样,如果数据量只有一点那不是很费内存?
//unsigned char ibm[bmpsize];   如果这样永远都是C2466错误
//unsigned char *ibm=new    ......    malloc      glTexImage2D无法分析,应用程序奔溃.即使末尾添加文件结束符-1.
for(unsigned int i=0;i<bmpsize;i++)ibm[i]=bmp.DataRGB[i];//bmp.DataRGB是一个动态指针
.......

glTexImage2D(GL_TEXTURE_2D,0,3,bmp.Width,bmp.Height,0,GL_RGB,GL_UNSIGNED_BYTE,&ibm);
.......

glTexImage2D最后一个参数的类型是const void*
这意味着我无法使用new或者malloc去做正常分配,我试过,得到的都是应用程序奔溃.动态数组是可以的.


PS:对于发生这种情况的我想知道你们是如何解决的.
GL对我来说到此为止了,人家都出es了,感觉已经放弃PC平台.
现在下了DX的教程,不会有这种问题了吧........

微软说的很明白 C99部分支持。。

用malloc呢？？

glTexImage2D的内部到底运用了什么机制我不知道(也许是内存拷贝,或者其它什么东西),但只要是动态申请的都不行.

PS:不是我说的要不是因为特么同一个程序vs编译出来在10kb一下,GCC/G++编译出来在40kb以上我是不会用微软的东西的,你懂的~~!!!你懂的~~!!!你懂的~~!!!你懂的~~!!!你懂的~~!!!你懂的~~!!!你懂的~~!!!你懂的~~!!!

-Os和strip 你懂的

我是说win上,手动剥了也没用.以前用devcpp而且时间戳本来默认的就是0.
原来用winhex找到file标致然后删(其实等同于剥掉附加码),然后在用upx压缩.
从来没得到过vs默认编译出来的这样大小,而且还可以用upx压.C,当时吓尿了

我说的就是win devcpp带的GCC太老了

比VS还是差一点罢 貌似十来K

C++标准 微软还比较热心 但C的 微软只想实现那些C++里也有的

总之 微软就不想让你用C C++也是迫不得已 快换到大.NET阵营

介是不可能的!