headers
Joel de Guzman | 1 Apr 2003 01:43
Picon
Favicon

Re: Re: Understanding MPL

Edward Diener wrote:
> David Abrahams wrote:
>> "Edward Diener" <eddielee <at> tropicsoft.com> writes:

>> There's an unspecified type-expression which goes where the
>> /*unspecified*/ comment is.
>> 
>>> I always though that a typedef must specify an actual type but I
>>> don't see any in the expression above.
>> 
>> The point is that we're not showing it to you ;-)
> 
> I suspected that but I couldn't figure out why you wouldn't show it.
> However it made it hard for me to understand how mpl::if_<> really
> works without understanding what actually goes there.

Because it's an implementation detail :-) You need not know
the guts of how if_ really works, as long as it works. The same
way as you don't need to know how if (c) a; else b; works, 
(in terms of low level code) as long as it works.

However, perhaps the /*unspecified*/ would better be enhanced
by pseudo-code? 

    template<
        typename Condition
        , typename T1
        , typename T2
        >
    struct if_
(Continue reading)

Permalink | Reply | 21 comments |
headers
David Abrahams | 1 Apr 2003 02:18
Picon
Picon
Favicon
Gravatar

Re: Understanding MPL

"Joel de Guzman" <djowel <at> gmx.co.uk> writes:

> Edward Diener wrote:
>> David Abrahams wrote:
>>> "Edward Diener" <eddielee <at> tropicsoft.com> writes:
>
>>> There's an unspecified type-expression which goes where the
>>> /*unspecified*/ comment is.
>>> 
>>>> I always though that a typedef must specify an actual type but I
>>>> don't see any in the expression above.
>>> 
>>> The point is that we're not showing it to you ;-)
>> 
>> I suspected that but I couldn't figure out why you wouldn't show it.
>> However it made it hard for me to understand how mpl::if_<> really
>> works without understanding what actually goes there.
>
> Because it's an implementation detail :-) You need not know
> the guts of how if_ really works, as long as it works. The same
> way as you don't need to know how if (c) a; else b; works, 
> (in terms of low level code) as long as it works.
>
> However, perhaps the /*unspecified*/ would better be enhanced
> by pseudo-code? 
>
>     template<
>         typename Condition
>         , typename T1
>         , typename T2
(Continue reading)

Permalink | Reply | 20 comments |
headers
Michael Kettner | 1 Apr 2003 16:22
Picon
Picon

Re: [Signals-1.30.0] Linking problems


Hi Doug,

> Do the testcases run properly? e.g., use the same bjam command line in
> libs/signals/test and check if there are any failures.

I tried the testcases and erverything ran properly.

> If the Signals testcases are running properly, I would guess that the
> gcc-stlport toolset is using different STLport options than you are using
> in your own program, and its affecting the name of the STLport namespace.
> One way you can check this would be to use "nm libboost_signals.a|c++filt"
> to see what STLport namespace the Boost.Signals classes refer to.

That was the point: the boost-signals library used the namespace "std" (and 
not "_STL" as my program), because STLPORT_ROOT was not set. Instead I set 
STLPORT_PATH, as required under Windows. Changing STLPORT_PATH to 
STLPORT_ROOT and re-builduing boost-signals fixed all undefined references.

Thanks for your help!

This brings me to another point: I think it is extremely inconvenient to set 
STLPORT_ROOT under Linux and STLPORT_PATH under Windows as it is a source for 
errors like my one. Why couldn't you change boost-signals, so that 
STLPORT_ROOT is used on all platforms (like BOOST_ROOT, for example)?

Michael

--

-- 
Dipl.-Ing. Michael Kettner, Wissenschaftlicher Mitarbeiter
(Continue reading)

Permalink | Reply | 1 comment |
headers
Douglas Gregor | 1 Apr 2003 17:05
Picon
Favicon

Re: [Signals-1.30.0] Linking problems

