headers
Dean Michael Berris | 1 Jul 07:36
Picon
Gravatar

[RC_1_34_0] Boost Build v2 installation missing headers

Hi Everyone,

I'm sending a ping again regarding the installation target of Boost
Build v2. I ran this command (on RC_1_34_0) and noticed some headers
weren't being copied over:

bjam --v2 install --prefix="C:\Program Files\Microsoft Visual Studio 8"

I am trying to build the library I'm working on (
http://sourceforge.net/projects/dispatcher ) using MSVC 8.

I've not enough experience with Boost.Jam (I just had it up and
running, and my local copy of the library was just converted to build
against/with boost using Boost.Jam) but would like to see how I can
check which headers are being copied over for msvc. Most of the
missing headers that I noticed pertained to msvc specific headers
(like detail/msvc in preprocessor, and mpl).

Is there a place where I should start looking? Ive tried most of the
.jam files in the boost/tools/build directory, but somehow I don't
feel like I'm looking in the right place.

I really would like to help, though pointers would be most appreciated.

Have a great weekend everyone!

--

-- 
Dean Michael C. Berris
C/C++ Software Architect
Orange and Bronze Software Labs
(Continue reading)

Permalink | Reply | 4 comments |
headers
Dean Michael Berris | 1 Jul 07:57
Picon
Gravatar

Re: Interest in a flyweight library?

On 7/1/06, Caleb Epstein <caleb.epstein <at> gmail.com> wrote:
>
> I like this utility, but I agree it might be better named
> boost::interned<T>.
>

I like the utlitity too, however I'm not really sure about "interned"
-- having been exposed only to the GoF Flyweight pattern.

Perhaps boost::interned<T> and boost::flyweight<T> can be made
identical or behave the same? What I would be saying really is that
boost::interned can apply the "value instance singularity" (invented
phrase, something I try to describe how I understand what the library
is doing) while boost::flyweight<T> be consistent with the GoF
flyweight description?

Would it be too much work to do this?

--

-- 
Dean Michael C. Berris
C/C++ Software Architect
Orange and Bronze Software Labs
http://3w-agility.blogspot.com/
http://cplusplus-soup.blogspot.com/
Mobile: +639287291459
Email: dean [at] orangeandbronze [dot] com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cory Nelson | 1 Jul 10:02
Picon
Gravatar

Re: Interest in a flyweight library?

On 6/28/06, Joaquín Mª López Muñoz <joaquin <at> tid.es> wrote:
> During some conversations with a colleague I came up with a very
> sketchy realization of what could be converted, if there is interest,
> in a flyweight library. Please see flyweight.hpp at Vault/Patterns:
>
>   http://tinyurl.com/l6lt4
>
> The so-called Flyweight Design Pattern, upon which this is inspired,
> is much too OO for current C++ tastes IMHO, what I'm proposing
> takes a more generic stance. A minimal use example follows
> showing the syntax:
>
> #include "flyweight.hpp"
> #include <string>
> #include <iostream>
>
> int main()
> {
>  using boost::flyweight::flyweight;
>
>  flyweight<std::string> str("hello world");
>  std::cout<<str<<"\n";
> }
>
> Briefly put, a flyweight<T> is an object that can be used as a
> const T (i.e. flyweight<T> provides an operator const T&) but whose
> size is that of a pointer. The trick is that identical flyweight<T>
> objects
> share their representation globally, which drastically reduces memory
> usage when there are much more objects than different values.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Leland Brown | 1 Jul 12:05
Picon
Favicon

Re: [PQS] Length::m vs Length

Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
> "Beth Jacobson"  wrote
> > Andy Little wrote:
> >> In PQS the units are part of the type. IOW the numeric value and
> >> its unit are always tightly coupled in code. That is a powerful
> >> feature. Once the numeric part of a quantity is disassociated
> >> from its unit then manual checking and external documentation is
> >> required, which is often the current situation wherever doubles
> >> are used to represent quantities. Manual checking doesnt always
> >> work as well as intended... That of course is why the Mars lander
> >> crashed!

