放弃bcb2006

[onemonth]

安装了BDS2006，并使用了一段时间，第一个事情是，不支持boost的function，而bcb6可以，郁闷；安装dev的treelist，重新启动bds后，就没有了，ehlib也有同样的问题，而我只用这两个控件，郁闷；如果没有工程，看不到控件（是不是没找到怎样设置？），郁闷；如果用delphi2006编译了package，重新启动bcb的时候，会报告“delphi设置失败”的信息，同样，反过来使用也报错，必须重新启动bcb，郁闷。
第一个问题，只有编译器改变才行。
第二个问题，应该是我哪里没设置对，或者包有问题？
第三个问题，不知道怎么回事。
第四个问题，难道是安装的问题？不然使用很不爽。
没办法，只有重新用bcb6了。
当然，如果哪位能够解决2，3，4三个问题，我一定换回bcb2006，毕竟ide要好用很多。第一个问题，我做一个简单的function就可以了，只需要支持成员函数就行，不用function这么完全，呵呵。
问题没解决前，就用bcb6了。

[CACACACACA]

我是不可能用2006了.唉...

[minlulu]

BCB2006我倒是装了，没敢用。

[HalfWorm]

我试了一下上面说的bug，没事。一开始我是装错了补丁，然后卸载了重装。卸载的时候也没有出问题。怪了。

[cczlp]

BCB总是比Delphi问题多

[constantine]

你把这些问题都归到bcb2006身上是否正确？
1.boost 我没有用过，bcb6也不是很好用，要自己安装包支持啊，2006不能装？
2.这个是第三方控件的问题，是这个控件已经支持2006？还是你自己搞得，自己搞清楚，我自己用过几个控件都还可以，不过没有用到你这些，基本上都是自己写的，从D7升级过来的
3.控件是要放到From或者其他设计容器上的，你连项目都没有你要控件干什么？就算给你看到了也用不了，没有什么好郁闷的
4.不清楚你 的意思，你编译什么包？怎么做的，我没有见过

[netsys2]

???

[onemonth]

你把这些问题都归到bcb2006身上是否正确？
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
第一个问题是bcb编译器的问题。boost只有几个库需要安装，file,thread等，而function是不需要的。bcb2006不支持，是不符合标准的缘故，就是它的特化机制问题。你测试一下gcc，vc7.1就知道了。bcb6是支持的，不知道2006怎样升级的。也许bcb编译器版本为6才行吧。顺便说一句，不用template，是不能够设计出轻便，弹性良好的类库的。
第二个问题，其实是bcb，delphi都有这个问题，就是安装好了包，重新启动开发环境，结果包就丢失。我很少做界面设计，核心库是不用vcl组件的，没去了解过原因，现在需要做一些单元测试，也就用这两个控件了。我想，这个问题应该都遇见过，应该有人指导我吧，呵呵。
第三个问题，毕竟以前的版本都能看到，而且出于某种心里，在没有工程的时候看不件，心里确实很不爽，还有谁也这样认为呢？大家说说。
第四个问题，就是用bcb安装一个控件，然后退出bcb，再运行delphi或c#builder，就报bcb设置有错（大意如此）。

[onemonth]

不是说问题归结到bcb身上，毕竟这些问题没解决，工作就不能用它了。慢慢玩习惯了再说。

[过客猫2022]

BCB2006确实太多bug了～
http://blog.csdn.net/zdhsoft/archive/2006/02/04/591842.aspx
还有就是很难缷载～

[Jonix]

我只在安装的过程中,报.../Demo/...下文件找不到还是错误, 忽略几下就过去了.
在使用过程中除了还没有安装第三方控件(主要是没几个forBDS2006的控件)其它都试了试,
没有任何问题哎

[ch_builder]

我还在用CB6呢，要不是CB5的盘不能用了，我还想用CB5呢，觉得CB5最经典

[onemonth]

从bcb版面来看，bcb的开发人员都不喜欢用template，stl，boost使用的人也不多。采用template可以很大提高开发效率，实现的构架比oo灵活清晰得多啊。为什么不使用这些利器呢？难道都是堆砌控件？

[勉励前行]

這些問題應該都能解決的。
function的問題我沒試過，不知如何，但我想可能是預定義宏(也就上一些編譯開關)的問題，其實就是：不少C++類庫針對不同的編譯器版本做了一些編譯開關，可是沒有針對BCB2006的，就使得編譯失敗了。既然bcb6, gcc 能用function , 那麼在改動不大的情況下在BCB2006下也就能用。2，3，4這幾項應可自行解決，只是這樣一來自然對BDS2006的質量打了個問號。

可是，現在這個版本確實令人不大放心，我用的時候，單步調試時偶爾出現問題。雖然喜歡這個版本，但感覺BUG還是太多。我現在還是在用BCB6。

[onemonth]

to PPower(月亮光光，照地堂)
function不是编译开关问题，这个牵涉到模板特化问题了。原因就是bcb2006用的编译器这个地方没有达到c++标准。bcb6能通过，但是也不是用的标准特化方式。因为考虑到了移植问题，所以我的类库代码是要通过gcc编译才行，但是做GUI界面，还是bcb最好。我看了很多bcb版的帖子，没见有关template的问题，所以感觉大家都不用它。但是用在设计上，GP确实比OO好很多，可以避免很多oo设计遇上的问题。当然，GP也要比OO困难很多，关系大概就像OO和过程式这样。
既然能和delphi用同一个后端，不知道borland为什么不做结合其他编译器这个事情。

