glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] Refactoring


From: Cyrille Dunant
Subject: Re: [glob2-devel] Refactoring
Date: Mon, 1 May 2006 19:12:33 +0200
User-agent: KMail/1.9.1

On Monday 01 May 2006 18:51, Sébastien wrote:
> Le Lundi 1 Mai 2006 18:12, Cyrille Dunant a écrit :
> > On Monday 01 May 2006 18:04, Sébastien wrote:
> > > Le Lundi 1 Mai 2006 17:31, Cyrille Dunant a écrit :
> > > > > It's not lazyness, I talked about char* removal and the ellipsis
> > > > > problem with Stéphane Magnenat, he told me to look at boost since
> > > > > we already depend on it. If you have a better idea, fine, please
> > > > > expose it. Reimplement everything all the time isn't a good
> > > > > solution too but if you have an idea to replace xxxprintf wich is
> > > > > not a cut n paste of boost, I'm open (even if there is work as
> > > > > opposed to what you said)
> > > >
> > > > No, now, it is too late anyway, we already depend on boost, so we
> > > > might as well use it...
> > > >
> > > > Of course, _stripping_ the boost dependency would be a worthwhile
> > > > endeavour
> > > >
> > > > :)
> > >
> > > I agree with you...
> > > I quickly looked to AINicowar and I can't figure out where boost is
> > > used... As a test I suppressed the include and all compiled fine, the
> > > game is working
> >
> > Odd.
> >
> > Well, If you really want to use boost, it is your call -- but if it is in
>
> I don't really want to use boost, I asked for a printf replacement and
> someone told me to look at boost
>
> > fact _not_ used... But if it is only to replace printfs (even so as to
> > follow the Real True Path Of C++ Leading To Supreme Enlightenement),
> > could
>
> I don't follow the Real True Path Of C++ Leading To Supreme Enlightenement.

you should, it is enlightening ;)

> The fact is that some parts of glob code use old C char* and some other
> parts use C++ string. It could be a good thing to have something coherent.
> Currently, for some function calls you have the following :
> string my_string      // A string
> myfunc(my_string.c_str());     // A char *
> in myfunc :
> myotherfunc(string(the_string_passed_in_argument) // A string, again !
> the same append in myotherfunc, and so on...

hmmm. Probably rewriting myfunc to take a std::string would be a good idea. In 
fact a function overload would be optimal. From an "API easiness" point of 
view...

I think the idea is "string everywhere except when the programmer will want to 
write the argument explicitely"

as in 

void manipulateString(string &) ;

void printOnDebugOutput(char *) ;

nct ?

 -- CFD





reply via email to

[Prev in Thread] Current Thread [Next in Thread]