Agreed!  Any code containing a numeric literal for a physical quanity,
or any code that inserts or extracts a numeric value from a quantity
should be required to also specify the units of the numeric value. 
That's a critical part of the goal of the PQS library.

> > I agree that unit checking can be an extremely useful feature, I'm
> > just not convinced that tight coupling is necessary to achieve
> > that.

But I also agree here.  The goal can be achieved without necessarily
making the units part of the type.  I'll explain.

> There is planned another quantity where you can change the units at
> runtime FWIW.

I mentioned much earlier that my own implementation of a quantities
library was more like the so-called "t2_quantity" - at least the way I
envisioned the t2_quantity.  But as I read the discussion it occurs to
(Continue reading)

Permalink | Reply | 3 comments |
headers
JOAQUIN LOPEZ MU?Z | 1 Jul 14:00
Picon
Gravatar

Re: Interest in a flyweight library?


----- Mensaje original -----
De: "Steven E. Harris" <seh <at> panix.com>
Fecha: Viernes, Junio 30, 2006 7:32 pm
Asunto: Re: [boost] Interest in a flyweight library?

> Joaquín Mª López Muñoz <joaquin <at> tid.es> writes:
> 
> > Anyway, naming discussions aside, do you see value in such a thing
> > being elaborated and eventually proposed to Boost?
> 
> From my brief examination of the implementation and examples 
> provided,yes, it looks useful. I have no qualms with the idea and 
> I have full confidence you'll implement it well. 
> However, I don't think you should
> cast the naming problem aside as immaterial.

Of course naming issues are important, excuse me if I gave
the impression I was belittling your concern. Only that
in these preliminary stage I want to gauge people's
interest in the stuff, regardless of final names

[...]
> We're both arguing that there's prior art here to justify the
> name. Your implementation includes both a reference mechanism and a
> pooling mechanism. "Flyweight" describes the former, but the pattern,
> at least by my reading, doesn't speak to comparing candidate 
instances
> and ensuring that there are no duplicates in the pool. That
> duplicate-avoidance policy is specifically addressed by interning.
(Continue reading)

Permalink | Reply | 1 comment |
headers
JOAQUIN LOPEZ MU?Z | 1 Jul 14:04
Picon
Gravatar

Re: Interest in a flyweight library?

----- Mensaje original -----
De: Caleb Epstein <caleb.epstein <at> gmail.com>
Fecha: Viernes, Junio 30, 2006 8:38 pm
Asunto: Re: [boost] Interest in a flyweight library?

[...]
> I immediately thought of an "interned_string" class I had written 
> when I read Joaquin's description.  I have only really seen this 
> technique called "interning" and (once) "coadunation" before.
> 
> There is an implementation of something similar for strings only 
> in the ASL called adobe::name_t: 
> http://opensource.adobe.com/classadobe_1_1name__t.html
> I like this utility, but I agree it might be better named
> boost::interned<T>.
> 
> -- 
> Caleb Epstein

Hello Caleb,

Please see my previous answer to Steve Harris. It'd help me
a lot if, for uniformity's sake, name proposals could be given
in this format:

  lib name / namespace names / main utility

like for instance:

  Boost.Intern / boost::intern / boost::interned<>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jeff Garland | 1 Jul 17:52

Re: Interest in a flyweight library?

JOAQUIN LOPEZ MU?Z wrote:

> 
> Please see my previous answer to Steve Harris. It'd help me
> a lot if, for uniformity's sake, name proposals could be given
> in this format:
> 
>   lib name / namespace names / main utility
> 
> like for instance:
> 
>   Boost.Intern / boost::intern / boost::interned<>
> 
> So, cast your vote :)

I have a problem with these names -- Boost.intern sounds like a developer that 
should be working on an SOC project.  'Interned' sounds like what happens when 
someone dies and is buried -- not too pleasant.  I think flyweight is better, 
although maybe some variant of 'wrapper' might be better.  Another question, 
C# and some other languages have the idea of 'boxing' -- perhaps that's what 
this really is?

Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 2 comments |
headers
JOAQUIN LOPEZ MU?Z | 1 Jul 17:51
Picon
Gravatar