On Tuesday 01 April 2003 09:22 am, Michael Kettner wrote:
> This brings me to another point: I think it is extremely inconvenient to
> set STLPORT ROOT under Linux and STLPORT PATH under Windows as it is a
> source for errors like my one. Why couldn't you change boost-signals, so
> that STLPORT ROOT is used on all platforms (like BOOST ROOT, for example)?
>
> Michael

I see (from stlport.jam) that both STLPORT_PATH and STLPORT_ROOT are supported 
on the GCC side, but STLPORT_ROOT is marked deprecated. Looks like you can 
use STLPORT_PATH in the same way on Linux and Windows:

    path ?= $(STLPORT_$(version)_PATH) ;
    path ?= $(STLPORT_PATH)$(SLASH)STLport-$(version) ;
    path ?= $(STLPORT_ROOT) ; #<< For backward compatability.

This is more of a Boost.Jam/Boost.Build question, because the Signals library 
itself doesn't know the difference between STLport on Windows or on Linux per 
se. They generally prefer that Jam-related questions go to 
jamboost <at> yahoogroups.com but usually answer questions here as well.

	Doug

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/xaxhjB/hdqFAA/VygGAA/EbFolB/TM
---------------------------------------------------------------------~->

Info: <http://www.boost.org>
Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Markus Werle | 1 Apr 2003 11:24
Picon

Re: Understanding MPL

David Abrahams wrote:

> We're not hacking the paper at this point (working on the book instead)

Ah! Earning money with Open Source via Closed Docs ;-)
Not exactly what RMS was dreaming of, but perfectly OK for me:
I will buy that book ASAP. I hope You also explain all those
macros that make the code so uneasy to read.

In the meantime Edward could be grateful for a hint to the book
from the guy who explained some of the techniques in detail,
even though his lib could not enter the boost tree due to
reasons I do not know of:

The book to buy until David's book is out is 
"Modern C++ Design" from Andrei Alexandrescu.
See http://www.moderncppdesign.com/

Markus

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/xaxhjB/hdqFAA/VygGAA/EbFolB/TM
---------------------------------------------------------------------~->

Info: <http://www.boost.org>
Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl>
Unsubscribe: <mailto:boost-users-unsubscribe <at> yahoogroups.com>

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
(Continue reading)

Permalink | Reply | 19 comments |
headers
Stephan Puchegger | 1 Apr 2003 15:15
Picon
Picon

ublas matrix slice bug?

Dear ublas developers!

(I am using boost 1.30 & gcc 3.2)

the following program:

#include <boost/numeric/ublas/matrix.hpp>
#include <boost/numeric/ublas/io.hpp>

int main () {
    using namespace boost::numeric::ublas;
    matrix<double> m (4, 4);
    for (unsigned int i = 0; i < m.size1 (); ++ i)
        for (unsigned int j = 0; j < m.size2 (); ++ j)
		m(i, j) = 1;

    std::cout << m << std::endl;

    // multiply a slice of the matrix with 2....
    project (m, slice (2, 1, m.size1()-2), slice (1, 0, m.size1()-2)) *= 2;

    // interesting result ... the slice has been multiplied with 4
    std::cout << m << std::endl;
}

gives the following output:

[4,4]((1,1,1,1),(1,1,1,1),(1,1,1,1),(1,1,1,1))
[4,4]((1,1,1,1),(1,1,1,1),(1,4,1,1),(1,4,1,1))
(Continue reading)

Permalink | Reply | 7 comments |
headers
John Fletcher | 1 Apr 2003 11:24
Picon

Re: linking Signals Library


Douglas Gregor wrote:

> On Monday 31 March 2003 06:17 am, John Fletcher wrote:
> > System: Red Hat 8.0 with gcc 3.2
> > Boost 1_30_0
> >
> > I have built the boost signals library using bjam.
> > The test suite runs and passes all tests.
> >
> > How do I make the resulting libraries available to my own programs?
> > Is there an equivalent of 'make install' which will move the results to
> > somewhere from which linking is possible?
>
> There isn't any equivalent to "make install" in Boost.Build, yet. However, you
> might consider adding a stage target to put the binaries into a more
> accessible location, e.g., the Jamfile might contain:
>
> (borrowed from libs/thread/build/Jamfile)
>     stage bin-stage
>         : <dll>boost_signals
>         : <tag><debug>"d"
>         : debug release
>     ;
>
>         Doug
>

