"Fernando Cacciola" <[EMAIL PROTECTED]> writes:
> [snipped]
>> So, I like Dave's macro, though I would prefer code generation macros
>> not to be put in code directly requiring users to know the inner
>> details of expanded code (for debugging, for instance).
>>
>> Just a thought.
>
>FWIW, my mac
"Fernando Cacciola" <[EMAIL PROTECTED]> writes:
> "Aleksey Gurtovoy" <[EMAIL PROTECTED]> escribió en el mensaje
> news:[EMAIL PROTECTED]
>> David Abrahams wrote:
>> > Here's an example I just cooked up of using the PP lib to solve a
>> > classic C++ OO problem: repeated boilerplate in the definiti
"E. Gladyshev" <[EMAIL PROTECTED]> writes:
> I think that any industry standard TEMPLATE library
> should be designed in terms of modern C++. The
> compilation time should NOT be considred as an issue.
Is MPL a modern TEMPLATE library, in your opinion?
I ask because compilation time is a very se
"Paul Mensonides" <[EMAIL PROTECTED]> writes:
> Aleksey Gurtovoy wrote:
>> David Abrahams wrote:
>> > Here's an example I just cooked up of using the PP lib to solve a
>> > classic C++ OO problem: repeated boilerplate in the definition of
>> > Pimpl classes.
>>
>> There is another variation of
E. Gladyshev wrote:
>> Are you aware that the pImpl idiom is used for many
>> different things
>
> It defenitly has its place but not in modern C++.
>
>> or have
>> you just decided its not modern C++ at all because
>> you don't use it for the
>> things you want to do ?
>
> In my opinion modern C++
"Aleksey Gurtovoy" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED]
> David Abrahams wrote:
> > Here's an example I just cooked up of using the PP lib to solve a
> > classic C++ OO problem: repeated boilerplate in the definition of
> > Pimpl classes.
>
> There is another variation
Aleksey Gurtovoy wrote:
> David Abrahams wrote:
> > Here's an example I just cooked up of using the PP lib to solve a
> > classic C++ OO problem: repeated boilerplate in the definition of
> > Pimpl classes.
>
> There is another variation of the idiom, sometimes called
> "hidden state", which d
--- Brock Peabody <[EMAIL PROTECTED]>
wrote:
> > Anyway I think I got the basic idea. The idea is
> that
> > the GUI elements are classes defined on top of a
> > pImpl. Someone else creates the pImpl object and
> > passes it to the GUI elements classes. The GUI
> > elements then call pImpl meth
--- Douglas Paul Gregor <[EMAIL PROTECTED]> wrote:
> On Fri, 1 Aug 2003, E. Gladyshev wrote:
> Because one might use multiple threading models in a
> single program? Since
> we already have a boost::threads design to compare
> against, could you
> explain how the ImplTraits idiom would improve it?
On Fri, 1 Aug 2003, E. Gladyshev wrote:
> > Pimpl definitely has its place.
>
> I agree, but boost::threads and boost::gui would be
> much better of with ImplTraits, in my opinion.
Because one might use multiple threading models in a single program? Since
we already have a boost::threads design to
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of E. Gladyshev
> Sent: Friday, August 01, 2003 4:57 PM
> To: Boost mailing list
> Subject: RE: [boost] GUI/GDI template library
>
> > Here is a very simplified version of how this can
> > happen.
> >
>
--- Rene Rivera <[EMAIL PROTECTED]>
wrote:
> [2003-08-01] E. Gladyshev wrote:
>
> >> Are you aware that the pImpl idiom is used for
> many
> >> different things
> >
> >It defenitly has its place but not in modern C++.
>
> Could you do us the courtesy of indicating who you
> are quoting when you
> Here is a very simplified version of how this can
> happen.
>
> template struct edit_imp {...};
>
>struct edit {
>
> template edit_imp
> make_gui() {...}
>};
>
>template struct
> gui_wrapper_base {
>
> //some pure virtual functions
>};
>
>template
> str
[2003-08-01] E. Gladyshev wrote:
>> Are you aware that the pImpl idiom is used for many
>> different things
>
>It defenitly has its place but not in modern C++.
Could you do us the courtesy of indicating who you are quoting when you post
to the list. It's very hard to follow otherwise. Not to me
David Abrahams wrote:
> Here's an example I just cooked up of using the PP lib to solve a
> classic C++ OO problem: repeated boilerplate in the definition of
> Pimpl classes.
There is another variation of the idiom, sometimes called "hidden state",
which doesn't have the shortcoming in the first p
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of E. Gladyshev
> Sent: Friday, August 01, 2003 3:31 PM
> To: Boost mailing list
> Subject: RE: [boost] GUI/GDI template library
>
> > Even if the implementation is parameterized by a
> > traits or other
> Are you aware that the pImpl idiom is used for many
> different things
It defenitly has its place but not in modern C++.
> or have
> you just decided its not modern C++ at all because
> you don't use it for the
> things you want to do ?
In my opinion modern C++ is more oriented toward
program
Hi Ron,
What's the status of shared_container_iterator? It's not been
converted to the new iterator adaptors. It's in the $boost_root/boost
directory but it's not listed in the library index. Was it accepted
into the library?
-Dave
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
> Pimpl definitely has its place.
I agree, but boost::threads and boost::gui would be
much better of with ImplTraits, in my opinion.
> If you buy Doug G.'s argument that no application
> will use two
> GUIs at once
No I don't buy Doug's argument at all.
Here is an example.
//customize the edit
> Even if the implementation is parameterized by a
> traits or other class,
> we could still use a non template class in the
> implementation to reduce
> compile times, which is what I though the original
> poster was trying to
> say.
>
> template <... typename ImplTraits> class
> some_edit_class
E. Gladyshev wrote:
>> Not quite. pImpl is really bad when you have
>> multiple interacting
>> concrete types. I think you'll find yourself doing
>> a lot of
>> polymorphic_downcast<>s.
>
> Another good point against the pImpl idiom. I'd
> suggest to overwrite some of the boost libaries that
> u
Why aren't there constructors accepting an error_code in
boost::fs::exception?
I have some code which needs to throw an exception if
!is_directory(some_path). I'd like to throw a not_a_directory
filesystem exception (or one derived therefrom).
Howto?
--
Dave Abrahams
Boost Consulting
www.boos
"E. Gladyshev" <[EMAIL PROTECTED]> writes:
>> Not quite. pImpl is really bad when you have
>> multiple interacting
>> concrete types. I think you'll find yourself doing
>> a lot of
>> polymorphic_downcast<>s.
>
> Another good point against the pImpl idiom. I'd
> suggest to overwrite some of the
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 tho
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of E. Gladyshev
> Sent: Friday, August 01, 2003 1:23 PM
> To: Boost mailing list
> Subject: Re: [boost] GUI/GDI template library
>
>
> --- Douglas Gregor <[EMAIL PROTECTED]> wrote:
> > > template < type
Here's an example I just cooked up of using the PP lib to solve a
classic C++ OO problem: repeated boilerplate in the definition of
Pimpl classes. Paul, if you want to put it (or something like it) in
the PP lib docs, you're welcome to.
// Copyright David Abrahams 2003. Permission to copy, use,
--- Douglas Gregor <[EMAIL PROTECTED]> wrote:
> > template < typename IT, typename PhysicalGuiLayer
> >
> > class ListControl
I came with a name for this idiom, ImplTraits idiom.
template <... typename ImplTraits >
class someclass
It is like the name of the pImpl idiom.
Eugene
_
> Not quite. pImpl is really bad when you have
> multiple interacting
> concrete types. I think you'll find yourself doing
> a lot of
> polymorphic_downcast<>s.
Another good point against the pImpl idiom. I'd
suggest to overwrite some of the boost libaries that
use the pImpl thing. It is not l
> 1) It buys us very little: generally template
> parameters are useful when
> more than one instantiation will be used within any
> particular program. It
> is highly unlikely that a program will support two
> physical GUI layers
> simultaneously,
I think that it is very likely. For examle
> Have you built the signals library multi-threaded or
> single threaded and
Whatever the default build is.
> are you building an application of the same sort?
The application is set to use multi-thread run-time
libraries and MFC.DLL.
> Not seen this specific one, the most common problem
>
Martin Wille <[EMAIL PROTECTED]> wrote:
> Joel de Guzman wrote:
>
>> l.. Added missing include files to miniboost
>
> For the records: that one doesn't apply to Boost 1.30.1.
Yes that's correct. Sorry.
--
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spir
David Abrahams <[EMAIL PROTECTED]> wrote:
> "Joel de Guzman" <[EMAIL PROTECTED]> writes:
>> I'd like to add Spirit 1.6.1 (a bug fix release) to Boost 1.30.1.
>> There are no new features in 1.6.1, just bug fixes. Here are
>> the list of bug fixes.
[snip]
>> I am about to commit Spirit 1.6.1 to t
On Fri, 1 Aug 2003, David Abrahams wrote:
> I have put a diff of the changes between Version_1_30_0 and RC_1_30_0
> at http://www.boost-consulting.com/diffs-1-30-1.txt. These will be
> the changes that go into the Boost 1.30.1 release. Will the
> authors/maintainers of the following libraries ple
Joel de Guzman wrote:
l.. Added missing include files to miniboost
For the records: that one doesn't apply to Boost 1.30.1.
Regards,
m
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
David Abrahams wrote:
> I have put a diff of the changes between Version_1_30_0 and RC_1_30_0
> at http://www.boost-consulting.com/diffs-1-30-1.txt. These will be
> the changes that go into the Boost 1.30.1 release. Will the
> authors/maintainers of the following libraries please post a brief
> s
"Joel de Guzman" <[EMAIL PROTECTED]> writes:
> David Abrahams <[EMAIL PROTECTED]> wrote:
>> I have put a diff of the changes between Version_1_30_0 and RC_1_30_0
>> at http://www.boost-consulting.com/diffs-1-30-1.txt. These will be
>> the changes that go into the Boost 1.30.1 release. Will the
>
David Abrahams <[EMAIL PROTECTED]> wrote:
> I have put a diff of the changes between Version_1_30_0 and RC_1_30_0
> at http://www.boost-consulting.com/diffs-1-30-1.txt. These will be
> the changes that go into the Boost 1.30.1 release. Will the
> authors/maintainers of the following libraries ple
David Abrahams wrote:
lambda
The fix in boost/lambda/detail/operator_return_type_traits.hpp enables
you to use the lambda library with GCC 2.95.2, which wasn't possible
with the 1.30.0.
--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aa
"Neal D. Becker" <[EMAIL PROTECTED]> writes:
> I know I (and others) have previously asked about extending integer.hpp to
> handle 64-bit types. I don't recall the conclusions of the discussion,
> though, and on visiting the boost archive, I don't see a search
> option.
How many options do y
I have put a diff of the changes between Version_1_30_0 and RC_1_30_0
at http://www.boost-consulting.com/diffs-1-30-1.txt. These will be
the changes that go into the Boost 1.30.1 release. Will the
authors/maintainers of the following libraries please post a brief
summary of the fixes that were a
David Abrahams wrote:
Daniel Frey <[EMAIL PROTECTED]> writes:
When looking at the current:
class X : boost::addable< X >
{
X& operator+=( const X& );
};
I wonder if addable is a good name. I thought that the classes are
named by the operator that is provided by the user and that they add
the o
I know I (and others) have previously asked about extending integer.hpp to
handle 64-bit types. I don't recall the conclusions of the discussion,
though, and on visiting the boost archive, I don't see a search option.
Perhaps someone can point me in the correct direction.
(I would really like
Daniel Frey <[EMAIL PROTECTED]> writes:
> When looking at the current:
>
> class X : boost::addable< X >
> {
> X& operator+=( const X& );
> };
>
> I wonder if addable is a good name. I thought that the classes are
> named by the operator that is provided by the user and that they add
> the ope
"Douglas Gregor" <[EMAIL PROTECTED]> writes:
> 3) There is an alternative solution: Boost.Threads presents a single,
> non-template interface to the user and hides all of the platform-specific
> details using the pImpl idiom. The same approach can be applied here, and I
> think we'll find that
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> On Behalf Of David Abrahams
> Sent: Wednesday, July 30, 2003 6:31 PM
> To: [EMAIL PROTECTED]
> Subject: [boost] Re: GUI/GDI template library
[...]
>
> I think so. See Boost.Python and Boost.Spirit for examples
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of Douglas Gregor
> Sent: Friday, August 01, 2003 12:40 AM
> To: Boost mailing list
> Subject: Re: [boost] GUI/GDI template library
[..]
> I believe that one bit that falls out of the above agrees 100% wi
(sorry for the prev. message without
subject)
Have anyone used StackTraces utility on
borland 6.0. I'm tring to use it and also tring to understand. At last i could
compile the project but;
* a deadlock occured, the program
locked
then i changed a line in
the code (stacktrace_win3
Hello, boost. :-}
This is refactore and improved date_parsing.hpp
--
nagual mailto:[EMAIL PROTECTED]
date_parsing.hpp.patch
Description: Binary data
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/
Daryle Walker wrote:
On Thursday, July 31, 2003, at 9:58 AM, Daniel Frey wrote:
Daryle Walker wrote:
In we have helper classes that can generate
"operator OP" from "operator OP=", where "OP" can be "+", "/", ">>",
etc. What about types and algorithms where the non-assignment
version is easie
On Thursday, July 31, 2003, at 9:58 AM, Daniel Frey wrote:
Daryle Walker wrote:
In we have helper classes that can generate
"operator OP" from "operator OP=", where "OP" can be "+", "/", ">>",
etc. What about types and algorithms where the non-assignment
version is easier than the assignment
50 matches
Mail list logo
