Chinaunix

标题: 弱弱的发帖寻求开源爱好者 [打印本页]

作者: gtkmm 时间: 2009-12-07 01:37
标题: 弱弱的发帖寻求开源爱好者
小弟不才，一直想做一个C++库，拥有基础数据结构，文件，网络，线程进程，GUI等东东，
暂时没有商业用途想法，正考虑GPL或是LGPL。

基础数据结构基本从stl或是其它free软件（比如glibc)里弄来一些就行了，或者加点算法。

文件，网络，我觉得这些东西应该是一套的，都是IO设备，想做一个统一的。
就像socket描述符可以fdpoen，之后转到FILE里一样。不过我这次想做一个C++版的，
因为C++标准库里只有文件，没有网络支持，ACE等又太复杂了，想做一个很kiss的库出来。

线程进程基本就是封装posix规定那些了，只是用C++的范型，变长模板参数等使之用起来更舒服一些。

GUI打算如下分层。。

驱动层：需要操作系统提供一个创建窗体的办法，还有事件通知（IO事件，窗口管理器事件）
绘图层：提供一个基本画点画线函数。（比如opengl, cairo, agg等库）
应用层：实现类的层次结构。
想参考gnash实现，不过gnash很复杂，以我一人之力，估计要吐血。

这些东西，我基本都做了一点点尝试(GUI的代码被不小心rm了），像是线程，线程池等是实现好了的，IO刚刚开始弄。

朋友们提醒过我，说我比较懒，立帖为证，望大家监督。

我希望把这个库做到KISS，代码与逻辑上足够清晰，接口使用上足够简洁，而且组件之间弱耦合。
若论功能，据我所了解的很多库，实现的也不过是这些功能，而且库实现的并不巧妙（并且组件之间过份耦合，导致库太大拆不开）。
如果哪位对这方面有兴趣，我很荣幸很得到您的支持。
如果谁能提供一些想法或是帮助，也不胜感激。

作者: gtkmm 时间: 2009-12-07 01:48
举一个现在实现了的例子说明代码的风格。
class T{
      void func( int);
};

int main(){
      ThreadPool tp( 10);          //最多拥有10个线程的线程池（线程数量是动态变化的）
      tp.setidletime( 0.5);          //最长空闲时间是0.5秒，就是说线程在0.5秒内没有工作，就会退出。
      tp.setidlesize(  2 );          //最多有2个线程空闲，就是说线程池里如果有3个线程没工作，就会有一个退出。


      T obj;
      for( int i = 0; i < 10; ++i)
         tp.run( &obj, &T::func, 2); //就是obj.func( 2), run的参数是任意可以当成仿函数的东西。
}

作者: OwnWaterloo 时间: 2009-12-07 02:11
标题: 回复 #1 gtkmm 的帖子
请教一下，做内存管理么？

作者: gtkmm 时间: 2009-12-07 02:16
我现在没有做，因为我不会，而不是我不打算做。
我只是把loki里的small obj给直接拿来用了。。
如果你能帮忙，那就很感激了。。。

作者: OwnWaterloo 时间: 2009-12-07 02:21
标题: 回复 #4 gtkmm 的帖子
我也是请教来着……

作者: gtkmm 时间: 2009-12-07 02:45
大牛过谦了。。

刚才在某帖看到你与一些大牛们讨论封装的问题。。
其实，我想做这个库，也是为了解决我对于封装这个问题的困惑的。

1. 有些库，不封装，根本没法用，比如xlib。
2. 还有些函数，总回某一个值表示出错，但出错的机会很小，如果这种函数被调用几十次，到处写错误处理也很烦，最可怕的还是这些出错处理是类似的，结果到处写一遍。
3. 如果函数在某种情况下要提前返回，但返回前，必须要做一些工作，比如解锁，释放内存，如果这种提前返回的地方很多，那就要写一大堆类似的函数了。
4. 有些库为了所谓的跨平台，封装的层次太深，根本没有办法调试。

对于1,只能封装了，没办法的。
对于2,某些情况应该是一个异常，但某些情况下不必。比如read返回-1,就应该异常，而0就不必了（个人感觉）
对于3,如果那些工作由一个类来处理，就会自动析构了。
对于4,我觉得浅封装posix，先不管其它的库。至于其它平台，那就是先用posix封装那个平台，之后就能用这个库了。

[ 本帖最后由 gtkmm 于 2009-12-7 02:47 编辑 ]

作者: OwnWaterloo 时间: 2009-12-07 05:05
标题: 回复 #6 gtkmm 的帖子
我说说如果我遇到这些问题了，打算如何处理吧。
仅仅是讨论啊…… 这种没个绝对判断标准的设计问题，谁也别指望能说服谁

除非他自己愿意相信。
我也只是抛出自己的观点而已，如果你觉得有点意思，那握个手^_^ 如果觉得是胡说八道，那你继续采取你的想法做也没关系。
我也希望能听到你的看法，人总是狭隘的…… 如果你的看法把我说服了，我还得感谢你~_~

差不多就这个讨论基调吧……

xlib我只知道它是干什么的，不了解它具体接口是怎样的…… 据说是设计得很底层，仅提供最小化接口。
在这上面直接编程可能会比较痛苦。所以提出一个新的概念，让程序员在这个概念下工作，而不接触xlib，是有意义的。

posix我了解得多一些。我的中心想法是：与其浅包装，不如不包装。

1. 如果浅包装，完全不懂posix是不行的吧？
既得了解一个新的库，还要了解它底层的posix。这很痛苦。
所以，可以假设使用该库的人，依然必须了解posix吧？

2. 那么，浅包装的目的何在？

2.1 绝对不应该是编写大量代码，让 function( object, param) 的语法，变成 object.function( param );
这很没意思。前者同样是通过object认可的方法去操作object，而不是直接拨弄object的数据。
这可能被称为数据隐藏，不变式维护，还有修改点限制什么的。嗯，也是很多人口中的封装的意思。
而OO中的封装部分，我觉得达到这点就足够了。这就是OO中封装的核心。 object.function( param ); 只是语法样子不同而已。

而且，不一定所有c api，都可以以这种方式，转换为c++api 。
比如FILE* 和 fscanf。 c89我记得是没有vfscanf的。如果我没记错：
1. 所谓的File，要么不能实现原有的fscanf —— 功能少了
2. 要么必须把内部的FILE*暴露出来 —— 那还不如干脆不做这个事情 ……

这只是一个例子，好像c89某个修订还是c99加入了vfscanf。

2.2 绝对不应该限制原有的功能
一旦限制了原有的功能，当需要该功能的时候，用户不得不抛弃一切美丽的封装，直接访问底层。

2.3 既然完全不改变原有的编程模型，浅包装的目的，无非是想让某些时候编程方便一些。
这里得限定一下，所谓的浅包装，就是该层和下层之间通常仅仅是转发，几乎不带什么多余逻辑。

如何不包装，也能让编程方便一点？这个只能有一说一，有二说二了…… 我一下子也想不完……
一个一个说吧。

原帖由 gtkmm 于 2009-12-7 02:45 发表
还有些函数，总回某一个值表示出错，但出错的机会很小，如果这种函数被调用几十次，到处写错误处理也很烦，最可怕的还是这些出错处理是类似的，结果到处写一遍。

嗯，这是C语言一个不太方便的地方 —— 没有异常。没有异常会导致无法自动对某个错误保持中立。
异常中立我就不多解释了，既然你打算用异常解决这个问题，我相信你也是因为C语言在这点上让你难受了。

我的想法嘛…… 在C++中真要解决"自动对错误保持中立"，那还是得用异常，没别的办法……
但可不可以这样…… 虽然有点土气……

error read(int fd,  param ); // posix
void my_read(int fd,  param ) {
      error e = read( fd, param );
      if ( has_erroe( e ) ) throw some_exception( e ) ;
}

也就是说，不要弄到一个File类里去。让程序员依然是在posix下工作：
int fd = open( ... );
error e = read( fd , .... ); // 我想自己处理
my_read( fd , ... ); // 我不处理

注意，如果某个程序员对你提供的my_read中的 has_error 不满（read返回值只有0和-1？）：
他不调用my_read就可以了……  不用放弃你整个File类。
如果他觉得某种 his_has_error 是经常的情况，他自己写一个 his_read 就ok了。

原帖由 gtkmm 于 2009-12-7 02:45 发表
3. 如果函数在某种情况下要提前返回，但返回前，必须要做一些工作，比如解锁，释放内存，如果这种提前返回的地方很多，那就要写一大堆类似的函数了。
对于3,如果那些工作由一个类来处理，就会自动析构了。

解决3这个问题，你需要的不是一个类，而是RAII。
甚至都不是RAII，而是RRID ——  Resource Release Is Destruction 。这东西有现成的，Loki::ScopeGuard，就2头文件only。MIT许可证。

f()
{

int fd = open( ... );
if ( fd is invalid ) throw ... ;

LOKI_SCOPE_EXIT(close, fd ); // 分配后成功后，立即锁住资源

char* buf = malloc( ... ); // 或者是某个可以抛出异常的版本。
if (!buf) throw ...;
LOKI_SCOPE_EXIT( free, buf );  // 分配成功后，立即锁住资源

下面的代码中，可以自由的使用任何跳转，除了longjmp。

}

Loki::ScopeGuard 也有自己的缺点，比如它是rollbackable的。很多时候并不需要回滚功能。（回滚功能会稍稍做点无用的事情）
第2个缺点，它不能作为成员。
ScopeGuard还是不错的…… 本来我以为类似它这样的语法，没有auto是会很难看了…… 结果被Alexandrescu一个const引用搞定了……
它提供了一种思路：范型的RRID或者rollback。

可以在这上面发挥一下，做一种不带rollback功能的，可以作为成员，嵌入到内中的，没有额外开销的，范型RRID 。
这个我有点想法，不过太懒……  没去深入想……  等着C++0x流行后，有decltype会比较好办一些^_^

如果你的目的就是提供一个类……  那就继续提供吧……

原帖由 gtkmm 于 2009-12-7 02:45 发表
4. 有些库为了所谓的跨平台，封装的层次太深，根本没有办法调试。
对于4,我觉得浅封装posix，先不管其它的库。至于其它平台，那就是先用posix封装那个平台，之后就能用这个库了。

嗯，层次太深是让人头很大的地方……  尤其是C没有异常……  要把底层的错误给带出来……  那叫一个痛苦……
比如直接返回值代表错误含义的，就不说了……  一层一层往上返回吧……
也有返回值仅指出对错的，用lasterrror查询具体原因的。这样比较容易记忆，但依赖于tss。
还有《C 接口与实现》中模拟出的TRY, CATCH，再深入一些就差不多可以做到自动错误中立了。
不过不太敢用……  毕竟这东西，在C语言中，算是非主流吧？  会雷焦别人的 ……

其实，所谓的跨平台……  说穿了，就是引入一个中间层次……
需要跨平台的人，使用这个中间层次。实现跨平台的人，再每个平台下实现中间层次。

你现在是打算建立一个新的中间层次，是吧？
其他这种库中，也建立了中间层次，为什么它们最后变得层次很深？总是有点原因的…… 设计太差？

可不可以换一种方式？  完全不要这个中间层次？  其实我的意思是，使用现有的中间层次 …… 就是posix。
然后在不支持posix的操作系统上（嗯，好像就一个），实现posix ……
完整的posix我不了解。  我最了解的是pthread部分。好像就几个特性没把握，其他都可以实现。
比如barrier，这应该要涉及汇编，不懂……
比如cancel机制，我不太了解pthread中这个cancel机制…… 这是和win32 不同的一个地方， win32没有这种东西。
有cancel的编程经验后，应该也不难。

这样的话，写的是pthread代码（比较多的人熟悉），在win32下链接一个库（逃不掉的工作），在posix下，几乎不用你做什么多余的事情，链接pthread即可……

我知道有个pthread-win32的库……  不过对他有些地方不太满意。
比如它几乎所有对象都动用了动态内存，而内部又使用malloc …… 二进制兼容性可以通过其他方式解决，不透明指针类型不是唯一的办法。
比如它实现STATIC_INITIALIZER的方式 ……  虽然我个人觉得pthread的STATIC_INITIALIZER就是一个错误……  至少应该将它降级为optional。
我讨厌这种 get_and_init语意的接口。用起来确实会爽一点点，但不用也死不了。
要实现这种 get_and_init语意的接口，会遭到很多很多麻烦。

心里隐约有一个依然是get_and_init；但是一旦init完成，以后的get_and_init调用就不再需要if测试，仅仅get的方案。
应该是可以实现的。具体没仔细想。

稍微大点的库，都要用到动态内存分配的。很多库就很不负责的直接使用malloc了 ……
所以我一开始就是问你对这个有没有什么想法…… loki.smallobj 在我的毕业论文里被批得半死，哈哈哈

底层要么用malloc, 要么用new，没别的定制方式；那个独特的char index设计，让chunk数量增多； vector<chunk> 本身就要消耗动态内存 ……

有一点可以改进的地方，就是归还时，找block 所属chunk，可以将chunk组织为树，就不需要线性查找。
Alexandrescu大牛在MCD里将归还情况分析来分析去的，居然没想到这个…… 不知道是不是考虑移植性问题了……
当然， i386下肯定没问题，其他平台下 …… 指针的比较语意是怎样定义的我不清楚了……

作者: OwnWaterloo 时间: 2009-12-07 05:21
标题: 回复 #6 gtkmm 的帖子
哦，  好像有个地方理解错了 ……

你是为了建立一个中间层次，屏蔽各种posix实现之间的差异？
如何屏蔽？  取交集？  那直接取posix的交集好了 ……

如果比交集多，需要自己实现一部分属于posix又不被目标平台支持的接口的话，使用一个中间层次可能带来的困扰会少一些。
但还是尽可能维持和posix差不多的样子吧，以减少学习成本。
核心部分也别做成C++吧 ……  让C程序员也沾沾光，用用

说来说去…… 如果按这个方向发展下去…… 那就是apr了 ……
如果加上C++接口，那就是boost了 ……

作者: hellioncu 时间: 2009-12-07 08:36
包含太多内容的封装的库往往没有市场，我不想为了其中的一点内容而包含一大坨东西，而且不同项目需求不同，要用一种封装符合多种需求不现实。

作者: youshuang 时间: 2009-12-07 09:45
标题: 回复 #9 hellioncu 的帖子
同意这位大哥的看法，要写一个小而且精，而且有创意的东西。
将来一定要能赚钱。。。买房阿。。。

作者: gtkmm 时间: 2009-12-07 12:23
于是我的异常代码都是用用宏写的_throw，而不是throw，禁了这个宏，就能在出错是返回-1了。
想比于cout,cin我更倾向于printf,scanf，不过printf和scanf的实现我觉得有问题，至少bsd的代码上速度问题。
再说封装，c99不是把一个“封装”过后的complex引入了么？还重载了+-*/，大家也没有说什么。
我确实想封装并且实现很多东西，不过我也说了，这些东西是弱耦合的，可以很容易拆开，想用哪块就用哪块，不用管整个库。

apr我没用过（只是内存那块用过）， boost我觉得很多库臃肿而且低效，而且不区分什么应该是标准库，什么不应该是，结果太大，而且想在头文件里实现一切，并大量用模板，直接导致编译速度差。

就算是一个新的而且小的boost吧，不过是我认为完美的。

作者: gtkmm 时间: 2009-12-07 12:31
标题: 回复 #1 gtkmm 的帖子
这个世界己经挺好了，
不过某些天，某人觉得某方面不好，于是出现了某库。
又是某些天，某人觉得某方面不好，而且是语言上的问题，于是出现了一个新的语言，之后把现有其它语言上的库一个一个的移植。

（比如python的库，多到BT的程度，无所不能了，成为神了）

作者: zhujiang73 时间: 2009-12-07 14:44

原帖由 gtkmm 于 2009-12-7 01:37 发表
小弟不才，一直想做一个C++库，拥有基础数据结构，文件，网络，线程进程，GUI等东东，
暂时没有商业用途想法，正考虑GPL或是LGPL。

基础数据结构基本从stl或是其它free软件（比如glibc)里弄来一些就行了，或 ...

