On Tue, Jul 1, 2008 at 11:12 AM, Michael Sweet <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>> [...]
>>> .. (which is why most C++ books
>>> recommend against "using" in application code...)
>>
>> Can you cite some examples? Personally I know of no authors
>> who recommend against "using" in application code, but then
>> again I haven't read a C++ book for a number of years.
>
> I'd have to go digging (I also haven't read a C++ book in a while)
> but the jist of it is that "using" only works well for a single
> namespace which can make it difficult to know which version of
> class "Widget" you are using in a particular source file, e.g.:
>
> using namespace foo;
>
> Widget a;
> ::Widget b;
> ::bar::Widget c;
>
What do you mean by "using only works well for a single namespace"?
If you have a Widget in multiple namespaces, you have the option to
* fully specify the namespace/Widget
* focus on a particular namespace/Widget (btw, you can also do "using
foo::Widget")
> Namespaces don't work any better than prefixes for preventing
> collisions, and they can also cause more collisions depending on
> how functions and classes are named.
>
prefixes don't give you the two choices above. By "cause more
collisions" do you mean "cause more ambiguity"? This can indeed
happen by careless use of "using", but that's why you have a choice.
In general, namespaces are far more flexible. Say I have to versions
of a library - one in ::mylib::version14 and the other in
::mylab::version15. I can import the "default" version of the library
into ::mylib, for use with code that doesn't care. I can also specify
what version to use for code that cares. I can test code with
different versions of the library (of that code uses "using" or a
namespace alias) by changing the version in *one* place.
> Think of FLTK's single-letter h(), w(), x(), and y() functions -
> in FLTK 1.x we put these in the Fl class, while in FLTK 2.x they
> are moved to the fltk namespace and thus will cause complications
> for any code with "using namespace foo". At least with the 1.x
> implementation the problem is limited to the Fl class methods.
You mean "using namespace fltk"? For *any* code? What if I have code
that doesn't introduce h, w, x, and y in any other namespace / scope?
And even if I do, I can still specify namespaces when resolving
ambiguities.
>
>> Perhaps you're thinking of the recommondation to avoid "using"
>> in header files?
>
> No, that is another case where you just don't want to do it.
>
Putting "using" at namespace scope in a header file can be dangerous
because including the header file can change the behavior of header
files included after it. Putting "using" in any other scope (say,
function body in the header file) is not dangerous in that way.
However, I believe you can also put a using in an anonymous namespace
like this:
// .h file:
namespace {
using namespace fltk;
}
Widget fltkwidget;
... and the "using" now only has file scope (it's not affecting any
other file). As long as your compiler knows what it's doing.
I'm not saying that any part of FLTK should or shouldn't be
implemented using namespaces. Working with namespaces can be a
problem - the programmer should understand how they work and know the
dangers. But, in the context of deciding whether there should be a
common FLTK1/FLTK2 layer that does use namespaces, and then providing
a FLTK1 compatibility layer that introduces fl_* symbols in the global
namespace, the end-programmer using the compatibility layer is not
exposed to any potential fltk namespace issues. The only people
required to know what they're doing when it comes to namespaces are
the library programmers, and that's a reasonable requirement.
FWIW, I've been an FLTK user for years and have really enjoyed the
ease of use. At some point I switched from FLTK1 to FLTK2 because I
was running into symbol conflicts with FLTK1, and I enjoyed the
slightly more modern design of FLTK2 (in particular, use of
namespaces, better naming, and use of relative coordinates for
drawing). It's been a pretty good experience, but due to the slow
progress of FLTK2 (I'm not complaining) I've been looking to switch to
something else for a long time. I am now looking into GLV
(http://mat.ucsb.edu/glv/).
Kind regards,
Stjepan
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
