RE: [ft-devel] Re: const problems

[Turner, David]

Please please do not make the sources more complex than they
already are. 

Contrary to popular advice, putting "const" everywhere is
_not_ important. It's just semantic sugar, and a hint to
developers that can also be placed in the documentation of
a given function. Of course we'd all be better if it was
there in the first place, but they have strictly no impact
on performance or portability.

Using additionnal macros to just deal with this seems a
bit too much.

- David Turner
- The FreeType Project  (www.freetype.org)


> -----Message d'origine-----
> De : address@hidden
> [mailto:address@hidden 
> la part de
> Werner LEMBERG
> Envoyé : lundi 6 juin 2005 18:20
> À : address@hidden
> Cc : address@hidden
> Objet : [ft-devel] Re: const problems
> 
> 
> 
> > As to 'const' problems, I understand that adding such a change into
> > public parts of FT can break API compatibility.  But I also had a
> > lot of problems when writing C++ wrapper around FreeType subsystems
> > with original interfaces, without the 'const'.
> > 
> > I would like to ask you, whether it is still possible to adopt my
> > patches into FT-2.1.10 as a 'non-fundamental' change?
> 
> I have an idea: Let's introduce a macro `CONST' which is placed into
> the public API header files where a `const' is missing currently.  By
> default, this is defined as
> 
>   #ifndef CONST
>   # define CONST
>   #endif
> 
> for backwards compatibility, probably in ftconfig.h (note that there
> is more than a single version of this file, depending on the platform)
> or in ftoption.h.  As soon as a new major release of FreeType is out,
> those `CONST' are converted to `const'.
> 
> What do you think?  Kirill, can you implement that?  We would also
> need a small note in the docs/CHANGES file...
> 
> 
>     Werner
> 
> 
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/freetype-devel
>