Subject: Re: Win98 i18n Unicode fonts trouble possibly solved.
From: Mike Nordell (tamlin@algonet.se)
Date: Sat Jan 06 2001 - 16:46:20 CST
I wrote:
> > I had a quick look at your proposed patch, and though I haven't actually
> > tried it yet I think it's the best solution so far.
> >
> > The only reservation I have is the use of the static member function as
a
> > C callback. For more information, see:
> > <http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/cwg_closed.html#168>.
Saint-Denis wrote:
> I have read the article indicated above. It talk about "A C language
linkage
> is ignored for the names of class members and the member function types of
> *non-static* class member functions", I agree with that. The callback
> function is declared static in the header file, so there is no problem.
Since item #168 is named "C linkage for static member functions" I think it
has everything to do with it. The mentioned URL lists issues that have been
submitted to the C++ WG and have been closed. This is one of the closed
issues and its status is NAD (Not A Defect).
What he [Darin Adler] suggested was (probably?) along the lines that it
would be legal to write something like
class C
{
extern "C" static void c_callable_fn();
};
and then you'd be able use a pointer to that function from C code as an
ordinary C function pointer.
The part you quoted is the *suggested* new wording, but the WG *rejected*
it.
What this (AFAIK) still means is that you *can not* replace a function
pointer to a C linkage function with a pointer to a C++ static member
function and expect it to work.
In defense of the proposed patch I might add that I have yet to find a
compiler that does *not* allow this use, but AFAIK it's *not* allowed by the
language and once a *real* C++ compiler surfaces this is, by the current
wording, not C++.
If I am truly wrong regarding this issue you're *all* free to flame me. But
until that is proven I think my standpoint is correct.
Your patch also displayed another (IMHO) "problem" (by including this
function). I once read a definition of "when a memer function should be a
member function". I don't intend this as criticism, just a little anecdote
of what *I* have found useful. It went something like this:
> Generally, functions that don't access any private members (data
> or functions) of a class should not themselves be class members.
> This rule tends to simplify the class definition and improve
> _cohesion_ - the degree to which members of the class are related
> to one another. A high level of cohesion simplifies maintenance.
>
> In general, a member function should do two things at once: use
> the object's internal-state information and mechanisms, and hide
> these thing from the outside world. The second requirement that
> supported messages should implement operations in a way that's
> independent of the underlying data structures. A function that
> does not fulfill these requirements has no business being a
> member of the class.
Some might think I'm splitting hairs, but it's actually part of the
foundation of good design.
Since the proposed patch didn't touch any class data, did it have any
business being part of that class?
> Would someone be so kind as to try it on WinNT or Win98 and commit it? It
> work on my Win95 system.
I have done some testing on W2k (i.e. NT5) and Win98 and it seems to work.
I'll commit it within minutes. Since I don't have a "patch" ready for win32
would you mind checking that I got the patching right?
/Mike
This archive was generated by hypermail 2b25 : Sat Jan 06 2001 - 16:47:05 CST