语言逻辑边界和新手友好

这个是namespace的问题，不是封装问题，跑题了。

  你的这里提出的封装仅仅是隐藏实现细节。同项目组内每一个class实现细节实际上是公开的！这种技巧性的"封装",在项目内部应该少用.在我的组里面,这样的"技巧"完全不能用.这种"技巧"除了会带来麻烦,没有任何好处.

  做项目不是玩技术.

  命名冲突的产生,实际上也是封装问题的一种.所以才有namespace关键字的存在. 在C#和C++中,namespace完全是一种空间概念.完全不产生任何实体.作为开发语言,要这种奇怪的空间概念干啥? 就是为了在逻辑上做出局部包,做隔离,产生边界.
  

（明明我这个帖子是和项目有关的，结果被你带走了。 ,举出c 和c++对比,只是因为两个不同的项目用的是这两种语言)

这种技巧性的"封装"在C++中自然没有必要，在C中则可以（这里是可以，不是应该）多用，它形成了你说的边界。

》同项目组内每一个class实现细节实际上是公开的
在新手云集的项目中（注意这个大前提），有点危险，这个危险可以通过充分交流解决，但总是个隐患。如果是代码公有化（所有人都可以修改任意一段代码），就更麻烦了。

namespace的问题是C天生的东西（但也不是什么大不了的缺陷），所以我没有讨论namespace，仅仅说封装。
我承认跑题，原因是你把层次上升到了语言级别，我就随意说两句。

语言逻辑边界对“老手”友好；但对“新手”是否友好，我表示怀疑

不用怀疑什么的，实践下就会清楚了.如果只是纯粹在理论层次上讨论问题，最后就会成为信仰问题。关于信仰问题，海板老庄有篇不错的文字。

有一个概念是混淆了，边界问题不简单的体现在封装上，在一个项目或者说程序上，封装只是一种控制边界的手段，而更主要的是在于开发人员的逻辑思维能力的控制以及对长久项目实践产生的经验的体现
封装这个在OO语言中大肆推广的概念几乎只要学过此类语言的人都用过，但是对于新手基本只是提留于概念阶段，所以开发的时候可能完全不再顾及这些.

就C和C++而言，实际上C++的东西C全部都可以模拟，而且会更有效率，但是这种模拟需要你完全了解C和C++的特性.
另外说一下DDD所提及的“绝对封装”(这个算是我第一次听到这个名词)，在C的程序中，很多人会这么写:

test.h

typedef void* handle_t;

handle_t Initialize();
int Operation1(handle_t hObj);

--------------------------------------------
test.c

include "test.h"

typedef struct _tagPrivate *LPPRIVATE;
struct _tagPrivate
{
int a;
int b;
};


handle_t Initialize()
{
LPPRIVATE lpObj;

loObj = malloc(sizeof(_tagPrivate));

...

return (handle_t)lpObj;
}

int Operation1(handle_t hObj)
{
LPPRIVATE lpObj;

lpObj = (LPPRIVATE)hObj;

...

return 0;
}

对外只需要公布对应的.h file就可以, C Library和OS SDK很多都是如此封装的, 这点就是potian已经说明的.
这么做只是为了对外发布模块是用来保证内核的一些秘密，是一种封装方式，也是一种有效的边界控制手段.

哦，是吗？ 能否模拟一下这个编译期的计算看看 ？

template<int n>
struct Fa
{

  enum{v =Fa<n-1>::v*n};
};

template<>
struct Fa<0>
{
enum {v = 1};
}

int main()
{
  cout<<Fa(5)::v<<endl;
}

靠，好久不玩了，一不小心，还写错了，改正


int main()
{
  cout<<Fa<5>::v<<endl;
}

我可能说的不够明白，如果你拿某个特性来说C++自然要强于C，因为很多事情都是编译器来实现支持的而不是语法本身可以完成的，所以我所说的模拟是就实际的开发程序而言的.
Template、try catch等从语法角度当然用C做不了一模一样的，但是同样的算法实现的功能C可以做到.
btw, template可以自己写个简单的预编译器实现，只要有这个能力.

干脆asm 吧