您这个 ID 和一个知名程序库同名，容易引起符号冲突，建议你加个名字空间区分，例如：my::gtkmm.

C++ 的库已经比较多了，也不时尚了，要不你开发个 ajax 库吧，这个最近比较流行。

作者: OwnWaterloo 时间: 2009-12-07 14:55
标题: 回复 #11 gtkmm 的帖子
不能用宏去控制throw 或者返回错误代码。因为客户对throw 和错误代码的反应是大不相同的。
除非想让客户代码写成这样：
#ifdef THROW
error e = f();
if ( !e ) {
      handle e
}

#else
try {
      f();
} catch ( ex e ) {
      handle e
}
#endif

我也想做成这样：这些东西是弱耦合的，可以很容易拆开，想用哪块就用哪块，不用管整个库。
看来我想的东西还是太非主流了

作者: gtkmm 时间: 2009-12-07 15:02
只是我用gtkmm当名字，并不是我的库。
C++库虽然很多，但我还是没有找到我想要的那种，于是想实现。
我觉得C++是艺术品，我用这个艺术品去创作自己的艺术，我现在不考虑ajax。

我非常讨厌用#ifdef THROW，
所以我干脆提供了一个特有的头文件，引入这个头文件就有异常，不然就没有。
而我到底define了什么，那在库的外面，是不需要关心的。