Doug
(Continue reading)

Permalink | Reply | 1 comment |
headers
Douglas Gregor | 1 Apr 2003 17:42
Picon
Favicon

Re: Re: linking Signals Library

On Tuesday 01 April 2003 04:24 am, John Fletcher wrote:
> Doug
>
> Thank you for this.  I don't understand the answer as I don't see any code
> there which will enable me to designate a location  e.g. boost_1_30_0/lib 
> where my libraries could be. 

Sorry, 'bin-stage' was the location, although I don't particularly like the 
name choice.

> An alternative would be to provide a link
> from e.g. boost_1_30_0/lib to the location where the library actually is,
> down a very long directory chain. Either would be nice as then I could do
>
> g++  -I../boost_1_30_0 something.cpp -osomething -L../boost_1_30_0/lib
> -lsignals
>
> from anywhere, and use a system of my choice e.g. Cmake, to control my own
> parts of the software.  It is simple to include the noncompiled boost
> libraries in other code, which is presumably the purpose of reusable
> library code.

This is the idea of staging. If you add this into libs/signals/build/Jamfile:

stage lib
    : <dll>boost_signals
    : <tag><debug>"d"
    : debug release
    ;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Edward Diener | 1 Apr 2003 17:46

Re: Understanding MPL

Markus Werle wrote:
> David Abrahams wrote:
>
>
>> We're not hacking the paper at this point (working on the book
>> instead)
>
> Ah! Earning money with Open Source via Closed Docs ;-)
> Not exactly what RMS was dreaming of, but perfectly OK for me:
> I will buy that book ASAP. I hope You also explain all those
> macros that make the code so uneasy to read.
>
> In the meantime Edward could be grateful for a hint to the book
> from the guy who explained some of the techniques in detail,
> even though his lib could not enter the boost tree due to
> reasons I do not know of:
>
> The book to buy until David's book is out is
> "Modern C++ Design" from Andrei Alexandrescu.
> See http://www.moderncppdesign.com/

I already have it and have read it. The techniques explained in the Boost
MPL library seem to be different from many of the techniques explained in
Mr. Alexandrescu's fine book. I hope when the Boost book is out, it is more
readable and deliberate in explaining how things work than the paper above
which I find heavy going. But that's reasonable since papers often assume a
level of understanding, and take appropriate shortcuts on that assumption,
than a book which has more space to explain things a little more slowly.
Perhaps my difficulty with the paper is just my own failing but I will stick
to it and see what I can get out of it, and ask further questions if
(Continue reading)

Permalink | Reply | 0 comments |
headers
Edward Diener | 1 Apr 2003 17:53

Re: regex++ use on binary data

There is no reason you can not use Regex++ with data which containes null
bytes. Use the forms of the search algorithms which take iterators which
define the extents of the data on which you want to search. You also should
be able to use the forms of the search algorithms which takes C++
std::strings since null bytes can be embedded in std::strings AFAIK. I do
not believe the Regex++ algorithms do any stopping or special actions if
they encounter null bytes in the search stream, but John Maddock the creator
of the Regex++ implementation would know about that for sure.

brian_hernacki wrote:
> Maybe a newbiew question, but is there any way to use the regex++
> libary to search chunks of binary data? (or more accurately to search
> a buffer of data of known length for a given pattern which may itself
> contain null bytes)

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/xaxhjB/hdqFAA/VygGAA/EbFolB/TM
---------------------------------------------------------------------~->

Info: <http://www.boost.org>
Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl>
Unsubscribe: <mailto:boost-users-unsubscribe <at> yahoogroups.com>

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Permalink | Reply | 0 comments |

Gmane