November 2004 - Boost - lists.preview.boost.org

GUI Library Proposal for a Proposal
by Brian Braatz 05 Nov '04

05 Nov '04

(was RE: [boost] Re: GUI library - something to think about) Both http://www.torjo.com/win32gui/save_dlg.html and http://www.litwindow.com/Library/Documentation/documentation.html are extremely interesting. What I see (just after taking a peek at both): Win32Gui Interesting design No macros Looks tied to Win32Gui LitWindow Also interesting design Does have macros Also sits on top of WxWidgets, but it looks like the WxWidgets layer could be abstracted out. I propose that BOTH authors collaborate (on this list) to achieve the following: * Combination of the best of both frameworks * Can sit on WxWidgets OR can have a win32 and xwindows underlying implementation * This would allow it to be in boost, but also be LEAN and not need another framework I believe that if you took both of your thoughts, and accomplished the above bullet points, not only would it be good for boost, but it would really mean that boost had something that was much cooler than what I see available from other (ahem) vendors. I.e. instead of making a boost library that just "provides a layer" over GUI things, this combination would be actually moving the technology forward. (they don't call it "boost" for nothing :) ) I ask that both of you gentlemen seriously consider my proposal. I would also offer to help in any way that I can as I think you both have some really groundbreaking ideas in the realm of GUI frameworks. (fingers crossed) Brian :) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of John Torjo > Sent: Wednesday, November 03, 2004 9:14 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: GUI library - something to think about > > > struct SomeSettings { > > int m_aMember; > > SomeOtherStruct m_struct; > > vector<string> m_strings; > > }; > > > > the neccessary data adapter definition which you must include in a > > source file looks like this > > > > IMPLEMENT_CONTAINER_ADAPTER(vector<string>) > > > > BEGIN_DATA_ADAPTER(SomeSettings) > > PROP(m_aMember) > > PROP(m_struct) > > PROP(m_strings) > > END_DATA_ADAPTER() > > > > > Sure thing, but how about *true* bindings? > http://www.torjo.com/win32gui/save_dlg.html > > (if you download the code, you'll find quite a few examples: > examples/smart_dialogs) > > Note that you can add correspondences directly to your data + validation > code (no macros whatsoever). > >

10 11

RE: [boost] Re: GUI Library Proposal for a Proposal
by Brian Braatz 05 Nov '04