作者: OwnWaterloo 时间: 2009-12-07 15:05
标题: 回复 #15 gtkmm 的帖子
#define 了什么，库外面不用关心。
但到底是用throw 还是error code，客户代码不关心不行。

作者: gtkmm 时间: 2009-12-07 15:08
客户自己是知道，他是怎么引入这个库的，还有这个库是怎么编译的。

就像fftw默认是double，想用float就要编出一个fftwf来。
所以，我的库也要自己编译出一个带异常的so或是一个不带异常的，看怎么编译。
之后看想链接哪一个so，来决定里面有没有异常。

作者: converse 时间: 2009-12-07 15:13
标题: 回复 #9 hellioncu 的帖子
顶这句话,这点应该也是unix哲学一直强调的.

作者: OwnWaterloo 时间: 2009-12-07 15:16
标题: 回复 #17 gtkmm 的帖子
哦，这样？

throw.cpp

#include "enable_throw.h"
#include "lib.h"

void f1()
{
lib_function();
}

non_throw.cpp
#include "lib.h"

void f2()
{
if ( error e = lib_function() , !e ) { ... }
}

可行。

作者: hellioncu 时间: 2009-12-07 15:41
建议楼主还是做一个能运行的能完成特定功能的项目，做好了会比你现在做一个“无所不包”开发库有成就感。

如果还是想做一个开发库，建议做一个着重于某个特定领域的，象Openssl那样，否则我看是没人会愿意使用的

作者: hellioncu 时间: 2009-12-07 15:44
另外问下OwnWaterloo，是学生/老师么？发帖子还写那么多内容，而且学术气味很浓呀

作者: OwnWaterloo 时间: 2009-12-07 15:53
标题: 回复 #20 hellioncu 的帖子
请教一下

其实我也是赞同将库做小做精这个观点的。
但这会引起另外一个问题……
假设，我的项目较复杂，我就得找很多这样的库来使用，比如找个 data structure的，找个 memory management的，找个thread的，找个 …… 找个…… 找个 ……

再次声明一下 …… 我觉得上面描述的情景，也比下面的情景要好：
假设，我的项目很简单，我只想要个thread的。找个A库，有thread，但又其他东西，很大，放弃……
找个B库，有thread，但又有其他东西，很大，放弃……
找个 …… 放弃…… 找个…… 放弃…… 找个 …… 放弃……

所以，想请教的是，对这种小而精的库，组合使用的时候有没有什么建议？？？

作者: OwnWaterloo 时间: 2009-12-07 16:07
标题: 回复 #21 hellioncu 的帖子
刚毕业

我也觉得我写的那些东西很非主流，所以我一般不说的

