Hi Przemek,
Generically speaking IMO it's the wrong solution for avoiding
bugs to uniformly require the addition of all full OS headers
to each source files, if that's what you say. Be those OS
headers windows.h files or any other OS files.
[ If that's what you're suggesting that is, your words are not
very clear to me this time to be honest, so sorry if I'm on
the wrong track here. ]
On the contrary, the leaner approach would be to isolate
windows.h dependent code as much as possible, and achieve
the same results, but without bloat and by avoiding other
problems (like unknowingly adding windows.h dependencies
to supposedly portable source code).
Since currently we're using an overlapping set of types
with windows.h, there is always the danger that code
behaviour changes, depending on whether windows.h is
included (and we're using _its_ types), or it isn't and we're
using locally defined "replicas" of those type.
I'm not sure of the xhb problem, as I'm not familiar with
its codebase, but theoretically speaking, above effect
might cause such problem.
And if we take a look on any multiplatform projects, it's
quite difficult to pick one which would do what you
suggest (= #including <windows.h> everywhere), instead,
all projects I've seen are using either standard types,
or distinctly names ones, and they not only don't
include "windows.h" in every file, but rather isolate the
Windows API dependent parts in separate directories,
or files. I'm not saying to go this far (we have HB_OS_WIN
instead), but including "windows.h" in all files, looks really
unusual, and IMO rather unnecessary and/or the wrong
(albeit easier) solution to the problem (not the xhb one,
but the one I've started the thread for).
There is yet another potential drawback of hitting the
whole project with "windows.h". "windows.h" isn't a
static entity, it has different incarnation depending on
C compiler and SDK version used, and it even changes
over time, so this wouldn't create a well defined static
environment in Harbour either.
Brgds,
Viktor
On Fri, Feb 6, 2009 at 7:59 PM, Przemyslaw Czerpak <dru...@acn.waw.pl>wrote:
> On Thu, 05 Feb 2009, Szak�ts Viktor wrote:
>
> Hi Viktor,
>
> > We should IMO never include windows.h from hbdefs.h. Besides
> > slowing down build time to a great deal, we don't do this for other
> > OS APIs either. This would also suggest that Windows API usage
> > is freely allowed in any files, which counteracts with our effort to
> > create portable code in the first place. Most of our core files don't
> > need windows.h.
>
> I do not agree.
> And now I have very good example.
> In xHarbour there is serious bug related to this subject.
> Today I lost few hours to locate it. The problem can be observed
> in SORT ON ... command but not only. Now I think that I know the
> answer for some other bug reports though without any code watching
> for them.
> Let's give some days to xharbour team to check how much time is
> necessary to locate the source of such problem and fixing it. It's
> possible to fix the problem even without knowing the reason and it
> will be also interesting to see how it will be resolved.
> It should give the real life answer if you are right or not and how
> much developers time can it cost.
> You can also try to locate it. Below is self contain example Enrico
> sent to me.
>
> best regards,
> Przemek
>
>
>
> FUNCTION MAIN()
>
> Local aStru:={{'aa','C',3,0},;
> {'bb','C',3,0}}
> ? version()
> DbCreate('testxxx',aStru)
> Use testxxx Exclusive New
>
> Append Blank
> Replace aa With 'xxx'
> Replace bb With 'xxx'
>
> Append Blank
> Replace aa With 'ggg'
> Replace bb With 'ggg'
>
> Append Blank
> Replace aa With 'kkk'
> Replace bb With 'kkk'
>
> ? "Sorting..."
> Sort On aa To testxxx1
> ? "Done"
>
> RETURN NIL
> _______________________________________________
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
