Re: [Flightgear-devel] New SimGear Class definition
Bernie Bright wrote: I've been using the Boost libraries (http://www.boost.org) for some time now and that is what they do. Portability is one of Boost's goals. I also wouldn't mind the opportunity to refactor the compiler configuration stuff similar to how Boost has done it. This might be a problem since boost (as far I've seen so far) doesn't use STL, which is the main reason in FlightGear for doing the things the way they are now. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear Class definition
David Megginson wrote: Erik Hofman writes: David Megginson wrote: I agree strongly on namespaces -- they'll eliminate some of our MSVC conflicts as well, especially if people avoid using global #defines whenever possible. Do all of our target compilers now support them? Please correct me if I'm wrong, but to my understanding namespaces are like classes but without the overloading and such? You're wrong. C++ namespaces are pretty-much exactly the same as Java packages -- they avoid naming conflicts by partitioning names. That way, you can have Uhm, well that was what i had in mind. Glad to have it streightened out. Thanks. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [flightgear-devel] New SimGear Class definition
Erik Hofman wrote:
Please correct me if I'm wrong, but to my understanding namespaces are
like classes but without the overloading and such?
Namespaces are just namespaces. :)
Some languages call them packages or modules, but the idea is
really simple: a symbol (function, class, global variable, whatever)
defined in a namespace is guaranteed not to clash with symbols defined
outside the namespace.
So I can (and did) write stuff like:
namespace yasim { class Propeller { ... }; };
without having to worry that anyone else in the simulator would write
a Propeller class too.
Basically, namespaces are the simple, attractive answer to all
prefix-madness that's been thrown around in C/C++ code over the past
few decades. No more FGPropeller vs. YAPropeller yuck. The developer
of a module gets to use internal names that make sense.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear Class definition
And namespaces can be closed and reopened. Classes must be contained within
a
single pair of braces.
You can have :
namespace foo {
// C++ code
}
namespace bar {
// C++ code
}
namespace foo {
// C++ code
}
in a single compilation.
You can't with classes. It is important for big projects that span over
multiple files without clumsy #include in the class definition.
I vote for namespaces
-Fred
- Original Message -
From: David Megginson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, December 18, 2001 12:46 PM
Subject: Re: [Flightgear-devel] New SimGear Class definition
Erik Hofman writes:
David Megginson wrote:
I agree strongly on namespaces -- they'll eliminate some of our MSVC
conflicts as well, especially if people avoid using global #defines
whenever possible. Do all of our target compilers now support them?
Please correct me if I'm wrong, but to my understanding namespaces are
like classes but without the overloading and such?
You're wrong. C++ namespaces are pretty-much exactly the same as Java
packages -- they avoid naming conflicts by partitioning names. That
way, you can have
class std::Foo
class fgfs::Foo
class simgear::Foo
class plib::Foo
without any naming conflict. You simply state which one you're using
at the top of the file, or add the package name explicitly, i.e.
using fgfs::Foo;
Foo myFoo;
simgear::Foo anotherFoo;
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear Class definition
Erik Hofman wrote: Hi, Today i have taken some time to take a look at the SimGear code and decided it might be time to create a new class definition. I'm not sure this is the right time to discuss about it. But then again, I always have the feeling it might not be the right time. ;-) This is a definition which i feel refelcts the layout of Simgear the best. It is not something which should be implemented before next week or even the next release. I have the feeling that it is something for after the 0.8.0 release of FlightGear. If anybody has any suggestions or comments please let me know, so i could ask Curtis to publish the best release somewhere on the website (just as a confrontation) ;-) If things have settled down (and implementing has begun) I was planning API documentation in html/what_ever form, which could make life easier for new developers. Erik Refactoring SimGear is probably a Good Thing since it has accumulated some cruft over time and some areas need reworking. However I don't think that having bogus top level classes is a good idea. Instead I propose we use namespaces. Perhaps a top level SimGear namespace with second level namespaces corresponding to the major functional divisions, as you've outlined. I think we should eliminate the Misc group as well. I've been using the Boost libraries (http://www.boost.org) for some time now and that is what they do. Portability is one of Boost's goals. I also wouldn't mind the opportunity to refactor the compiler configuration stuff similar to how Boost has done it. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear Class definition
Bernie Bright writes: Refactoring SimGear is probably a Good Thing since it has accumulated some cruft over time and some areas need reworking. However I don't think that having bogus top level classes is a good idea. Instead I propose we use namespaces. Perhaps a top level SimGear namespace with second level namespaces corresponding to the major functional divisions, as you've outlined. I think we should eliminate the Misc group as well. I've been using the Boost libraries (http://www.boost.org) for some time now and that is what they do. Portability is one of Boost's goals. I also wouldn't mind the opportunity to refactor the compiler configuration stuff similar to how Boost has done it. I agree strongly on namespaces -- they'll eliminate some of our MSVC conflicts as well, especially if people avoid using global #defines whenever possible. Do all of our target compilers now support them? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear Class definition
David Megginson wrote: Bernie Bright writes: Refactoring SimGear is probably a Good Thing since it has accumulated some cruft over time and some areas need reworking. However I don't think that having bogus top level classes is a good idea. Instead I propose we use namespaces. Perhaps a top level SimGear namespace with second level namespaces corresponding to the major functional divisions, as you've outlined. I think we should eliminate the Misc group as well. I've been using the Boost libraries (http://www.boost.org) for some time now and that is what they do. Portability is one of Boost's goals. I also wouldn't mind the opportunity to refactor the compiler configuration stuff similar to how Boost has done it. I agree strongly on namespaces -- they'll eliminate some of our MSVC conflicts as well, especially if people avoid using global #defines whenever possible. Do all of our target compilers now support them? I believe so, although some just ignore namespace declarations (gcc-2.95!). My only guideline is Boost, it targets many the same platforms we do (and some we don't). Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