作者: gtkmm 时间: 2009-12-07 16:56
小而精，也是我所追求的啊。。
所以我才弱耦合，为的就是能拆开看，就是一个个很小的，合起来，就是一个全面的库。

作者: UnixStudier 时间: 2009-12-07 17:07

原帖由 OwnWaterloo 于 2009-12-7 15:53 发表
请教一下

其实我也是赞同将库做小做精这个观点的。
但这会引起另外一个问题……
假设，我的项目较复杂，我就得找很多这样的库来使用，比如找个 data structure的，找个 memory management的， ...

这种情况，我也不会使用你的库的，项目组会自己做一个。

作者: OwnWaterloo 时间: 2009-12-07 17:14
标题: 回复 #25 UnixStudier 的帖子
大哥，不是我要做好哇 ……

anyway …… 你说的不会使用，是哪中情况？
是上面的A ：将多个小而精的组合起来太麻烦
还是B ：我仅仅需要一小部分功能，所以不想引入一个大而全的库。

作者: hellioncu 时间: 2009-12-07 17:15

原帖由 OwnWaterloo 于 2009-12-7 15:53 发表
请教一下

其实我也是赞同将库做小做精这个观点的。
但这会引起另外一个问题……
假设，我的项目较复杂，我就得找很多这样的库来使用，比如找个 data structure的，找个 memory management的， ...

我做的项目除了编译器自带的一般很少用第三方的库，data structure一般根据需要自己写，基本上数组+链表这些差不多了，根据情况用STL，内存池、线程、socket等都是自己写，主要我做的项目一般性能要求都很高。其实写多了，把以前的东西拿来根据不同需要改动下也是很简单的事情。

作者: OwnWaterloo 时间: 2009-12-07 17:22
标题: 回复 #27 hellioncu 的帖子
如果能做到确实能适合你的项目呢？

比如说，假设某个库，它能达到这样一个目标：
你只会说，oh，这个组件对我来说功能不够 —— 不过我可以轻易在它之上添加我需要的功能。
你绝不会说，no，这个组件的功能与我的需求相悖，我很难改装它，使得符合自己的需要。

这里的功能，当然也包括性能。不损失性能而达到通用性。

这样的库，你会使用吗？

作者: GodPig 时间: 2009-12-07 18:23
那个啥呢
qt这些不是也提供好多东西吗？
什么网络、文件、GUI之类的都有了吧～

作者: hellioncu 时间: 2009-12-07 18:38

原帖由 OwnWaterloo 于 2009-12-7 17:22 发表
如果能做到确实能适合你的项目呢？

比如说，假设某个库，它能达到这样一个目标：
你只会说，oh，这个组件对我来说功能不够 —— 不过我可以轻易在它之上添加我需要的功能。
你绝不会说，no，这个组件的功 ...

首先我得知道它的存在吧，这样它得比较有名，能让我和其他人员信任它。
其次它得比较简单，让我相信自己能够驾驭得了它，或者久经考验，没有问题。
否则用了它之后，程序出问题就不好解决了，容易成为罪人：谁让你用这么个破烂库呢

作者: OwnWaterloo 时间: 2009-12-07 18:52
标题: 回复 #30 hellioncu 的帖子

比较简单，相信能够驾驭

嗯，了解了~ 过段时间来接受大牛的检验

先提前谢过了

作者: hellioncu 时间: 2009-12-07 19:51

原帖由 OwnWaterloo 于 2009-12-7 18:52 发表

嗯，了解了~ 过段时间来接受大牛的检验
先提前谢过了

我啥时候也成大牛了

作者: OwnWaterloo 时间: 2009-12-07 20:01
标题: 回复 #32 hellioncu 的帖子
因为你像prolj、emacsnw（暂时只想起2位……）一样，直击要害而不多罗嗦

这是境界

作者: srdgame 时间: 2009-12-07 20:27
求大求全是不可取的，

作者: gtkmm 时间: 2009-12-07 22:18
本来想找人一起做的，不过结果居然变成这样了，虽然结果还是在我的意料之中，不过我还是伤心了。

作者: OwnWaterloo 时间: 2009-12-08 03:42
标题: 回复 #35 gtkmm 的帖子
其实结果也在我的意料之中

所以我一开始欲说还休

别灰心，去做便是。会不会有人用又有何关系？
程序员都有发明轮子的冲动。那些抱着"不要重复发明轮子"的观点，要么是人云亦云，要么是过来人 —— 谁知道他们是不是已经偷偷发明过好多次 ……
不管轮子怎样，总是可以提高编程能力、熟悉不同系统的嘛，有收获即可

作者: 雨过白鹭洲 时间: 2009-12-08 12:33
支持，现在的C++库，比如boost虽然很强大，但太依赖于模板特性，使用也不简洁

这么说当初我从java转回来学习c/c++时，就在想，啥时候也能像java那样有个强大的标准库，而且其它库开源社区都有典型代表，想什么有什么。。

作者: flynetcn 时间: 2009-12-08 18:17
两个美女和一个风流才子

作者: cnsibo 时间: 2009-12-08 19:44
no懂！！

