headers
daveh-lists | 1 Sep 2001 01:49
Favicon

sub module support for python

Hi,

I have written some support in boost for python sub modules. This 
means that a single code module can support multiple python modules.

It works like this:

    .
    .
    .
    python::module_builder this_module("mymodule");
    python::sub_module_builder mysub_module(this_module, "mysub");
    mysub_module.def(mufunc, "myfunc");
    .
    .
    .

then in python:

import mymodule
print mymodule.mysub.myfunc()

mysub is treated as 'built-in' module of mymodule

So far this has only been tested with MSVC6 SP5

I have added the modified boost python files in the files section 
for comments?

Dave Hawkes
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Abrahams | 1 Sep 2001 02:44
Favicon
Gravatar

Re: Review: Config system

Aleksey makes some excellent points. On the other hand it is really useful
for developers who can handle the issues if they don't have to crawl through
all of their bug workarounds and disable them just to see how well a new
compiler works. The solution seems obvious to me: we specify a preprocessor
symbol which, when #defined, makes the appropriate assumption for
developers... shall we say, BOOST_DEVELOPER?

-Dave

----- Original Message -----
From: "Aleksey Gurtovoy" <alexy <at> meta-comm.com>
To: <boost <at> yahoogroups.com>
Sent: Friday, August 31, 2001 6:28 PM
Subject: RE: [boost] Review: Config system

> Jens Maurer wrote:
> > On a different topic discussed here, unknown compiler versions
> > should be assumed to be fully compliant.  If they aren't,
> > people will complain here, and we will know thusly that a new
> > version of some compiler has appeared and we can make appropriate
> > corrections.
>
> Being a real-world _user_ of boost (as opposite to a developer) I strongly
> disagree. Using of boost libraries in your project is supposed to help you
> in your every-day professional life, not to make it harder. Switching to a
> new version of the compiler and getting _your own_ code to compile and
work
> is painful enough without being forced to deal with a sudden break of 3rd
> party libraries' code, even (and especially) if one these libraries is
> "boost". Although fortunately it's not a case for our team, I know that
(Continue reading)

Permalink | Reply | 1 comment |
headers
Douglas Gregor | 1 Sep 2001 03:58
Picon
Favicon

Re: tuple problem report

Vitalij,
	There is now a fix for this in CVS, and it should be in the next Boost 
release as well. I apologize for the delay.
	
	Doug

On Friday 24 August 2001 10:21, flameframe <at> hotmail.com wrote:
> The following program fails to compile.
>
> #include <boost/tuple/tuple.hpp>
> int main(int argc, char* argv[])
> {
>     const boost::tuple<int> test;
>     boost::get<0>(test);
>     return 0;
> }
>
> MSVC6.5 claims to line 'boost::get<0>(test)'
> .. : error C2667: 'get' : none of 2 overload have a best conversion
> .. : error C2668: 'get' : ambiguous call to overloaded function
>
> Though program compiles without 'const'. Is it inappropriate here?
>
> Regards,
> Vitalij.
Permalink | Reply | 0 comments |
headers
Jason Shirk | 1 Sep 2001 04:15
Picon
Favicon

RE: Review: Config system


I have a few comments, especially considering my experience with 3
different versions of VC++ (VC6, VC7, and my ongoing work in developing
VC7.1.)

Some parts of BOOST will not compile out of the box with new versions of
VC.

This is true for VC7 (even after correcting _MSC_VER in boost\config.h.)
There was at least 1 compilation error due to a more conforming STL.

This will also be true for VC7.1.  (I have already made corrections
where BOOST_MSVC was used and perhaps another macro would have been
better.)

Simply put, some workarounds under BOOST_MSVC weren't written expecting
a conforming compiler from Microsoft.  It's usually trivial to fix, but
it might not work either way with a new version of the compiler.

How about using #error instead?  The BOOST user is made very aware they
are entering uncharted territory.

Of course, since VC has the greatest number of workarounds and I'm the
one fixing the compiler bugs, I could suggest assuming they'll all be
fixed in VC7.1.  After all, I already have all regression tests passing
in BOOST 1.20.2 with all workarounds disabled.  I've just moved on to
1.24.0 to see what bugs the new libraries have exposed.

Jason Shirk
VC++ Compiler Team
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jens Maurer | 1 Sep 2001 10:37
Picon

Re: Review: Config system

David Abrahams wrote:
>  The solution seems obvious to me: we specify a preprocessor
> symbol which, when #defined, makes the appropriate assumption for
> developers... shall we say, BOOST_DEVELOPER?

Agreed, and thanks to Aleksey for the user's perspective.
Except that I like BOOST_STRICT better (see other mails on the subject).

Jens Maurer
Permalink | Reply | 0 comments |
headers
Jens Maurer | 1 Sep 2001 10:44
Picon

Re: shared_xxx issues

