glob2-devel
[Top][All Lists]
Advanced

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

Re: [glob2-devel] Refactoring


From: Sébastien
Subject: Re: [glob2-devel] Refactoring
Date: Mon, 1 May 2006 19:25:41 +0200
User-agent: KMail/1.9.1

Le Lundi 1 Mai 2006 19:12, Cyrille Dunant a écrit :
> 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...
Yes... or no ;)
I noticed that GCC get confused when you have some function overloading :
func(char*, string)
func(string, char*)
Compilation is fine but execution... (look at a recent thread about 
StringTable on this ml...)

I started looking for a replacement for ellipsis since string can't be passed 
through it. We can always use c_str() but I stay on the idea that it is not 
really a good idea (except for c function), I think we should use string 
throughout the functions' chain
>
> 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 ?
Yes, that's what he said...
>
>  -- CFD
>
>
>
> _______________________________________________
> glob2-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/glob2-devel




reply via email to

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