[Top][All Lists]

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

Re: [aspell-devel] Port to Win32

From: Gary Setter
Subject: Re: [aspell-devel] Port to Win32
Date: Wed, 22 Sep 2004 12:16:12 -0500

> With a little effort Aspell should compile just fine under
CygWin and
> MinGW. These binaries can be used by other applications since I
use a C
> interface. There for I find this the best solution.
Are you doing the Win32 port? ;-))

> > > > I've tried to express why I believe the ported code is
> > > > code. Why do you believe that it is not?
> > >
> > > Because the changes to get Aspell to compile with VC are
> > generally ugly.
> >
> > Sometimes, sometimes not.
> > Take this line from convert.hpp
> > class Convert {
> > private:
> > static const size_t memory_size = 96;
> > };
> > I believe it is none standard to initialize member data in a
> > class definition.
> You are wrong. It is allowed if it is an int type.
I've often been found wrong. What is your source? I can't afford
the $65 for a copy of the standard. Maybe your U has it?

> > The alternative is using an enum. Not ugly at all.
> >
> > enum {memory_size = 96};
> In my view yes.
> By ugly I mean VC++ specific hacks like the one above.
You know, enum has been around longer then you have. Longer that
Microsoft, I believe. I've having difficulty understanding what
you find unattractive about it. It attaches a symbolic name in
the current namespace to a numeric value. It has been supported
everywhere for decades. What's not to like?

> > What is the alternative? What is happening now is the same
> > have to be changed to port the code with each release. That
> > kind of ugly to me.
> You are welcome to submit patches. I may even approve them into
the main
> source if they are not too ugly.
> I personally do not think it is worth the effort.
If you had no VC or BC users that would be true. If it is not
portable to those platforms, you will not have VC or BC users. Is
that what you want?

reply via email to

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