On Sunday 27 July 2008 21:24, James Turner wrote:
>
> Incidentally, a minor rant - even in the past week, I've seen the 'XXX
> is being worked on, person YYY has lots of changes which they haven't
> committed for arbitrary (justifiable) reason ZZZ'. I'd like to get
> involved in hacking on some ac
James Turner wrote:
> On 27 Jul 2008, at 21:02, Tim Moore wrote:
>
>>> If you're doing that work, I'd like you to follow a *really*
>>> minimalist stance
>> i.e., if a header file only contains pointers or references to
>> another class or
>> includes them as arguments in uninstantiated templa
On 27 Jul 2008, at 21:02, Tim Moore wrote:
>> If you're doing that work, I'd like you to follow a *really*
>> minimalist stance
> i.e., if a header file only contains pointers or references to
> another class or
> includes them as arguments in uninstantiated templates (e.g.,
> osg::ref_ptr),
James Turner wrote:
> On 27 Jul 2008, at 16:41, Frederic Bouvier wrote:
>
you have no idea about the cruft windows.h is dragging.
>>> True. But I had the impression that you were adding the
>>> #if ... #include #endif to every single file,
>>> anyway. :-)
>>>
>> You are misinformed. I
On 27 Jul 2008, at 17:24, Durk Talsma wrote:
> You might be interested in some work done by Thomas Foerster. Thomas
> has done
> a fairly detailed analysis of the current interdependencies in
> FlightGear's
> include files. IIRC, Thomas has a patched version of FlightGear that
> already
> r
Hi James,
On Sunday 27 July 2008 18:06, James Turner wrote:
> - header inclusion is a very very real compilation time issue,
> especially for gcc since they're not shared (MSVC can do magic caching
> I believe). As I have time / boredom, I'm going to start reviewing
> header / source files in tu
On 27 Jul 2008, at 16:41, Frederic Bouvier wrote:
>>> you have no idea about the cruft windows.h is dragging.
>>>
>>
>> True. But I had the impression that you were adding the
>> #if ... #include #endif to every single file,
>> anyway. :-)
>>
>
> You are misinformed. I was adding config.h. Loo
Melchior FRANZ a écrit :
> * Frederic Bouvier -- Sunday 27 July 2008:
>
>> you have no idea about the cruft windows.h is dragging.
>>
>
> True. But I had the impression that you were adding the
> #if ... #include #endif to every single file,
> anyway. :-)
>
You are misinformed. I wa
* Frederic Bouvier -- Sunday 27 July 2008:
> you have no idea about the cruft windows.h is dragging.
True. But I had the impression that you were adding the
#if ... #include #endif to every single file,
anyway. :-)
m.
-
Melchior FRANZ a écrit :
> * Frederic Bouvier -- Sunday 27 July 2008:
>
>> That would mean even longer compilation time.
>>
>
> Yes, a few milliseconds. Come on! The file is loaded into the
> file cache and then takes almost *no* time for loading, and not
> more time for parsing as if it's
* Frederic Bouvier -- Sunday 27 July 2008:
> That would mean even longer compilation time.
Yes, a few milliseconds. Come on! The file is loaded into the
file cache and then takes almost *no* time for loading, and not
more time for parsing as if it's directly in the code file.
Following that argume
Oh, and while we are at it, this silliness should also disappear:
#ifndef __cplusplus
# error This library requires C++
#endif
If anyone needs to be reminded that foo.hxx is a C++ file then
there's no hope. It's just visual noise. I mean, foo.hxx isn't
an image or a sound file either, and w
Melchior FRANZ a écrit :
> * Frederic Bouvier -- Sunday 27 July 2008:
>
>> My next commit will please you. Most are gone. ;-) The real problem was
>> unneeded inclusion of GLU.h and GL.h that required windows.h
>>
>
> Sounds good. :-)
>
> I've always envisioned a "system" where every simg
* Frederic Bouvier -- Sunday 27 July 2008:
> My next commit will please you. Most are gone. ;-) The real problem was
> unneeded inclusion of GLU.h and GL.h that required windows.h
Sounds good. :-)
I've always envisioned a "system" where every simgear code file
includes "simgear.hxx" and every f
Melchior FRANZ a écrit :
> * Curtis Olson -- Sunday 27 July 2008:
>
>> It wouldn't surprise me if the standard hello world example for windows is:
>>
> [...]
>
> Wouldn't surprise me either. But I don't see why the noisy
> include lines aren't then in config.h, rather than in every
> single
* Melchior FRANZ -- Sunday 27 July 2008:
> I don't see why the noisy include lines aren't then in config.h,
> rather than in every single code file.
Ah, I remember, config.h is also loaded just conditionally. But
that's really the root of the annoyance.
m.
---
* Curtis Olson -- Sunday 27 July 2008:
> It wouldn't surprise me if the standard hello world example for windows is:
[...]
Wouldn't surprise me either. But I don't see why the noisy
include lines aren't then in config.h, rather than in every
single code file.
m.
-
On Sun, Jul 27, 2008 at 5:03 AM, James Turner wrote:
> (mostly for Fred, I guess)
Hi James,
I'll defer to Fred's expertise here, but I'm pretty sure that #include
does several magic things that are required for a clean compile
on the windows platform.
It wouldn't surprise me if the standard h
(mostly for Fred, I guess)
Whilst cleaning up various headers and includes, I've noticed quite a
few files including windows.h, via a section like:
#ifdef HAVE_WINDOWS_H
# include
#endif
Many of these files have no obvious reason to be relying on platform
specific code, and I think that th
19 matches
Mail list logo