[勉励前行]

#include <iostream>
using namespace std ;

template <class T> struct testClass {};
template <> struct testClass<int> {};

template <class I, class O> struct testClass2 {
testClass2() { cout << "I, O" << endl; }
};
template <class T> struct testClass2<T*, T*> {
testClass2() { cout << "T*, T*" << endl; }
};
template <class T> struct testClass2<const T*, T*> {
testClass2() { cout << "const T*, T*" << endl; }
};


void Test(void)
{
testClass2<int, char> obj1;
testClass2<int*, int*> obj2;
testClass2<const int*, int*> obj3;
testClass<char> t1 ;
testClass<int> t2 ;
}
以上模板特化的例子可以在bcb2006通過。有關模板我了解不多,只希望B2006向標准再靠攏一點。

查找了一下，整個boost庫中涉及__BORLANDC__這個編譯開關的地方400多處，太多了，其中不少是與具體的版本號相關，不敢動，boost庫針對不同編譯器版本做了太多手腳,維護難度肯定增加了。

[勉励前行]

TO： onemonth(CSDN真烦)
記得偏特化有很多種方式，把B2006不支持的那種方式寫下來，讓人看了沒意見。
這世道，要找一個對C++標准支持得好的C++編譯真的不好找。

[过客猫2022]

onemonth(CSDN真烦):第一，模板应用的范围还是很限的。第二、BCB及windows中提供的很多方法及类，可能没有boost,stl效率高，但用起来顺手！第三BCB对模板应用很好，并且我在程序中应用了很模板。

[勉励前行]

在使用了__BORLANDC__ __MSVC__這些編譯開關後，用不同的編譯器，編譯的是不同的代碼。

怪只怪boost沒能加入C++標准中來。怪只怪boost使用了太多的與編譯器相關的代碼。
等Boost出一個支持BCB2006的版本吧。如果Boost這樣搞下去，加入標准的希望就越來越小了。要是Boost總結出不同的編譯器的一些差異及對Boost代碼的影響，而不是現在這樣出錯了就加個編譯開關是避開，那Boost加入C++標准才會讓人看到希望。

能讓編譯器語法分析引擎出錯的代碼是值得把這些代碼抓出來的。畢竟這些語法分析引擎都經過了長時間的考驗。

只是覺得，在面向應用的編程中，少用點模板容易維護些。維護那些天書樣的代碼，還不讓人狂暈倒地。應用寫好的模板倒是好主意(如STL)，提倡用模板來編程，最後還是難維護。
我的觀點：不同的應用選擇使用不同的方案，片面強求同一化，只會帶來苦果。

[onemonth]

我认为这样的情况，c++标准有一定的责任。比如，标准规定有int，char但是没有规定int大小一定比char大；也规定了需要用virtual，但是也没有规定怎样实现。这就导致了可以用各种方法来完成。对于oo，这个没有任何问题。因为oo里面，所有的东西都能清楚的知道是什么，所以的东西都需要实现。所以幕后的vtbl，成员顺序等等，只是大家能找到最好的方式，用其他方式实现也未尝不可。
但是GP不这样了。GP算是一种范畴，里面看不到对象这样的称谓，可以比较自由的表达思想。而且c++的GP，可以实例化的东西和忽略的东西，是一样重要。这个和java,c#的GP根本不一样。这两种语言的GP，只能算是单根继承语言用来明确TObject的名称。那么这样一来，由于不同编译器实例化方式不同，可能就会导致相同GP代码很可能不能编译通过。这样，要照顾各种情况，显然就困难了。
GP使用不多，主要还是因为它的不保密性，我以为。但是话说回来，GP恰好是现在做构架的头号选择。如果明白了GP，代码反而比oo好维护，当然确实学习很困难，周期曲线都要比oo长，这个没办法。

[onemonth]

因为是编译器提示是特化不成功，我也就没有找原因。现在这个题目发下来了，就看了一下。没想到问题居然是出在bcb语法分析出错。再看进去，是分析MPL的时候出错了。根据代码的定义，增加、减少几个boost的宏，也测试通不过。同样的代码用gcc没问题。没时间来一一检查源代码，我也就没有再看下去了。这样归结到是bcb的问题，我想也不为过。上面举的例子，是最起码的特化，肯定是不会错，但是一到了typetraits，那可就花样百出了，复杂度不是这样简单。更何况还有MPL掺杂，简直就是恶梦。对了，这里还牵涉到一个实例化的方式，如果只是oo，这个没问题，但是template 机制和oo完全不同，也导致了template中，相同代码不一定能同时通过不同编译器。如果只是处理到MPL，我勉强能过去，但是牵涉到编译器本身，这个我就无能为力了。

看到bcb下有人用template，很高兴。template用得少，是因为困难，缺乏经验，就象80年代用oo一样，这个很正常。如果仅仅是把template当作宏的替代，用来自动生成代码，是偏离了现代GP的发展。GP用来做构架才是前景。而这样一来，始终是避不开typetraits，policy，MPL这几个概念，而它们正是oo的最大足。至于效率高，只是c++GP的良好副作用，不用过多考虑。