David Abrahams wrote:
> Second Issue:
> 
> I found the following code in shared_array (and I assume the analogous code
> is in shared_ptr):
> 
>         void reset(T* p=0)
>         {
>             if ( px == p ) return;  // fix: self-assignment safe
> 
> What this does is to make a silent success of resetting a shared_ptr with
> the pointer it owns. 
[...]
>  I'd rather see an assert() here.

A similar issue has come up with Boost.Thread, where some simple
case of deadlock can be easily detected, but more complicated ones
cannot.  I think the resolution was not to detect the simple case
and specify a reaction to it, but instead treat all cases as a
precondition violation (with undefined behaviour).

David's case is similar.

I second David's suggestion above: It's a precondition violation
which should be handled by an assert(), if easy to detect.

Jens Maurer
Permalink | Reply | 0 comments |
headers
AlisdairM | 1 Sep 2001 11:04

RE: shared_xxx issues

First a call for help, how do I get MS Outlook newsreader to use a sensible
quoting style?  I can't reply point-by-point without losing my response in
the original message.

In response to David

First issue:  Agree!  While I believe both scoped_ptr and shared_ptr are
vital classes to submit for standardisation, as they cover over 90% of my
smart pointer requirements, an advanced policy-based smart pointer would be
extremely useful for the other 10% of cases.  I feel it is important to
retain scoped/shared_pointer though for the much simpler usage in the
majority of cases.

Second issue:  Makes sense, but if all I see in the code is an assert with
minor comment, I can imagine forgetting the issue in six months time and
trying to work out what is going on again.  Needs a comment in the
documentation, or a small FAQ entry.  After all, it is NOT self-assignment
that is the error (that is safely handled), but the fact that you are
self-assigning means you risk using reset with other pointers which you
cannot catch, and is not indicated clearly by asserting self-assignment!

AlisdairM

-----Original Message-----
From: David Abrahams [mailto:david.abrahams <at> rcn.com]
Sent: 30 August 2001 19:27
To: Boost <at> Yahoogroups. Com
Cc: Andrei Alexandrescu
Subject: [boost] shared_xxx issues
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Maddock | 1 Sep 2001 12:21
Picon

boost and Borland C++ Builder project

Giles,

>Is it going to be difficult to use Boost to link in with my project? Has
anyone
already done a similar thing - reason I ask is that I see VC++ and Borland
command line compiler mentioned a lot, but not Builder.
I'm not too good a programmer so I'd appreciate an 'honest' reply as to how
difficult it will be, so I can plan alternatives if need be.
<

Borlands command line compiler is the same as the compiler that ships with
C++ Builder, so yes you can use boost with Builder.  Also the graph library
(if that's the part you're interested in) has no source files associated
with it (it's headers only) so there's nothing to link.  On the down side,
the graph lib only partially supports the Borland compiler (probably this
is down to compiler bugs), you should also be aware that this is fairly
complex library that's probably not for the faint of heart :-)

- John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/
Permalink | Reply | 0 comments |
headers
John Maddock | 1 Sep 2001 12:33
Picon

Re: functional.hpp and mem_fun.hpp (was [Review] bind)


>I don't believe that optimizations - such as using
call_traits<>::param_type - should be part of the interface. As long as the
'effects' are the same, the implementor is free to use whatever tools are
available to him/her to improve the efficiency of the implementation.
<

Which is surely the core of the issue - the intent is that
call_traits<>::param_type is just "one of the tools that the implementor
uses to improve the efficiency of the implementation", it isn't supposed to
alter semantics at all, if it does then it's a defect.  

Now we were happy that everything was OK, and then along came auto_ptr (and
surely we're not the first to be tripped by that one!), the question is how
to fix that...

>I've outlined something close to a rationale for this decision in a
previous
>post. Basically, in the absence of information about which method for
>parameter passing is 'best', it's reasonable to choose the const
reference.
>In these cases, however, we do have information which method has been
chosen
>by the function designer, so it's reasonable to use it.

My point was that mem_fun/ptr_fun and bind_1st all have the same
information available to them (how the underlying function takes it's
args), but they do different things.  Whatever there's not much we can do
about that other than shrug I guess :-)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Anatoli Tubman | 1 Sep 2001 13:19

Re: Re: Re: quantity libraries

On Friday 31 August 2001 02:45, Ken Shaw wrote:
> I feel that
>   pounds <--> newtons
>   slugs  <--> kilograms
> should both be allowed, but
>   pounds <--> kilograms
> should not, unless perhaps with a real_ugly_cast.
>
> But is it worth complicating the library with such a cast?
> What would it look like? (I assume it would never permit
> converting parsecs <--> volts.)

No, such cast should not be provided. Provide pound-mass
instead. (A mass of one pound-mass weighs one pound at
nominal Earth gravity.)

By the way, the "units" Unix program tells me that pound (lb) is
mass, and pound-force (lbf) is weight. I guess there's no
one true definition of pound.

> Are there other pairs of units that people might think are
> equivalent (modulo a location-scale transform) but which
> actually are not--or are these the only strange cases?

Kilogram and kilogram-force? Hm, I guess it's the same old
misnomer.

> I haven't looked at the quantity library in a while, but
> perhaps there's a way to specialize the error message in
> this case:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane