Re: [FleXML-Users] new checkins to flexml.pl and skel files

[Martin Q. <mar...@im...>]

Ok, I finally devoted some time to flexml. Sorry for the delay.

On Tue, Jan 25, 2005 at 09:30:44AM -0500, William F. Dowling wrote:
> On Tue, 2005-01-25 at 03:11, Martin Quinson wrote:
>=20
> >=20
> > I was reading the changes by curiosity mainly, and I have some question=
s.
> > (plus an extra changelog entry: do not use the "new" identifier since it
> > breaks in C++ ;)
> >=20
> > +enum {flexml_max_err_msg_size =3D 512};
> >=20
> > Why is flexml_max_err_msg_size an enum and not a const int? I understand
> > that it makes very little difference, but I would find the latter clean=
er,
> > wouldn't it?
>=20
> Just a habit of coding style consistent with local (where I work) code
> standard, historically arising from the need for the "enum hack" when
> using older C++ compilers. See Scott Meyers on this quoted at
> http://www.geocities.com/lgol27/CPlusPlus.htm.  (That's an answer, not a
> justification -- const int would be better. So feel free to change it if
> you want.)

I tried to change this, and had to revert the change since gcc complains
about the flexml_err_msg array being dynamically sized. It should be a
define, but defines are crude.

> > Would it be possible to create some sort of option somewhere stating wh=
ether
> > we're going to display the errors as some as they appear (former behavi=
our)
> > or if we put them into this mecanism, expecting the user to pool it from
> > there ?
> >=20
> > Or, more precisely, do we want to do so (since I know how to do so  ;)?
>=20
> As an option it would be OK.  My bias is toward writing library code, so
> I would prefer if the default was silence (not writing to stderr). You
> don't want your library writing to stderr -- that would make it less
> general and harder to document.

I added a -q option which goes to your direction, and left the default being
the previous behaviour.

I also fixed some long standing trivial bugs against the debian package. We
now only have a bunch of open bugs on sourceforge. I closed two of them, but
I unfortunately need some help for the remaining...

Please people, have a look at
https://sourceforge.net/tracker/?group_id=3D34654&atid=3D411869
and see if you can fix some of them...


Thanks, Mt.