作者: ioerr 时间: 2009-12-08 19:52
偶不搞开发，不过，支持开源

，顶！！！！！

作者: flymouses 时间: 2009-12-09 13:53
标题: 支持
当然最好有特色或者超越，在性能上、使用方便性上、功能上有所提升，而不是重新实现一套

作者: 5毛党党员 时间: 2009-12-09 14:03

原帖由 gtkmm 于 2009-12-7 22:18 发表
本来想找人一起做的，不过结果居然变成这样了，虽然结果还是在我的意料之中，不过我还是伤心了。

我就看看...我不说话

作者: mz198424 时间: 2009-12-09 14:45

作者: souldemo 时间: 2009-12-09 16:20
ZL是刚进公司的吧，还带着一些学校的想法。
我以前也有你这样的想法，不过我是用C写的，
主要是一些靠代码分发的程序，每个文件只支持
一个功能，比如锁，IO，链表，定时器，内存池，
工作队列，其实我当初写这个是为了做另外一个
库，大部分都是模仿Linux内核实现的，比如内存
池和定时器，效率应该还可以，就是有些乱，没时
间整理。今年工作搞上Java了，进展不是很大，

如果你说写通用的模块，比如IO，UI，SOCKET什么的
涵盖很多功能，针对某一个平台还好，可当平台移植性
变为考虑因素了，性能又下降了，而且会更复杂。我只
能这么告诉你，你做得越多，越会发现你的库没什么价值。

C有glib，还有源码分发的gnulib（直接使用其代码），
其他的库也很多。

我最近也在写一个c++项目要用一个你想写的那种库，
但是没有特别完美的，我选了libcommonc++,LGPL协议，
跨平台的，这会让我省去很多时间和精力，而简单的数据结
构等能不用就不用。

其实当初和另外一个GNU的库commoncpp2,选了几天才
决定放弃，不是commoncpp2不好，而是因为它是GPL的，
而我的东西是不可能以GPL发布的。其实这个不错的库也是
因为许可证的原因很多人不愿意去用。

所以关于许可证建议你使用BSD，APACHE之类的证，GPL发布
的会有很大问题，LGPL也只能允许你动态链接。

至于boost,我始终没敢用过。

如果你写好了别忘了mail我一份(souldump@163.com)，
也许我可以帮你改进测试.

作者: UnixStudier 时间: 2009-12-09 17:20

原帖由 OwnWaterloo 于 2009-12-7 17:14 发表
大哥，不是我要做好哇 ……

anyway …… 你说的不会使用，是哪中情况？
是上面的A ：将多个小而精的组合起来太麻烦
还是B ：我仅仅需要一小部分功能，所以不想引入一个大而全的库。

要做一個庫，我覺得最好是專注于一個小方面，做的好一點，同時方便別人與其它模塊組合，這個最好的。
大而全，我覺得不會做出有意義的庫。

建議先參考:apr,nspr

作者: lygxy 时间: 2009-12-09 23:24
都是老鸟，学习了

作者: OwnWaterloo 时间: 2009-12-10 08:33
标题: 回复 #45 UnixStudier 的帖子
thx~

作者: gtkmm 时间: 2009-12-10 08:42

原帖由 UnixStudier 于 2009-12-9 17:20 发表

要做一個庫，我覺得最好是專注于一個小方面，做的好一點，同時方便別人與其它模塊組合，這個最好的。
大而全，我覺得不會做出有意義的庫。

建議先參考:apr,nspr

common c++2里好像没什么东西的，我翻过一遍源码。

apr没研究，nspr不知是什么，只用过glib，boost，QT，
线程是因为其他库不方便，
IO，网络是因为不能和其他库融合，每一个都是自成体系。
GUI因为没有直接用opengl做。

想试试做点东西，我怕我一不小心就老了，结果啥也做不动了。

[ 本帖最后由 gtkmm 于 2009-12-10 09:22 编辑 ]

作者: gtkmm 时间: 2009-12-10 09:25

原帖由 souldemo 于 2009-12-9 16:20 发表
ZL是刚进公司的吧，还带着一些学校的想法。
我以前也有你这样的想法，不过我是用C写的，
主要是一些靠代码分发的程序，每个文件只支持
一个功能，比如锁，IO，链表，定时器，内存池，
工作队列，其实我当初 ...