Re: Interest in a flyweight library?

----- Mensaje original -----
De: Cory Nelson <phrosty <at> gmail.com>
Fecha: Sábado, Julio 1, 2006 10:02 am
Asunto: Re: [boost] Interest in a flyweight library?

> On 6/28/06, Joaquín Mª López Muñoz <joaquin <at> tid.es> wrote:
[...]
> > So, is there interest in having such a lib in Boost? Please note 
> > that the provided implementation is still a primitive one, but
> > OTOH it does have all the advertised functionality, so one can
> > use it to test it locally and form an opinion about its
> > suitability: if somebody, for instance, can plug it into some
> > scenario with massive quantities of elements, I'd
> > appreciate knowing about resulting memory and performance
> > improvements.
> >
> > In case this raises interest, I can turn the thing into a more 
> > fleshed out proposal during the summer.
> 
> This library seems like it could be excellent, lets get a review 
> going!

Thank you for your enthusiasm :) I'm afraid it'll take me weeks
to come up with something complete enough to apply for a review.
But given that there's quite some interest, I think I'll put
myself to work on it.

> As others have noted, of all the languages I have looked at, I've
> never heard the term "flyweight", only "interned".  Where does
> "flyweight" come from?  This library might get more recognition if
(Continue reading)

Permalink | Reply | 0 comments |
headers
Douglas Gregor | 1 Jul 18:01
Picon
Picon
Favicon

Boost regression notification (2006-07-01 [RC_1_34_0])

Boost Regression test failures
Report time: 2006-07-01T08:23:26Z

This report lists all regression test failures on release platforms.

Detailed report:
  http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/issues.html

The following platforms have a large number of failures:
  vc-6_5-stlport

892 failures in 59 libraries (451 are from non-broken platforms)
  algorithm/minmax (0 of 2 failures are from non-broken platforms)
  algorithm/string (1)
  any (0 of 1 failures are from non-broken platforms)
  array (0 of 3 failures are from non-broken platforms)
  assign (0 of 7 failures are from non-broken platforms)
  bind (0 of 17 failures are from non-broken platforms)
  concept_check (1)
  config (0 of 5 failures are from non-broken platforms)
  conversion (1 of 5 failures are from non-broken platforms)
  crc (0 of 1 failures are from non-broken platforms)
  date_time (2)
  disjoint_sets (0 of 1 failures are from non-broken platforms)
  dynamic_bitset (0 of 3 failures are from non-broken platforms)
  filesystem (4 of 9 failures are from non-broken platforms)
  foreach (0 of 10 failures are from non-broken platforms)
  format (0 of 4 failures are from non-broken platforms)
  function (0 of 8 failures are from non-broken platforms)
  functional (0 of 1 failures are from non-broken platforms)
(Continue reading)

Permalink | Reply | 0 comments |
headers
JOAQUIN LOPEZ MU?Z | 1 Jul 18:09
Picon
Gravatar

Re: Interest in a flyweight library?

----- Mensaje original -----
De: Jeff Garland <jeff <at> crystalclearsoftware.com>
Fecha: Sábado, Julio 1, 2006 5:52 pm
Asunto: Re: [boost] Interest in a flyweight library?

> JOAQUIN LOPEZ MU?Z wrote:
> 
> > 
> > Please see my previous answer to Steve Harris. It'd help me
> > a lot if, for uniformity's sake, name proposals could be given
> > in this format:
> > 
> >   lib name / namespace names / main utility
> > 
> > like for instance:
> > 
> >   Boost.Intern / boost::intern / boost::interned<>
> > 
> > So, cast your vote :)
> 
> I have a problem with these names -- Boost.intern sounds like a 
> developer that should be working on an SOC project.  'Interned'
> sounds like what happens when  someone dies and is buried
> -- not too pleasant. 

:)

> I think flyweight is better, although maybe some variant of 'wrapper'
> might be better.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane