Page 1 of 1
Why wxWidgets does not have a namespace ?
Posted: Tue Jan 12, 2010 11:50 am
by shankar
i have just started learning wxWidgets .
i have a question .
why does not the whole package of the library contained in a separate namespace .This would reduce the name clashes .
another question is why macros are just every where, i mean every one will love this kind of statement---->
m_button.signal_clicked().connect(sigc::mem_fun(*this,
&ExampleWindow::on_button_clicked));
for a callback.
with regards..............
Posted: Tue Jan 12, 2010 12:07 pm
by Frank
Because wxWidgets is Oooold.
And for the developers of wx backwardscompatibility is more important than some fancy new language features.
BTW: There is a wxEvtHandler::Connect.
Another BTW: Why are you using sigc::mem_fun, when there is TR1::bind(), wich will also be in the next C++ standard? Yeah, because Sigc is old, when it was designed, there was no bind().
Posted: Tue Jan 12, 2010 12:29 pm
by shankar
Frank wrote:Because wxWidgets is Oooold.
And for the developers of wx backwardscompatibility is more important than some fancy new language features.
BTW: There is a wxEvtHandler::Connect.
Another BTW: Why are you using sigc::mem_fun, when there is TR1::bind(), wich will also be in the next C++ standard? Yeah, because Sigc is old, when it was designed, there was no bind().
You are right.
i mean i don't like MFC style programing. A modern library
design would make programming more enjoyable and more fun to do.if wxWidgets start using boost library then reuseability will increase .
with regards.........
Posted: Tue Jan 12, 2010 4:58 pm
by johncruise
That could be nice good project for the wx team... put everything into namespace just like what they did in wxPython.
Posted: Tue Jan 12, 2010 4:59 pm
by johncruise
Posted: Tue Jan 12, 2010 7:02 pm
by Frank
I don't think it's such big of a task. Just wraping every wxClass into a namespace can be done in a couple of hours.
I think the real issue here is backward compatibility. Namespaces are just thre begin. Getting rid of the macros is a much bigger task. And it breaks hundreds (if not thousands) of Projects.
So, the only solution would be to use the wx from today as backend and wrap it in an alternative API, wich uses modern C++ instead of 1995 C++. This way, old Code would still work on newer wx Versions, but for new code one could use new language features.
Well, this would be a really big task...
Posted: Wed Jan 13, 2010 2:55 am
by johncruise
If that's the only case, a directive would be sufficient enough to fix it.
Code: Select all
#if defined( _USING_NAMESPACE_ )
namespace wx {
#endif
...
// in the end of the file
#if defined( _USING_NAMESPACE_ )
}; // namespace wx
#endif
What I had in mind was even a class rename to conform with wxPython implementation. For example, instead of using the following statement in our program...
Code: Select all
#include <wx/xml/xml.h>
...
wxXmlDocument samplexmldoc;
we'll be using...
Code: Select all
#include <wx/xml/xml.h>
...
wx::XmlDocument samplexmldoc;
This would mean all class declarations (including attribute/struct/const/etc declaration outside the class), in the header and implementation file (this includes each function implementation) would have to be touched.
so instead of
Code: Select all
class WXDLLIMPEXP_XML wxXmlDocument : public wxObject
{
public:
wxXmlDocument();
that would look like
Code: Select all
namespace wx {
...
class DLLIMPEXP_XML XmlDocument : public Object
{
XmlDocument();
and the corresponding code in the implemenation file would have a similar change from
Code: Select all
wxXmlDocument::wxXmlDocument()
: m_version(wxT("1.0")), // ...
{
to
Code: Select all
namespace wx {
...
XmlDocument::XmlDocument()
: m_version( wx::T("1.0")), // ...
{
(I've had reason why I meant wx::T() instead of just using T()).
Anyhue, besides the fact that namespace is added, regression testing would play the major part of the release process. There's going to be a plenty of hit and miss around on this kinds of change. (of course the team won't deploy it without testing right? *wink* *wink*) That would be the hard and time-consuming part of it
Posted: Wed Jan 13, 2010 9:10 am
by shankar
Hi,
Yes i know that a possible api change will introduce possible portability problems with the old projects but i think a change is necessity and will have to be done at some point of time. A change is always welcome .
Looks like wxWidgets faces the same problem as fltk gui toolkit .Fltk has couple of versions like 1.3.x and 1.1.10 and the experimental 2.0 with a very clear api.
with regards.....
Posted: Wed Jan 13, 2010 3:09 pm
by Auria
My very personal opinion: it's a "nice-to-have", but there's a ***load of stuff that are more important in the "TODO-list"
Posted: Wed Jan 13, 2010 7:05 pm
by catalyn269
To be honest, I don't really see the gain in using wx::T() instead of wxT().
I understand that it can help a lot with the syntax and the name colisions but there are a lot of other things that could be improved before that, last but bot least being the documentation !
Posted: Thu Jan 14, 2010 6:14 pm
by tierra
catalyn269 wrote:I understand that it can help a lot with the syntax and the name colisions but there are a lot of other things that could be improved before that, last but bot least being the documentation !
The docs have already been
immensely improved in 2.9+.
As for namespace questions, please do a search on wx-dev for "namespace". This question has come up at least once a month for a number of years now. The benefits and drawbacks involved have been covered numerous times already.
Posted: Fri Jan 15, 2010 4:28 am
by chenbin.sh
Frank wrote:Because wxWidgets is Oooold.
And for the developers of wx backwardscompatibility is more important than some fancy new language features.
BTW: There is a wxEvtHandler::Connect.
Another BTW: Why are you using sigc::mem_fun, when there is TR1::bind(), wich will also be in the next C++ standard? Yeah, because Sigc is old, when it was designed, there was no bind().
Several months ago, some people really needed a new feature which amule (wxwidgets) didn't have. So a guy just ported some code from emule (mfc) to amule to implement it. It only took him half an hour because wxwidgets and mfc are very similar.
That proved why the wxwidget's old style is actually a strategic advantage for wxwidgets.
Re: Why wxWidgets does not have a namespace ?
Posted: Fri Jan 15, 2010 6:49 am
by tierra
shankar wrote:m_button.signal_clicked().connect(sigc::mem_fun(*this,
&ExampleWindow::on_button_clicked));
I forgot to mention that wxWidgets 2.9 actually goes a step farther than this with an even cleaner approach:
Code: Select all
m_button.Bind(wxEVT_BUTTON, &ExampleWindow::on_button_clicked);
But it's not like this is even all that bad in 2.6 and 2.8:
Code: Select all
m_button.Connect(wxID_ANY, wxEVT_COMMAND_BUTTON_CLICKED, wxCommandEventHandler(ExampleWindow::on_button_clicked), NULL, example_window_ptr);