05 Nov '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Jared McIntyre > Sent: Friday, November 05, 2004 7:28 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: GUI Library Proposal for a Proposal > > >Edward Diener wrote: > >> > >>No !!!!! WxWidgets has almost nothing to do with modern C++. Let's no go > >>there, or have anything to do with supporting any other GUI > implementation. > >> > > > >Also, wxWindows is a huge library. If we were to introduce > >something in boost, I'd very much like it to be as small and light > >weight (as win32gui is supposed to be), not a collection of > >multi-megabyte dlls required, just to wrap win32 or what ever the > >underlying library is. > > > >If people want more powerful components, they can be added > >afterwards, but the underlying library around core OS controls > >should be as small as possible. > > > >Thanks > > > >Russell > > Honestly, I don't buy into the idea of cross platform GUI at all. I > have lots of reasons born out of experience with them that I won't > get into here, but in general, I find they are nice for the > developer, but poor for the user. I would much rather write my > backend code in a cross-platform language, and hook it up to a GUI > designed for each platform I support. That is why, at first glance > anyway, I like the idea behind the Lit Window design. Most of the > backend is GUI neutral, allowing you to do more work in your > cross-platform code. In theory, this could be used to simplify the > platform specific GUI code that needs to be written. I'd much rather > see C++ go a route of making it easier to develop for different GUI > libraries than to actually develop one of its own (since I don't > think it would get much use anyway). > > JJared McIntyre > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost [Brian Braatz] " I'd much rather > see C++ go a route of making it easier to develop for different GUI > libraries than to actually develop one of its own (since I don't > think it would get much use anyway)." Yes, and that is what my original mail that started this thread suggested :) Where it gets confusing to talk about, is that by doing that, you end up doing a "little bit" of the work that "already exists" elsewhere. That is ok.

1 0

[serialization] problem with boost/serialization/is_abstract.hpp
by Joaquín Mª López Muñoz 05 Nov '04

05 Nov '04

In MSVC 6.0, the following snippet fails: #include <boost/archive/text_iarchive.hpp> #include <boost/tuple/tuple.hpp> int main() { return 0; } complaining about is_abstract being already defined. The problem lies in the following lines inside boost/serialization/is_abstract.hpp: #ifndef BOOST_TT_IS_ABSTRACT_CLASS_HPP #if defined(__GNUC__) && (34 <= _GNUC__ * 10 + __GNU_MINOR) \ || defined(__MSVC_VER) && (1310 <= __MSVC_VER) \ || defined(__EDG_VERSION__) \ /**/ #include <boost/type_traits/is_abstract.hpp> #else // default to false if not supported namespace boost { template<class T> struct is_abstract { typedef mpl::bool_<false> type; BOOST_STATIC_CONSTANT(bool, value = is_abstract::type::value); }; } // namespace boost #endif #endif // BOOST_TT_IS_ABSTRACT_CLASS_HPP The code is *incorrectly* using __MSVC_VER where it should use _MSVC_VER (just one leading underscore). Thus boost::is_abstract is defined twice, as boost/type_traits.hpp is implicitly included by boost/tupe/tuple.hpp If nobody complains, I can fix this and commit it to the release and main branch. What worries me, though, is that the code above seems flawed to me (apart from the minor typo). What happens if the compiler is not one of those taken care of explicitly in boost/serialization/is_abstract.hpp? Could anyone please test the first snippet in some compiler other than MSVC, ICC for Windows, GCC or an EDG-based compiler? My thesis is that it will fail. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

7 7

Serialization support for mersenne_twister
by Neal D. Becker 05 Nov '04

05 Nov '04

I know I've mentioned this before. I'd really like to see this tiny bit of code added to mersenne_twister: template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & x; ar & i; } This would make it very easy to use our new serialization library with mersenne_twister. It costs nothing if you don't use it. If you are really paranoid, it could be surrounded by an #ifdef.

3 2

[spirit] select_p problem
by Vyacheslav E. Andrejev 05 Nov '04

05 Nov '04

Hi All, boost::spirit::select_p parser can not be compiled with boost::spirit::rule as argument. The problem is that metafunction boost::spirit::impl::as_embedded_parser<ParserT> returns const reference to boost::spirit::rule, not boost::spirit::rule itself, when PaerserT = boost::spirit::rule. So trying to compile parser_result<as_embedded_parser<rule<> > > deep inside the select_p implementation generates error message that const rule<>& has no result_type. I suggest to change parser_result definition as following: template <typename ParserT, typename ScannerT> struct parser_result { typedef typename boost::remove_reference<ParserT>::type::template result<ScannerT>::type type; }; -- ______________________________ Vyacheslav E. Andrejev System Architect, Excelsior, LLC

2 1

Contacting Chuck Allison [if you don't know how to contact Chuck Allison ignore]
by Vesa Karvonen 04 Nov '04

04 Nov '04

Hi, I would like to query whether The C++ Source (http://www.artima.com/cppsource/index.jsp) would be interested in publishing an article on Lazy Template Metaprogramming. I tried e-mailing the ChuckAllison(a)mailblocks.com -address, but haven't received any response in about 24-hours. So, if you know how to contact Chuck Allison, please forward this message to him. Regards, Vesa Karvonen _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/

2 1

RE: [boost] [Boost-bugs] [ boost-Bugs-1059388 ] shared_ptr::operator->() const return type should be const
by Eyal Farago 04 Nov '04

04 Nov '04

I think you're wront about this, shared_ptr should behave just like a pointer (in this aspect). it really doesn't matter if the pointer is const or not, what matters is the constness of the pointee. typedef int* pint_t; const pint_t p = new int(1); //p is const(same as int * const) int &ref_to_int = *p; //but *p isn't eyal. -----Original Message----- From: SourceForge.net [mailto:noreply@sourceforge.net] Sent: Wednesday, November 03, 2004 12:29 PM To: noreply(a)sourceforge.net Subject: [boost] [Boost-bugs] [ boost-Bugs-1059388 ] shared_ptr::operator->() const return type should be const Bugs item #1059388, was opened at 2004-11-03 13:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1059388&group_… Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roland (vzaznobin) Assigned to: Peter Dimov (pdimov) Summary: shared_ptr::operator-> () const return type should be const Initial Comment: shared_ptr::operator-> () const return type should be const const T * operator-> () const; T * operator-> (); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1059388&group_… ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: [boost] [serialization] problemwithboost/serialization/is_abstract.hpp
by JOAQUIN LOPEZ MU?Z 04 Nov '04

04 Nov '04

----- Mensaje original ----- De: Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> Fecha: Jueves, Noviembre 4, 2004 7:58 pm Asunto: Re: [boost] [serialization] problemwithboost/serialization/is_abstract.hpp > Joaquín Mª López Muñoz writes: > > In MSVC 6.0, the following snippet fails: > > > > #include <boost/archive/text_iarchive.hpp> > > #include <boost/tuple/tuple.hpp> > [...] > > complaining about is_abstract being already defined. The problem > > lies in the following lines inside > boost/serialization/is_abstract.hpp:> > > #ifndef BOOST_TT_IS_ABSTRACT_CLASS_HPP > > #if defined(__GNUC__) && (34 <= _GNUC__ * 10 + __GNU_MINOR) \ > > || defined(__MSVC_VER) && (1310 <= __MSVC_VER) \ > > || defined(__EDG_VERSION__) \ > > /**/ > > #include <boost/type_traits/is_abstract.hpp> > > #else > > First of all, the whole thing is a huge hack and can cause an ODR > violation on 1-2-3. We should really fix type_traits to fall back to > something like the code below, but that is definitely out for the > release. Yep, I'll take care of this as soon as Boost 1.32 is out -I need it for my own purposes :) > > Having said that, the #else branch is simply missing this: > > # define BOOST_TT_IS_ABSTRACT_CLASS_HPP > [...] > > If nobody complains, I can fix this and commit it to the release and > > main branch. > > Please! Together with the #define, if you can. Consider it done in approx. 12 hours from now. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

small library proposal -- rebind template args and function pointer types
by James Harris 04 Nov '04

04 Nov '04

Hello Boost Members, I have written a small library of meta-functions that allow rebinding of template arguments and function pointer return/argument types. I am posting in an attempt to guage interest and hopefully receive pointers on the library proposal process. The library provides the following meta-functions: rebind<int index, class rebind_type, class source_type> -- rebind template arguments rebind_func_arg<int index, class rebind_type, class func_type> -- rebind argument type of func/method ptr rebind_func_return<class rebind_type, class func_type> -- rebind return type of func/method ptr rebind_method_class<class rebind_type, class func_type> -- rebind class portion of method ptr // --- rebind<> example ------------------------------------------------ template <class A, class B, class C> class foo { }; typedef foo<int, int, int> source_type; typedef rebind<1, char, source_type>::type rebound_type; // rebound_type equates to foo<int, char, int> // --- rebind_func_arg<> example --------------------------------------- typedef int (*func_ptr)(int); typedef rebind_func_arg<0, char, func_ptr>::type rebound_type // rebound_type equates to int (*)(char) // rebind_func_args also works with pointer-to-method types // --- rebind_func_return<> example ------------------------------------ typedef int (*func_ptr)(int); typedef rebind_func_return<char, func_ptr>::type rebound_type // rebound_type equates to char (*)(int) // rebind_func_return also works with pointer-to-method types // --- rebind_method_class<class rebind_type, class func_type> --------- typedef int (foo::*method_ptr)(int); typedef rebind_method_class<bar, method_ptr>::type rebound_type; // rebound_type equates to int (bar::*)(int); -- end examples -- I have tested the code using MSVC 7.1 and GCC 3.3.2-1. Please let me know if this library would be useful to any of you, or otherwise any reason why it is not required or, of course any tips/suggestions/questions that you might have. Kind Regards, James Harris.

4 3

Documentation Bug
by Joshua Berne 04 Nov '04

04 Nov '04

Quick bug in the documentation links for "www.boost.org"'s "Nightly CVS" link. All the library links that don't link to pages under docs/html are broken, since the directory http://www.boost.org/regression-logs/cs-win32_metacomm/ seems to contain only the doc directory, and not the full distribution. (The same aspect of the lib links, that they link to ../../libs/... outside of the doc/html dir, is also breaking the "put a symbolic link to docs/html in my home dir" approach to viewing the boost documentation.. but i'm not sure that's a behaviour anyone endorses.) Hope this helps. - Josh

1 0