[boost] RE: Re: Filesystem: create_directories
Reid Sweatman wrote: >> > Another option might be: "create_directory_and_parents" >> > That name is longer than "create_directories" although it better >> > describes the function. >> >> I like "create_directory_path" > That one's good, and captures the essential distinction well. Other > possibles: "create_full_directory," or "create_rooted_directory." Dunno. > On whole, I might prefer your choice. Although it again lengthens the > name, "create_directory_and_path" captures another minor piece of the > distinction. You could also play with the distinction (none save semantic > in most file systems) between "pathname" and "filename;" a filename is > usually just the thing at the leaf-terminal end of the path (and needn't > be a "file," save as a directory is often actually implemented as such), > while the pathname is the full Monty. FWIW, I don't like - "create_full_directory", because I don't understand what it means for directory to be full. "Full of files" is one interpretation which is not correct. - "create_rooted_directory", because I don't know what's "rooted" directory. - "create_directory_and_path", because how if one can create directory, one can name that directory, and the path should already exist. So, to summarize, I've no problem with the current name that I've introduced. Of other suggestions "create_directory_and_parents" looks best to me. "ensure_directory_exists" does not imply any operational semantic (i.e. the name does not say that the directory will be created. One might expect exception to be thrown if dir does not exist). "demand_directory" is good. One problem is that "demand" still does not communicate to me that something will be created. - Volodya > > In the original scheme, I would think the problem with > "create_directories" is that it would seem to imply (to me, at any rate) > the creation of multiple > directories at the same depth in the file system. Anyway, them's my > kibitz's. > > Reid Sweatman > > > ___ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Sudden VC6 ICEs in BGL code
David Abrahams wrote: > David Abrahams <[EMAIL PROTECTED]> writes: > >> Jeremy Siek <[EMAIL PROTECTED]> writes: >> >>> I seem to remember the named parameters mechanism being fragile >>> under VC6. >> >> After a painstaking binary search in recent CVS states for the ICE, I >> narrowed it down to: > > > > Worked around now in CVS. Had no idea my innocent change will break anything. Why doesn't vc6 like declarations of static methods inside class? - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Filesystem: create_directories
David Abrahams wrote: > The documentation for create_directories makes no sense. It says > only: > > void create_directories( const path & ph ); > > Precondition: ph.empty() || > forall p: p == ph || is_parent(p, ph): is_directory(p) || !exists( p ) > > Postcondition: exists(ph) && is_directory(ph) > > It looks as though this is the same as create_directory, but has a > weird precondition. Sure. It has the (almost) the same postcondition, but has waeker precondition: the parent directories are not required to exist. > I swear I was *completely* baffled by its > purpose until I looked at the header file. I'd say that pre/post conditions are just correct. Maybe more docs can be added. > The comment in the header file describes it pretty well, though. Ehm... only postcondition there is not correct: is_empty(ph) is not guaranteed. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] C++ Builder 6 and Boost Generic Graph Library
awhile ago I tried to compile this simple program:
#include
int main (){
return 0;
}
and Borland C++ Builder 6 refuse to compile.
I have track the problem and it seemed that Borland C++ builder has problem with template partial specialization with constant. The program below also refuse to compile
template< class T>
class A{
typedef T type;
};
template
class A< const T>{
typedef T consttype;
};
int main (){
return 0;
}
does anybody has the workaround with this ? By the way, I use Boost version 1.30.0 ( the latest)
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
[boost] Re: Re: Re: Re: Re: Re: Re: Re: Re: GUI/GDI template library
brock wrote: [...] >> Is it possible to associate widget instances with functions? > > Like with boost::bind? > >button b; >edit e; > >button.set_on_pushed(boost::bind(&edit::disable_window, &e)); > > (This is not how my library class names looks now, but how they will > when rewritten) Looks a lot better this way IMO. Philippe ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Re: Re: Re: Re: GUI/GDI template library
- Original Message -
From: "Philippe A. Bouchard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, August 03, 2003 9:33 PM
Subject: [boost] Re: Re: Re: Re: Re: Re: Re: Re: GUI/GDI template library
> brock wrote:
>
> [...]
>
> > What do you mean by "official macros"? The only macros in my code
> > are in
> > the implementation, you shouldn't see any in user code.
>
> Sorry I guess I have misinterpreted BEGIN_MESSAGE_MAP() in
> boost_gui_test.cpp.
Oh, that is auto generated MSVC 6 stuff.
[...]
> > If you're talking about message notifications, I use something like:
> >
> >struct window {
> >
> > void set_on_change(boost::funtion0);
> >
> > void set_on_character_typed(boost::function1);
> >};
>
> Is it possible to associate widget instances with functions?
Like with boost::bind?
button b;
edit e;
button.set_on_pushed(boost::bind(&edit::disable_window, &e));
(This is not how my library class names looks now, but how they will when
rewritten)
Brock
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: Re: Re: Re: GUI/GDI template library
brock wrote:
[...]
> What do you mean by "official macros"? The only macros in my code
> are in
> the implementation, you shouldn't see any in user code.
Sorry I guess I have misinterpreted BEGIN_MESSAGE_MAP() in
boost_gui_test.cpp.
> I'm pretty
> sure
> they use macros in similar situations in boost::tuple and
> boost::function.
Macros should be used only for compiler-specific definitions, compilation
options or to simplify complex recursive typelists for internal usages. My
0.02$.
> In the case of the GUI library though, I think you're correct in
> saying that overloading an operator would lead to a more elegant
> solution and I can get rid of all of the macros. I did really enjoy
> the boost preprocessor lib though.
>
> If you're talking about message notifications, I use something like:
>
>struct window {
>
> void set_on_change(boost::funtion0);
>
> void set_on_character_typed(boost::function1);
>};
Is it possible to associate widget instances with functions?
Philippe
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Re: Re: Re: GUI/GDI template library
- Original Message -
From: "Philippe A. Bouchard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, August 03, 2003 8:40 PM
Subject: [boost] Re: Re: Re: Re: Re: Re: Re: GUI/GDI template library
[...]
> Find a way not to rely on "official macros". Those are false hopes.
What do you mean by "official macros"? The only macros in my code are in
the implementation, you shouldn't see any in user code. I'm pretty sure
they use macros in similar situations in boost::tuple and boost::function.
In the case of the GUI library though, I think you're correct in saying that
overloading an operator would lead to a more elegant solution and I can get
rid of all of the macros. I did really enjoy the boost preprocessor lib
though.
If you're talking about message notifications, I use something like:
struct window {
void set_on_change(boost::funtion0);
void set_on_character_typed(boost::function1);
};
Brock
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: Re: Re: GUI/GDI template library
brock wrote: [...] >> - "boost_gui_test/dialog.cpp" is pretty cool... I like it for its >> simplicity but the syntax could be even more elegant. Try some >> operator << instead > of >> a macro defined number of parameters. Nobody likes this idea. > > Probably true, I think I was just looking for an excuse to try the > preprocessor library :) Or an array of rows defined a compile-time, a list or rows at run-time, etc. >> - Work on the macro defined WxWindows signal / slot mechanism; this >> is ugly. Maybe the suggestions I've sent to Mr. Slettebo could help. > > I'll have to look into that. Most of the signal/slot stuff I do (if > I get your intention correctly) relies on boost::function<>. Find a way not to rely on "official macros". Those are false hopes. Philippe ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Filesystem: create_directories
Thomas Witt <[EMAIL PROTECTED]> writes: > I'de like to get away from create. As I understand it, what we really > want is to make sure a directory path actually exists without > necessarily creating any directories. To me calling a create function > for something that already exists should be an error. I can't see a > reasonable way to have these semantics with create_directories. > > What about something like this: > > ensure_path_exists(path); I have a word I use in scenarios like this: "demand". demand_directory(path) "Demand" is not a perfect fit, but if you treat it like a term of art, it works. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Re: Re: GUI/GDI template library
- Original Message - From: "Philippe A. Bouchard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, August 03, 2003 8:04 PM Subject: [boost] Re: Re: Re: Re: Re: Re: GUI/GDI template library > brock wrote: > > [...] > > > Having a library with an interface that > > leverages the advantages of modern C++ saves me a lot more time than > > what I spent making the library. > > That is true. Maintenance is important also. > > [...] > > > I've been proposing, something like: > > > >gui_manager app = row( "name", edit(&employee::ssn)); > > > >app.set_data(get_employee()); > > > > It is in the files section with the name boost_gui.zip. If someone > > would at least tell me that my ideas stink I would feel better :) > > Yeah... I am not a Boost consultant but here goes a little overview: Thanks for taking a look! > > - You're "boost_gui/Functors.h" is already defined in ... partly > specialize it. A lot of stuff in the implementation is out of date. Some of it was even written in the dark times before I found boost. > > - "boost_gui_test/dialog.cpp" is pretty cool... I like it for its simplicity > but the syntax could be even more elegant. Try some operator << instead of > a macro defined number of parameters. Nobody likes this idea. Probably true, I think I was just looking for an excuse to try the preprocessor library :) > > - Work on the macro defined WxWindows signal / slot mechanism; this is ugly. > Maybe the suggestions I've sent to Mr. Slettebo could help. I'll have to look into that. Most of the signal/slot stuff I do (if I get your intention correctly) relies on boost::function<>. Brock ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: Re: GUI/GDI template library
brock wrote: [...] > Having a library with an interface that > leverages the advantages of modern C++ saves me a lot more time than > what I spent making the library. That is true. Maintenance is important also. [...] > I've been proposing, something like: > >gui_manager app = row( "name", edit(&employee::ssn)); > >app.set_data(get_employee()); > > It is in the files section with the name boost_gui.zip. If someone > would at least tell me that my ideas stink I would feel better :) Yeah... I am not a Boost consultant but here goes a little overview: - You're "boost_gui/Functors.h" is already defined in ... partly specialize it. - "boost_gui_test/dialog.cpp" is pretty cool... I like it for its simplicity but the syntax could be even more elegant. Try some operator << instead of a macro defined number of parameters. Nobody likes this idea. - Work on the macro defined WxWindows signal / slot mechanism; this is ugly. Maybe the suggestions I've sent to Mr. Slettebo could help. [...] Philippe ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: GUI/GDI template library
Philippe A. Bouchard wrote: [...] > emit (a.sigdone)(99); Let's call it the placement "emit" operator ;) Just joking... Philippe ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Re: GUI/GDI template library
Personally I would much rather start from scratch. I want something that is boost from the ground up, not a project that has a code so old it supports MSVC 4.0. Who knows if the folks at wxWindows or elsewhere have the same goals as boost. Don't they have an open source license? Developing a GUI library from the ground up will be hard, but worthwhile. Developing a GUI applications is also hard. Having a library with an interface that leverages the advantages of modern C++ saves me a lot more time than what I spent making the library. From what I've seen of the interface to wxWindows, I don't think I'd be gaining much over MFC. Anyway, I do have a library whose interface (if not yet implementation) is platform independent. I haven't gotten any feedback about whether anyone likes the library itself, or the syntax I've been proposing, something like: gui_manager app = row( "name", edit(&employee::ssn)); app.set_data(get_employee()); It is in the files section with the name boost_gui.zip. If someone would at least tell me that my ideas stink I would feel better :) As soon as I get everything upgraded to VC 7 I'm going to rewrite it with the idea of submitting it to boost for a review. I've never written a GUI for another platform but if no one wants to colaborate I'll do that too. Any suggestions? Developing this will be work, but it is not rocket science. - Original Message - From: "Philippe A. Bouchard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, August 03, 2003 7:02 PM Subject: [boost] Re: Re: Re: Re: Re: GUI/GDI template library > Rene Rivera wrote: > > [2003-08-03] Philippe A. Bouchard wrote: > > > >> WxWindows don't have any intermediate compiler but the end user > >> syntax is not attractive for the signal / slot mechanism (macros). > > > > Yes, and no. You can use the macros if you like that sort of stuff. > > But the signal/slot mecahnism is just as easilly available directly > > with the "Connect" interface. Thruth is WX doesn't need most, if not > > all, of the macros it uses. If only you could convice the WX > > developers of that ;-) > > ... other issues: > > - Qt is more popular than WxWindows because it is commercial: > - they can support their product; > - they can affort to sponsor their product; > - people won't have to install yet another library; > - it is binary compatible with previous versions also. > > But I think WxWindows developpers can affort to completely rewrite their > engine if a better syntax is available. Yours to decide. > > > > Philippe > > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: GUI/GDI template library
Rene Rivera wrote: > [2003-08-03] Philippe A. Bouchard wrote: > >> WxWindows don't have any intermediate compiler but the end user >> syntax is not attractive for the signal / slot mechanism (macros). > > Yes, and no. You can use the macros if you like that sort of stuff. > But the signal/slot mecahnism is just as easilly available directly > with the "Connect" interface. Thruth is WX doesn't need most, if not > all, of the macros it uses. If only you could convice the WX > developers of that ;-) ... other issues: - Qt is more popular than WxWindows because it is commercial: - they can support their product; - they can affort to sponsor their product; - people won't have to install yet another library; - it is binary compatible with previous versions also. But I think WxWindows developpers can affort to completely rewrite their engine if a better syntax is available. Yours to decide. Philippe ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: GUI/GDI template library
Trying to continue GUI libraries review ( FLTK, WxWin ) Any ideas about VCF ( visual component framework ) sourceforge project ? Its original idea was taken from Borland C++ Builder. Unfortunately, this IDE and VCL (pascal GUI library used by Delphi and c++ builder) doesn't allow to use c++ features like templates and multiple inheritance in gui components. Anyway idea is great. VCF project is trial to fix this drawback. They already have new IDE and GUI library more c++ friendly and portable. Despite it is relatively new project, it looks great. Can it be used somehow ? Or more lazy choice : ask developers to port it to boost ?:)) It is developed under BSD license. I'm not expert in licenses :(. If somebody can shed light on this license thanks. regards, bohdan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: GUI/GDI template library
How about this one:
#include
#include
#include
using namespace std;
struct Object
{
};
template
struct signal : vector< pair >
{
typedef typename vector< pair >::value_type
value_type;
template
void connect(Object & o, T U::* s)
{
push_back(value_type(& o, static_cast(s)));
}
};
#define emit(SIGNAL) for (size_t i = 0; i != SIGNAL.size(); ++ i)
(SIGNAL[i].first->*SIGNAL[i].second)
// Usage example:
struct A : Object
{
signal sigdone;
};
struct B : Object
{
void slot_bip(int a)
{
cout << __PRETTY_FUNCTION__ << ": " << a << endl;
}
void slot_refresh(int a)
{
cout << __PRETTY_FUNCTION__ << ": " << a << endl;
}
};
int main()
{
A a;
B b;
a.sigdone.connect(b, & B::slot_bip);
a.sigdone.connect(b, & B::slot_refresh);
emit(a.sigdone)(99);
}
Philippe
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Filesystem: create_directories
David Abrahams wrote: Dave Gomboc <[EMAIL PROTECTED]> writes: Ah, naming again. My favourite. :-) It's not my favourite, but it matters. I like create_path_and_directory. I prefer this order of the two terms because logically the path exists before the directory itself does. create_full_path(path, 'd') create_full_path(path, 'f') I'de like to get away from create. As I understand it, what we really want is to make sure a directory path actually exists without necessarily creating any directories. To me calling a create function for something that already exists should be an error. I can't see a reasonable way to have these semantics with create_directories. What about something like this: ensure_path_exists(path); Thomas ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: GUI/GDI template library
... or the following with the "emit" keyword defined as the only macro. The
function connect() could be simplified but I won't go further because it is
not pure C++. You take the decisions from here:
#include
#include
#include
using namespace std;
struct Object
{
};
template
struct signal : vector< pair >
{
typedef typename vector< pair >::value_type
value_type;
void connect(Object * p, T Object::* s)
{
push_back(value_type(p, s));
}
};
#define emit(SIGNAL) for (size_t i = 0; i != SIGNAL.size(); ++ i)
(SIGNAL[i].first->*SIGNAL[i].second)
// Usage example:
struct A : Object
{
signal sigdone;
};
struct B : Object
{
void slot_bip(int a, ...)
{
cout << __PRETTY_FUNCTION__ << ": " << a << endl;
}
void slot_refresh(int a, ...)
{
cout << __PRETTY_FUNCTION__ << ": " << a << endl;
}
};
int main()
{
A a;
B b;
a.sigdone.connect(& b, (void (Object::*)(int)) & B::slot_bip);
a.sigdone.connect(& b, (void (Object::*)(int)) & B::slot_refresh);
emit (a.sigdone)(99);
}
Philippe
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: GUI/GDI template library
Here is a better example. I am breaking standards when upcasting a pointer
to member though ((void (B::*)(int) -> (void (Object::*)(int))). This is
why I never proposed it ;)
#include
#include
#include
using namespace std;
struct Object
{
};
template
struct signal : list< pair >
{
typedef typename list< pair >::value_type
value_type;
void connect(Object * p, T Object::* s)
{
push_back(value_type(p, s));
}
template
void emit(U const & u, V const & v)
{
for (typename list::iterator i = begin(); i != end(); ++ i)
{
(i->first->*i->second)(u, v);
}
}
template
void emit(U const & u)
{
for (typename list::iterator i = begin(); i != end(); ++ i)
{
(i->first->*i->second)(u);
}
}
void emit()
{
for (typename list::iterator i = begin(); i != end(); ++ i)
{
(i->first->*i->second)();
}
}
};
// Usage example:
struct A : Object
{
signal sigdone;
};
struct B : Object
{
void slot_bip(int a, ...)
{
cout << __PRETTY_FUNCTION__ << ": " << a << endl;
}
void slot_refresh(int a, ...)
{
cout << __PRETTY_FUNCTION__ << ": " << a << endl;
}
};
int main()
{
A a;
B b;
a.sigdone.connect(& b, (void (Object::*)(int)) & B::slot_bip);
a.sigdone.connect(& b, (void (Object::*)(int)) & B::slot_refresh);
a.sigdone.emit(99);
}
Philippe
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: GUI/GDI template library
Terje Slettebø wrote:
[...]
> It's also possible to do the signal/slot without macros on wxWindows.
> See here (http://www.wxwindows.org/hworld2.txt) for an example. It's
> all done in standard C++, without any macros.
It is a lot better this way, I was not aware of this new syntax. But it
seems you still need global IDs to refer to the members... A signal is
really a list of pointer to members, maybe the following could simplify the
situation. This is an example, but the signal<>::emit should be overloaded
for N template parameters, N times:
#include
#include
#include
using namespace std;
struct Object
{
};
template
struct signal : list< pair >
{
typedef pair type;
void emit(...)
{
for (typename list::iterator i = begin(); i != end(); ++ i)
{
(i->first->*i->second)();
}
}
};
struct A : Object
{
signal sigdone;
};
struct B : Object
{
void slot_bip()
{
cout << __PRETTY_FUNCTION__ << endl;
}
void slot_refresh()
{
cout << __PRETTY_FUNCTION__ << endl;
}
};
int main()
{
A a;
B b;
a.sigdone.push_back(make_pair(& b, (void (Object::*)(...)) & B::slot_bip));
a.sigdone.push_back(make_pair(& b, (void (Object::*)(...)) &
B::slot_refresh));
a.sigdone.emit();
}
> The syntax is similar to Qt's signal/slot mechanism, but without any
> preprocessor/intermediate compiler (MOC) needed.
>
> Here's a version using macros, which then resembles MFC
> (http://www.wxwindows.org/hworld.txt).
Yeah, this is what I was talking about.
Philippe
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: GUI/GDI template library
>From: "Philippe A. Bouchard" <[EMAIL PROTECTED]> > WxWindows don't have any intermediate compiler but the end user syntax is > not attractive for the signal / slot mechanism (macros). It's also possible to do the signal/slot without macros on wxWindows. See here (http://www.wxwindows.org/hworld2.txt) for an example. It's all done in standard C++, without any macros. The syntax is similar to Qt's signal/slot mechanism, but without any preprocessor/intermediate compiler (MOC) needed. Here's a version using macros, which then resembles MFC (http://www.wxwindows.org/hworld.txt). Naturally, one might use Boost.Signals for a boostified version. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: GUI/GDI template library
[2003-08-03] Philippe A. Bouchard wrote: >WxWindows don't have any intermediate compiler but the end user syntax is >not attractive for the signal / slot mechanism (macros). Yes, and no. You can use the macros if you like that sort of stuff. But the signal/slot mecahnism is just as easilly available directly with the "Connect" interface. Thruth is WX doesn't need most, if not all, of the macros it uses. If only you could convice the WX developers of that ;-) -- grafik - Don't Assume Anything -- rrivera (at) acm.org - grafik (at) redshift-software.com -- 102708583 (at) icq ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: GUI/GDI template library
E. Gladyshev wrote:
> --- Rainer Deyke <[EMAIL PROTECTED]> wrote:
>> For a GUI library to be useful to me, it would need
>> to support custom
>> physical GUI layers. I would then write my own
> [...]
>> full-screen multimedia. I
>> realize that my needs are unusual, and boost::gui
>> may be unable to
>> accomodate them.
>
> It seems strange to me, why are you willing to give up
> on your requirements. What is so unusual about them? I
> believe boost::gui must accomodate them and it can.
> Your requirements are very reasonable IMHO.
Ok.
>> Nonetheless I also dislike the idea of
>> PhysicalGUILayer as a template
>> parameter to all GUI elements.
>
> PhysicalGUILayer is great for your requirements. Why
> do you dislike it?
There's the compile-time issue, but there's also the physical dependency
between the high-level GUI structure and the physical GUI layer. I would
prefer a system where they are kept independent. This would have the
benefit of allowing the phyisical GUI layer to be specified at runtime.
top_level_window = create_top_level_window();
if (using_wx_windows) {
wx_gui_layer::run(top_level_windows);
} else {
win32_gui_layer::run(top_level_windows);
}
>> It violates the
>> principle of Once and Only
>> Once.
>
> You can use a default template parameter for the
> PhysicalGUILayer and define it only once in your
> program.
The GUI code would still be physically bound to a single physical GUI layer.
--
Rainer Deyke - [EMAIL PROTECTED] - http://eldwood.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: GUI/GDI template library
Pavel Vozenilek wrote: [...] > Here is interesting review of five GUI toolkits, including wxWindows: > http://freshmeat.net/articles/view/928/ For the Qt toolkit, they kinda forgot to mention that they work in parallel with the KDE project (http://kde.org) so they have a huge open source support for their development extensions (class KHTML, ...). But their moc compiler creates intermediate files and it could be annoying sometimes. WxWindows don't have any intermediate compiler but the end user syntax is not attractive for the signal / slot mechanism (macros). On the other hand, I really like their free bundled IDE + MinGW + WxWindows package under Microsoft Windows: Dev-C++ (http://www.bloodshed.net/). Philippe ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Filesystem: create_directories
Dave Gomboc <[EMAIL PROTECTED]> writes: > Ah, naming again. My favourite. :-) > > I like create_path_and_directory. I prefer this order of the two terms > because logically the path exists before the directory itself does. create_full_path(path, 'd') create_full_path(path, 'f') ?? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Preparing 1.30.1 Release
>I've applied the first two; I'm not comfortable applying the regex >patches myself; it takes someone who knows the library to verify that >they're OK. John can do it, though, as far as I'm concerned. done, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Misha Bergal <[EMAIL PROTECTED]> writes: > "Misha Bergal" <[EMAIL PROTECTED]> writes: > >> "David Abrahams" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> > >> > Thanks. The hyperlinks to test failure logs don't ever scroll to the >> > appropriate section of the output on IE6. > Fixed >> The compiler_status changes from main trunk need to be integrated back to >> RC_1_30_0 . >> If I don't hear from somebody about it, I will just apply patch locally. > Done Could you possibly do another regression run? There have been quite a few little changes since the last one. Thanks, Misha! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: GUI/GDI template library
"Terje Slettebø" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Make no mistake - this is a lot of work, too. However, it may be much less > work than creating one from scratch. What do we want - vaporware of a Boost > GUI library coming "real soon now", perhaps not appearing for many years, if > ever, due to the amount of work, or adapting an existing solution and being > able to use it here and now, with a boostified version to come? > Every project needs to start and can be labeled 'vaporware' at this moment. > My goal was to include > existing libraries in the discussion, and that has been met. > Exhaustive list of toolkits is on: http://www.free-soft.org/guitool/ Here is interesting review of five GUI toolkits, including wxWindows: http://freshmeat.net/articles/view/928/ /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: Re: Filesystem: create_directories
> > > > create_directory > > > > and > > > > create_directories > > > > > > Another option might be: "create_directory_and_parents" > > > That name is longer than "create_directories" although it better > > > describes the function. > > > > I like "create_directory_path" > > That one's good, and captures the essential distinction well. Other > possibles: "create_full_directory," or "create_rooted_directory." > Dunno. On whole, I might prefer your choice. Although it again > lengthens the name, "create_directory_and_path" captures another minor > piece of the distinction. You could also play with the distinction (none > save semantic in most file systems) between "pathname" and "filename;" a > filename is usually just the thing at the leaf-terminal end of the path > (and needn't be a "file," save as a directory is often actually > implemented as such), while the pathname is the full Monty. > > In the original scheme, I would think the problem with > "create_directories" is that it would seem to imply (to me, at any rate) > the creation of multiple directories at the same depth in the file > system. Anyway, them's my kibitz's. Ah, naming again. My favourite. :-) I like create_path_and_directory. I prefer this order of the two terms because logically the path exists before the directory itself does. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: GUI/GDI template library
>From: "Rob & Lori" <[EMAIL PROTECTED]> > E. Gladyshev wrote: > > >--- Edward Diener <[EMAIL PROTECTED]> wrote: > > > >>As you have pointed out in the rest of your post, it > >>may prove more > >>worthwhile to work with the developers which already > >>exist for a free > >>cross-platform framework like wxWindows, in order to > >>encourage them to use > >>more modern C++ idioms > > > >I agree with this suggestion. I am wondering how > >realistic would it be? As I quoted from their roadmap, there are plans to do this - at least changing the components used to standard components, such as changing wxString to std::sstring. After all, the library originated long before there was a standard, and a standard string. > Personally I'm not certain I like that idea. WxWindows is much more > than just multi-platform GUI. This means when you only need the GUI > you'll be linking to everything else in their library, which increases > your code size. I'm aware of that. However, with boostification/transforming it to use modern C++ idioms, one might also change it to use existing standard components for these, or Boost components. One might also omit parts not strictly belonging to a GUI library, such as database access. Or one could include it, if no Boost library supports that at the time. Make no mistake - this is a lot of work, too. However, it may be much less work than creating one from scratch. What do we want - vaporware of a Boost GUI library coming "real soon now", perhaps not appearing for many years, if ever, due to the amount of work, or adapting an existing solution and being able to use it here and now, with a boostified version to come? Anyway, it was just a thought. wxWindows is already tested and debugged - and has been used in real-world projects. It's shown its worth. By the way, dynamic layout have been mentioned (like layout managers in Java), and wxWindows support these, as well. As Alec Ross pointed out, there's also an XML-based portable resource format (XRC) (http://www.wxwindows.org/manuals/2.4.0/wx478.htm), and a resource editor for it. > Besides, I believe it would take more effort to change all the existing > WxWindows code to use modern C++ techniques (which they would probably > be against for backwards compatibility reasons) than it would to create > one from scratch. This might also be. It is something to consider. My goal was to include existing libraries in the discussion, and that has been met. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: GUI/GDI template library
>From: "Edward Diener" <[EMAIL PROTECTED]> > Terje Slettebø wrote: > >> From: "Edward Diener" <[EMAIL PROTECTED]> > > > >> Add to this the fact that nearly every C++ programmer already works > >> with a framework library depending on his implementation of choice. > >> On Windows alone I know of WTL, ATL, MFC, OWL, VCL, wxWindows, QT, > >> and no doubt > > others > >> about which I have no knowledde, each tied very closely to a > >> particular > > C++ > >> compiler, IDE, and implementation. > > > > I just wanted to point out that several of these, Qt and wxWindows, > > are cross-platform, so they are not tied to any specific compiler or > > platform. wxWindows is also Open Source, and I've good experience > > with the little I've used it. It's very easy to get up and running > > with it (at least it was on Windows). snipped... > > I see you are supporting my main point which was that re-inventing a GUI > framework for Boost, with both many platform dependent and cross-platform > frameworks already in place and very popular with most C++ programmers, will > be duplicating functionality which already exists. I do realize that most of > these frameworks do not use template techniques but that doesn't make them > necessarily any less popular with their many users. Also, as I pointed out, > the amount of work necessary to implement an effective GUI framework is > enormous, given the differences in GUI controls and GDI-like functionality > on the major OSs. I complately agree. That was also an unspoken point of my posting - that there's an enourmous amount of work to do this. Just wrapping/emulating _one_ platform is a lot of work. I've been working on a Windows/Direct3D wrapper, myself, which wraps the Win32 API, and especially due to the low-level nature of this API, it's a lot of work to do so. Since I discovered wxWindows, I've preferred to use that, instead, than duplicating all the work that has gone into cross-platform GUI toolkits/frameworks like wxWindows. > I am certainly not against the OP trying to do something like this for Boost > but I think that is naive to assume that one can create such a Boost > templated cross-platform framework without a tremendous amount of work and > time spent invesigating the GUI and graphics APIs of a number of OSs. OTOH > if the consensus is that such a framework will work only by having the end > user plug-in to it classes with the appropriate functionality for a generic > idea, such as a listbox let's say, there will be enormous amount of work for > the end-user to do and even then the templated listbox may provide hooks > into only a very small amount of functionality which listboxes represent on > that user's particular OS. > > As you have pointed out in the rest of your post, it may prove more > worthwhile to work with the developers which already exist for a free > cross-platform framework like wxWindows, in order to encourage them to use > more modern C++ idioms which will make using their framework easier for > end-users, than attempting to recreate one all over again. Boostifying > wxWindows and having Boost developers and wxWindows talking to each other > about better techniques for making wxWindows easier to program may be much > more worthwhile than re-creating yet another GUI/Graphics framework. That has also been my thought. As we've both pointed out, greating such a library is a lot of work. There's a reason there's not yet a Boost.GUI. There's a lot of developers at the wxWindows project, for example, showing this. I just wanted to point out this point, too, to consider existing libraries, as well. Boost has several times adopted libraries originating elsewhere, and with an existing body of developers, as well, e.g. Boost.Spirit. The other mentioned cross-platform GUI similar in capability to wxWindows, Qt, is not Open Source - there's an older Open Source non-commercial Windows version, but not the more recent one, and not for commercial use. That makes its license incompatible with Boost. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
David Abrahams <[EMAIL PROTECTED]> writes: > I am slightly concerned about the number of unexpected failures with > intel7.1-stlport. Is there a configuration problem? Yes, there is. The main trunks intel-win32-tools.jam,1.28 enables wchar_t for our configuration but RC_1_30_0 intel-win32-tools.jam,1.23 doesn't. Our STL installation is compiled with wchar_t support. I will setup another copy compiled without it. -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
"Misha Bergal" <[EMAIL PROTECTED]> writes: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > > Thanks. The hyperlinks to test failure logs don't ever scroll to the > > appropriate section of the output on IE6. Fixed > The compiler_status changes from main trunk need to be integrated back to > RC_1_30_0 . > If I don't hear from somebody about it, I will just apply patch locally. Done Misha Bergal MetaCommunications Engineering ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