不知道您写的是BSD，还是GPL，能膜拜一下么？

作者: crazybu 时间: 2009-12-10 09:51
虽然看不懂你们在讨论什么，我还是坚持看了下来，就只有一个感觉：我太无知了。惭愧，刚才还在看考研的书（计算机），以前没有认真学过，也不是计算机专业毕业，只是爱好的学了一点点PHP，现在想想人真的很可怕。看书基本是死记硬背，我现在都怀疑我考研的意义何在??自嘲一下。

作者: youshuang 时间: 2009-12-10 10:06
倒是想参与，不过不完全赞同你的编码风格。
如果你同意先讨论通过编码风格的话，我就参加。QQ：710145308

因为要从一个风格转换到另外一个，很困难。大家折衷最好。

作者: gtkmm 时间: 2009-12-10 10:24
好吧。

作者: zliming 时间: 2009-12-10 10:51
这个项目有没有什么QQ群，加一下我Q9169778，可能会是你的用户

作者: swxlion 时间: 2009-12-10 13:00

原帖由 OwnWaterloo 于 2009-12-7 16:07 发表
刚毕业我也觉得我写的那些东西很非主流，所以我一般不说的

非主流？
当年托马斯·杨德双缝干涉和普朗克的Quantum对当时统治物理界的微粒说和经典物理，都是非主流~~~
哦，广义某某论的那个黎曼几何，当时也是非主流~~~~

作者: swxlion 时间: 2009-12-10 13:02

原帖由 gtkmm 于 2009-12-7 16:56 发表
小而精，也是我所追求的啊。。
所以我才弱耦合，为的就是能拆开看，就是一个个很小的，合起来，就是一个全面的库。

我打算等有空了，回过头来把我签名的这个项目再拆出一个子库来。
这样要整个库用也行，用一个分库也行。

作者: youshuang 时间: 2009-12-10 13:28
开源软件除了最开始的几个历史经典EMACS，GCC，MOZ之外，
后面的人越来越不行了。

小的软件，比如1W行左右的myget，用C++写的，简直一坨屎。
大的软件，比如1000W行的OpenOffice，用C＋＋写的，那也是一坨屎。

为什么捏？
因为他们玩的是兴趣，不是产品；他们没有统一的风格，自己爱怎么搞就怎么搞；很多人的想法就是Linus所谓的：It works，能用就行。

楼主要写的话，先把整个框架，方方面面想清楚了，写个完整的需求先。

作者: youshuang 时间: 2009-12-10 13:30
个人觉得，你要是能写个200页左右的需求文档，任务完成一半了。

作者: mz198424 时间: 2009-12-10 13:38
支持lz

作者: OwnWaterloo 时间: 2009-12-10 18:00
标题: 回复 #50 crazybu 的帖子
我也怀疑

考研太恶心了

作者: OwnWaterloo 时间: 2009-12-10 18:03
标题: 回复 #54 swxlion 的帖子
他们提出非主流口号之前，都应该有相应的证明或者实验吧？没有空喊非主流口号的吧？

所以…… 我还是暂时闭嘴比较好

等言之有物之后再说

作者: windyrobin 时间: 2009-12-10 18:34

原帖由 youshuang 于 2009-12-10 13:28 发表
开源软件除了最开始的几个历史经典EMACS，GCC，MOZ之外，
后面的人越来越不行了。

小的软件，比如1W行左右的myget，用C++写的，简直一坨屎。
大的软件，比如1000W行的OpenOffice，用C＋＋写的，那也是一坨 ...

现在的知名开源，webkit ，chrome，代码风格都是很不错滴，
webkit的基础类库 wtf （以前我就推荐上传过），
chrome的基础类库（放在chrome代码的base目录）

都是很不错的跨平台c++库，小而精，倒是和楼主的设想有很多相似

我现在开发代码，基本上都是优先考虑这些基础库，呵呵

有兴趣的朋友不妨看下！

作者: gtkmm 时间: 2009-12-10 19:34
有QQ群的，欢迎大家了。。。
96335419

加群就注明：chinaunix吧，谢了。

作者: UnixStudier 时间: 2009-12-11 14:19
代碼風格可以考慮：
http://www.freebsd.org/cgi/man.c ... ASE&format=html

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)