In http://reviews.llvm.org/D8654#147918, @clayborg wrote:
> The main question is do we want to move each plug-in into its own namespace
> within lldb_private namespace?
>
> All code from the GDB remote process plug-in could be in:
>
> namespace lldb_private {
> namespace plugin {
> namespace process {
> namespace gdb_remote {
> // Code here
> }
> }
> }
> }
>
>
> Or just
>
> namespace lldb_private {
> namespace process_gdb_remote {
> // Code here
> }
> }
>
I am not sure if moving each plugin into its own namespace will make too much
sense because most of the plugin is very small (1 or 2 cpp file) so the
additional namespaces just adding some noise to the code without any real
benefit. What I would consider is to leave the public part of the plugins
directly in the lldb_private namespace and if a plugin require additional
classes which are private to the plugin then put them into a nested namespace
inside lldb_private.
>From the two namespace structure you suggested I would prefer the second one
>as the first one create a very deep nesting so if we have to refer to a plugin
>from a header file outside of that plugin (e.g.: from a platform plugin to a
>process plugin) then it will create extremely long fully qualified names.
If we want to go with adding nested namespace then I would also consider the
following structures because the plugins for the same OS usually tied together
in some level:
namespace lldb_private {
namespace linux {
namespace process {
// Code here
}
}
}
Or just an OS level separation (then we don't have to postfix almost all class
with the OS name as ProcessLinux, PlatformWindows, ...)
namespace lldb_private {
namespace linux {
// Code here
}
}
http://reviews.llvm.org/D8654
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
