Re: MERGE: bse2cxx-part2


On Tue, Jul 05, 2011 at 12:27:24PM +0200, Tim Janik wrote:
> On 05.07.2011 09:56, Stefan Westerfeld wrote:
> >On Mon, Jul 04, 2011 at 09:55:05PM +0200, Tim Janik wrote:
> >>On Fri, 1 Jul 2011, Stefan Westerfeld wrote:
> >>>I've read your remarks on my first attempt to port bsebus.c to C++, so in this
> >>>merge request you'll find a version I adjusted accordingly. There are also C++
> >>>ports of a few more sources in the bse/ directory.
> >>>
> >>>repo:
> >>>branch: bse2cxx-part2
> >>
> >>Thanks, merged. You are free to port gchar->char and gint->int
> >>on the fly btw. It's a pitty that porting the code to C++ makes
> >>it so much more ugly instead of improving it ;(
> >
> >>Did you find a way yet to automated part of the most stupid
> >>changes needed? E.g. something like this small perl script here?
> >>
> >>==================
> >>#!/usr/bin/perl -w -pi.bak
> >>s,\bclass\b,klass,g;
> >>==================
> >
> >Sounds good. I think it would be best to first run a script on all C sources,
> >like
> >
> >class ->  klass
> >gint ->  int
> >guint ->  unsigned int
> >gdouble ->  double
> >gfloat ->  float
> >gchar ->  char
> >guchar ->  unsigned char
> >
> >(did I forget anything?). I can make a merge request for that.
> >
> >Once this is done, manual porting can do the rest, but that should be done in
> >seperate commits, to make it easy to review what was manually changed between
> >the C ->  C++ transition.
> Hm, I'd rather see this done on a single file before it's ported.
> These changes tend to screw up indentation, catch comments and strings
> as well and sometimes do other harm. So it needs to be reviewed with
> each individual file. Thus doing it along porting a single file to C++
> is much more natural, workflow wise.

Right, I didn't take into account that running the script would probably
require manual fixing in every file anyway, for instance because of the
indentation. So we do it your way: one file at a time.

(Btw, I'm readding the beast list to CC, I think this started as public
discussion, so it should remain public).

   Cu... Stefan
Stefan Westerfeld, Hamburg/Germany,

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