Why wxWidgets does not have a namespace ?
Why wxWidgets does not have a namespace ?
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..............
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..............
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().
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().
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.........
-
- Earned a small fee
- Posts: 24
- Joined: Wed May 07, 2008 4:29 pm
- Location: Sunnyvale, CA
- Contact:
-
- Earned a small fee
- Posts: 24
- Joined: Wed May 07, 2008 4:29 pm
- Location: Sunnyvale, CA
- Contact:
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...
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...
-
- Earned a small fee
- Posts: 24
- Joined: Wed May 07, 2008 4:29 pm
- Location: Sunnyvale, CA
- Contact:
If that's the only case, a directive would be sufficient enough to fix it.
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...
we'll be using...
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
that would look like
and the corresponding code in the implemenation file would have a similar change from
to
(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
Code: Select all
#if defined( _USING_NAMESPACE_ )
namespace wx {
#endif
...
// in the end of the file
#if defined( _USING_NAMESPACE_ )
}; // namespace wx
#endif
Code: Select all
#include <wx/xml/xml.h>
...
wxXmlDocument samplexmldoc;
Code: Select all
#include <wx/xml/xml.h>
...
wx::XmlDocument samplexmldoc;
so instead of
Code: Select all
class WXDLLIMPEXP_XML wxXmlDocument : public wxObject
{
public:
wxXmlDocument();
Code: Select all
namespace wx {
...
class DLLIMPEXP_XML XmlDocument : public Object
{
XmlDocument();
Code: Select all
wxXmlDocument::wxXmlDocument()
: m_version(wxT("1.0")), // ...
{
Code: Select all
namespace wx {
...
XmlDocument::XmlDocument()
: m_version( wx::T("1.0")), // ...
{
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
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.....
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.....
-
- Experienced Solver
- Posts: 66
- Joined: Wed Dec 12, 2007 2:40 pm
- Contact:
- tierra
- Site Admin
- Posts: 1355
- Joined: Sun Aug 29, 2004 7:14 pm
- Location: Salt Lake City, Utah, USA
- Contact:
The docs have already been immensely improved in 2.9+.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 !
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.
-
- Experienced Solver
- Posts: 64
- Joined: Fri Apr 17, 2009 7:15 am
- Location: Sydney, Australia
- Contact:
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.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().
That proved why the wxwidget's old style is actually a strategic advantage for wxwidgets.
help me, help you.
http://blog.binchen.org
http://blog.binchen.org
- tierra
- Site Admin
- Posts: 1355
- Joined: Sun Aug 29, 2004 7:14 pm
- Location: Salt Lake City, Utah, USA
- Contact:
Re: Why wxWidgets does not have a namespace ?
I forgot to mention that wxWidgets 2.9 actually goes a step farther than this with an even cleaner approach:shankar wrote:m_button.signal_clicked().connect(sigc::mem_fun(*this,
&ExampleWindow::on_button_clicked));
Code: Select all
m_button.Bind(wxEVT_BUTTON, &ExampleWindow::on_button_clicked);
Code: Select all
m_button.Connect(wxID_ANY, wxEVT_COMMAND_BUTTON_CLICKED, wxCommandEventHandler(ExampleWindow::on_button_clicked), NULL, example_window_ptr);