RE: [boost] lexical_cast(Was: FYI)

[Bjorn . Karlsson]

> From: Dave Gomboc [mailto:[EMAIL PROTECTED]
> Yeah, I was aware that work had been done on it, but as of a couple of
> days ago CVS had no change to lexical_cast.hpp, which is what 
> prompted me
> to write my original query.  Could whoever did the update 
> please commit it
> to CVS?

Kevlin Henney, the author of lexical_cast, is currently reviewing and
brushing up some minor details in the proposal by Terje Slettebo
(http://groups.yahoo.com/group/boost/files/lexical_cast_proposition/lexical_
cast_proposition.zip). It should only be a day or two before the CVS will
contain the new version. I know that people have been waiting a _really_
long time for this to happen, and as has been stated before, the changes
will be part of 1.30.0. To all of you who've been waiting, thanks for your
patience! 

Bjorn Karlsson
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] [BGL]edge connectivity code won't compile

[Vladimir Prus]

Hi J-S,

> Hi, Volodya
>
> Following arethe error messages:
> --
> \boost-g\boost_1_29_0\boost\property_map.hpp(151) : error C2039:
> 'reference'
>
> : is not a member of 'boost::property_traits'
>
> with
> [
> PA=boost::default_color_type *
> ]
> g:\boost-g\boost_1_29_0\boost\graph\properties.hpp(52) : see
> declaration of 'boost::property_traits'
> with
> [
> PA=boost::default_color_type *
> ]

Could you please try adding 

typedef default_color_type& reference; 

to the specialization of property_traits for default_color_type, which
is in file boost/graph/properties.hpp (line 56 in CVS version)

If this fixes the error, I'll make the fix in CVS.

> > > Basically, I got two errors:
> > > 1)C1076--I have changed from /Gm to /Zm1000, and it went way.

Did you posted compiler output for this error, or I missed it?

Thanks,
Volodya


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: CVS repository locked?

[Vladimir Prus]

Beman Dawes wrote:
> At 11:04 AM 3/6/2003, Vladimir Prus wrote:
>  >I see this, when doing update:
>  >
>  >cvs server: [07:46:57] waiting for beman_dawes's lock in
>  >/cvsroot/boost/boost/tools/build
>  >.
>  >cvs server: [08:02:58] waiting for beman_dawes's lock in
>  >/cvsroot/boost/boost/tools/build
>  >
>  >Beman, is there anything you can do about it? Like killing client or
>  >updating again? Or
>  >ony sourceforge admins are in position to fix this?
>
> If it really was a hung lock, only the sourceforge people can unlock it.
>
> But more likely you just happened to access during the more than an hour it
> took to apply the merged_to_RC_1_30_0 tag. There was a delay of more than
> ten minutes right at the end with no apparent activity.

I had this for more than 10 mins, but now everything's OK. 

> I don't know why it took so long, unless it had to do with tagging at a
> past date rather than the current state.

More than an hour? Well, tagging is O(N) is CVS, after all...

- Volodya
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Proposal: static_string library

[Terje Slettebø]

>From: "Robert Klarer" <[EMAIL PROTECTED]>

> Terje Slettebø wrote:
>
> > If run-time computation is ok, and that one only wants to avoid
dynamical
> > allocation, then one might do something like I used in another posting
in
> > this thread:
> >
> > template
> > class fixed_size_string;
> >
> > template
> > fixed_size_string operator+(const
> > fixed_size_string &s1, const fixed_size_string
> > &s2);
>
> An implementation of basic_string that uses the small string optimization
already
> implements something very close to this.  We don't need to specify an
entirely new
> kind of string to benefit from this technique.

True, for small strings. However, that particular technique doesn't work for
larger strings. I just mentioned the above, since it appeared that much of
the interest for static_string came from the lack of dynamical allocation,
so I wanted to point out that you don't need compile-time computation for
that.

Naturally, a compile-time string would be much less expensive to copy
around, though, since it's all encoded in the type, and there would be no
run-time cost for many operations.


Regards,

Terje

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Proposal: static_string library

[Robert Klarer]

Beman Dawes wrote:

> Unfortunate? Is that one of those understatement jokes Canadians are known
> for? I'd say it is way worse that "unfortunate" - it is ugly and error
> prone.

I didn't want to prejudice the group with judgemental language like "ugly and
error prone." :-)

I certainly recognize that the syntax is terrible, but the syntax isn't the
essence of this proposal.  I'm really proposing a general direction toward a
solution to a problem that, as you have mentioned, has already been discussed by
the performance subgroup of the C++ committee.  The details can be changed.

One thing that I'm really interested in discussing is whether the problem that
this library addresses is one that's worth solving.  Is there sufficient interest
in solving the problem (and others like it) that a change to the language is
justified?

> * Can you come up with a small, workable language extension that eases
> those problems?

Here's a list of possibilities, with some discussion.  Please note that I'm not
arguing that any of these ideas is especially desirable.  They're just ideas to be
explored.

idea #1: string literals as template arguments

The extensions subgroup of the committee has discussed this one briefly.
Interestingly, this extension is not, by itself, sufficient for the implementation
of a static_string.  The reason for this is that the expression "str[index]" is
not currently a compile-time constant expression.  Since individual characters
cannot be selected from a string literal at compile-time, it would be impossible
to implement compile-time versions of most of the basic_string (and static_string)
member functions.  To be useful for creating a static_string library, then, this
idea really involves more than one change to the core language.  If these changes
were in fact made to the language, would we still need a static_string library?  I
suppose that the answer to this question depends on the number and nature of those
changes.

idea #2: a magic operator

This idea is simple, but it might not be of sufficiently general utility to
justify its addition to the language.  The magic operator would instruct the C++
compiler to rewrite a string literal by replacing it with a comma-separated list
of character literals.  Then the initialization syntax for a static_string would
look like this:

boost::static_string str;
// becomes: boost::static_string<'m', 'y', ' ', 't', 'e', 'x', 't'> str;

Please note that I chose to name the operator "magic_string_unglue" for the
purpose of this example only.  I'm not seriously suggesting that this is a great
name for a C++ keyword. :-)

idea #3: preprocessor tricks

I don't believe that a preprocessor trick can help, actually, though I'd be happy
to be proven wrong.   The basic lexical unit that can be manipulated by the
preprocessor is the token.   The individual characters that compose a token aren't
really available for manipulation.  The preprocessor has a token-pasting macro,
but no token-unpasting macro, for example.

> Lack of internationalization support is also a serious concern.

I'm not sure whether this addresses that concern, but I had thought that I would
wait until more of the issues surrounding static_string were resolved before I
began to implement a static_wstring.


Trying-not-to-appear-crazy,

Robert Klarer


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Proposal: static_string library

[Robert Klarer]

Terje Slettebø wrote:

> If run-time computation is ok, and that one only wants to avoid dynamical
> allocation, then one might do something like I used in another posting in
> this thread:
>
> template
> class fixed_size_string;
>
> template
> fixed_size_string operator+(const
> fixed_size_string &s1, const fixed_size_string
> &s2);

An implementation of basic_string that uses the small string optimization already
implements something very close to this.  We don't need to specify an entirely new
kind of string to benefit from this technique.


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers

[Aleksey Gurtovoy]

Ralf W. Grosse-Kunstleve wrote:
> This requires active participation by the developers. We've spent a 
> lot of time setting up the auto-builds to enable developers to see 
> immediately when their changes break portability. We've also made a 
> major effort cleaning up 1.29.0. That seemed like a good start to me, 
> but it didn't work out for lack of participation from the developer's
> side. So now I am stuck with messages like the one posted before:
> 
> cc-3192 CC: ERROR File = zzstrip.cpp, Line = 71667
>   The nontype "boost::mpl::fold_backward boost::mpl::arg<1>>::rebind"
>   is not a class template.
> 
>   static const int arity = 3; typedef Sequence arg1; 
> typedef State arg2;
> typedef BackwardOp arg3;   struct rebind; }; template< 
> typename T1,typename
> T2,typename T3 > struct fold_backward ::rebind { 
> template< typename
> U1,typename U2,typename U3 > struct apply : fold_backward< 
> U1,U2,U3 > { };
>   
>  
>   
>  
>^
> 
> If one of the developers could at least comment on this I might give it
> another try. Otherwise I estimate it would take me weeks to 
> reverse-engineer what is happening here.

Ralf, I will definitely look into it tonight and get back to you.

Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Variant Library Review

[Eric Friedman]

Eric Friedman wrote:
> As I said above, this was the result of a typo and certainly not intended
to
> acknowledge your prior work. (Indeed, the sandbox CVS history shows this.)

Speaking of typos, what I *meant* to say...

As I said above, this was the result of a typo and certainly not intended to
avoid acknowledging your prior work. (Indeed, the sandbox CVS history shows
this.)

Thanks,
Eric



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Variant Library Review

[Eric Friedman]

Andrei Alexandrescu wrote:
> By the way, any chance to tweak the acknowledgments a bit. They mention
> "Generic: Discriminated Unions" Part 1, Part 2, Part 3. C/C++
> Users Journal. 2002", but the text doesn't mention the earlier
publication,
> which is
> http://oonumerics.org/tmpw01/alexandrescu.pdf. I think that's where
various
> kinds of visitation in the context of C++ discriminated unions were first
> considered a core feature, together with a number of more obvious things
> (that made it or not), such as using typelists, computing alignment, and
> dispatching via pseudo-vtables.

Can do. We had excluded this since you reference it in your later articles.
But I suppose it makes sense to acknowledge the history.


> Also, the ack text doesn't say whether the work above influenced at all
the
> library design or is just previous work developed unbeknownst to the
> authors - the Generic reference is specified in the
> bibliography as [Ale02] without being referred to at all.

Sorry this is a typo that was carried over from an old version of the docs.
Where the acknowledgments read:

  "Andrei Alexandrescu's work in [Ale01] inspired the library's design."

It should instead reference [Ale02]. The problem was that I mistyped the
publication year for the Generic articles in an earlier version
of the docs.

So I will fix this. As well, I will update the docs to reflect the influence
of the oonumerics paper on the design of the library.


> If the authors were aware of the previous work and used it as a source of
> inspiration, it's nice to give credit where it is due. It costs nothing
and
> it is considerate. Just recently I failed to give due credit and boy it
> didn't feel good.

As I said above, this was the result of a typo and certainly not intended to
acknowledge your prior work. (Indeed, the sandbox CVS history shows this.)

Sorry for any misunderstandings.

Thanks,
Eric



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Eric Ford's Unit package with MSVC 7.0

[Paul A. Bristow]

Sadly, example1.cpp fails with MSVC 7.0  - sigh :-(

with language extension allowed:

-- Build started: Project: Units, Configuration: Debug Win32 --

Compiling...
example1.cpp
j:\Cpp\Units\fraction_ct.hpp(44) : fatal error C1001: INTERNAL COMPILER ERROR
(compiler file 'msc1.cpp', line 2844)
 Please choose the Technical Support command on the Visual C++
 Help menu, or open the Technical Support help file for more information

Build log was saved at "file://j:\Cpp\Units\Debug\BuildLog.htm"
Units - 1 error(s), 0 warning(s)

with disable language extensions

-- Build started: Project: Units, Configuration: Debug Win32 --

Compiling...
example1.cpp
j:\Cpp\Units\fraction_ct.hpp(42) : warning C4253:
'ebf::fraction_ct::FracConcept::constraints' : forming a pointer-to-member
requires explicit use of the address-of operator ('&') and a qualified name
j:\Cpp\Units\fraction_ct.hpp(51) : see reference to class template
instantiation 'ebf::fraction_ct::reduce_frac' being compiled
j:\Cpp\Units\fraction_ct.hpp(43) : error C2970: 'boost::math::static_gcd' :
template argument 'Value1' : invalid use of non-integral-constant static
variable 'num' as non-type argument
I:\boost_1_29_0\boost\math\common_factor_ct.hpp(170) : see declaration
of 'boost::math::static_gcd'
j:\Cpp\Units\fraction_ct.hpp(43) : error C2970: 'boost::math::static_gcd' :
template argument 'Value2' : invalid use of non-integral-constant static
variable 'den' as non-type argument
I:\boost_1_29_0\boost\math\common_factor_ct.hpp(170) : see declaration
of 'boost::math::static_gcd'
j:\Cpp\Units\fraction_ct.hpp(44) : fatal error C1903: unable to recover from
previous error(s); stopping compilation

Build log was saved at "file://j:\Cpp\Units\Debug\BuildLog.htm"
Units - 3 error(s), 1 warning(s)


Info on the error is:
'class' : template argument 'parameter' : invalid use of non-integral-constant
static variable 'var' as non-type argument

You cannot use the name or address of a static variable as a template argument.
For example, the following code shows how this error would be generated:

// C2970.cpp
static int si;   // C2970 cannot use static variable in templates
template  class X {};
template  class Y{};
X anX;
Y<&si> aY;
int main()
{
}

Can you see a way around this?

Can anyone try with 7.1?

Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB  UK
+44 1539 561830   Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]




___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers

[Ralf W. Grosse-Kunstleve]

--- David Abrahams <[EMAIL PROTECTED]> wrote:
> I think it would be better to make the trunk work,

This requires active participation by the developers. We've spent a lot of time
setting up the auto-builds to enable developers to see immediately when their
changes break portability. We've also made a major effort cleaning up 1.29.0.
That seemed like a good start to me, but it didn't work out for lack of
participation from the developer's side. So now I am stuck with messages like
the one posted before:

cc-3192 CC: ERROR File = zzstrip.cpp, Line = 71667
  The nontype "boost::mpl::fold_backward>::rebind"
  is not a class template.

  static const int arity = 3; typedef Sequence arg1; typedef State arg2;
typedef BackwardOp arg3;   struct rebind; }; template< typename T1,typename
T2,typename T3 > struct fold_backward ::rebind { template< typename
U1,typename U2,typename U3 > struct apply : fold_backward< U1,U2,U3 > { };
   
   
   ^

If one of the developers could at least comment on this I might give it another
try. Otherwise I estimate it would take me weeks to reverse-engineer what is
happening here.

Ralf


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Proposal: static_string library

[Terje Slettebø]

>From: "Beman Dawes" <[EMAIL PROTECTED]>

> At 05:58 PM 3/5/2003, Robert Klarer wrote:
>
>  >The purpose of the static_string library is to offer an alternative to
>  >string literals and the standard type const std::string.  A
>  >static_string uses no dynamically allocated memory, and is more
>  >efficient at execution time than either string literals or
>  >basic_strings.
>
> Yes, agreed. That would be useful. IIRC, the C++ committee's performance
> working groups has talked about such a string in the past.
>
> There are questions that come to mind:
>
> * Can you come up with a small, workable language extension that eases
> those problems?

Josuttis/Vandevoorde mentions being able to pass string literals as template
parameters as a possible future extension. That would be a clean way to
handle it. Possibly could there also be a general solution regarding passing
compound values. At the moment, values of class type can't be passed as
template parameters.

> * Can you come up with an alternate design that gives up a tiny bit of
> efficiency (one pointer indirection perhaps) but then allows reasonable
> construction and internationalization?

If run-time computation is ok, and that one only wants to avoid dynamical
allocation, then one might do something like I used in another posting in
this thread:

template
class fixed_size_string;

template
fixed_size_string operator+(const
fixed_size_string &s1, const fixed_size_string
&s2);

etc.


Regards,

Terje

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] coding style

[David Abrahams]

Terje Slettebø <[EMAIL PROTECTED]> writes:

>>From: "Joel Young" <[EMAIL PROTECTED]>
>
>> I find other people's code with long linelengths is cause by either too
>> much nesting or by putting too many concepts on one line...
>
> That doesn't have to be the case. There can easily be lines longer than 80
> characters, which only contain one statement or expression, i.e. one
> concept, regardless of nesting.

Please take this conversation elsewhere!

Thanks,
Dave (as moderator)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Proposal: static_string library

[Terje Slettebø]

>From: "Phil Nash" <[EMAIL PROTECTED]>

> > Robert Klarer wrote:
> > > The syntax for declaring a static_string is unfortunate, but once it
has
> > > been declared, a static_string's interface is (almost*) the same as
that
> > > of a const std::string.
> > Yes, you right it's unfortunate and IMHO is not appropriate for a wide
> use.
> >
> > >typedef boost::static_string<'s', 't', 'a', 't', 'i', 'c', '_'>
> > > StrType1;
> >
> I have to admit I like the idea of having a std::string interface without
> the overhead of dynamic allocation.

Well, you could get that using ordinary string types, as well, e.g.:

template
class fixed_size_string
{
  // ...

private:
CharType array[Size];
};

However, one thing the static_string may be used for, is for compile-time
computations, including passing it around as a template parameter, as shown
in the OP. The interface is rather inconvenient, though. I played some
around with this about half a year ago, too
(http://article.gmane.org/gmane.comp.lib.boost.devel/3032). However, I
didn't pursue it, because of the difficult way of specifying strings.

> My biggest reservation would by the char-only restriction...

You could also use wchar_t, of course, or any fundamental type, if that's
what you mean?


Regards,

Terje

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] coding style

[Terje Slettebø]

>From: "Joel Young" <[EMAIL PROTECTED]>

> I find other people's code with long linelengths is cause by either too
> much nesting or by putting too many concepts on one line...

That doesn't have to be the case. There can easily be lines longer than 80
characters, which only contain one statement or expression, i.e. one
concept, regardless of nesting.


Regards,

Terje

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Proposal: static_string library

[David Abrahams]

Beman Dawes <[EMAIL PROTECTED]> writes:

> Lack of internationalization support is also a serious concern.

What would internationalization support look like on a static string?!

> There are questions that come to mind:
>
> * Can you come up with a small, workable language extension that eases
>   those problems?
>
> * Can you come up with an alternate design that gives up a tiny bit of
>   efficiency (one pointer indirection perhaps) but then allows
>   reasonable construction and internationalization?

That's potentially a huge difference.  With a truly static string you
can do computations at compile-time.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Proposal: static_string library

[Beman Dawes]

At 05:58 PM 3/5/2003, Robert Klarer wrote:

>There's already been some discussion of this library under the thread
>"Proposal: strings as template parameters," but static_string hasn't
>been the subject of its own thread, so I'm starting this one.  I'd like
>to solicit opinions about this project.  Is it worthwhile?
>
>The purpose of the static_string library is to offer an alternative to
>string literals and the standard type const std::string.  A
>static_string uses no dynamically allocated memory, and is more
>efficient at execution time than either string literals or
>basic_strings.
Yes, agreed. That would be useful. IIRC, the C++ committee's performance 
working groups has talked about such a string in the past.

But...

>The syntax for declaring a static_string is unfortunate...
>
>  boost::static_string<'s', 't', 'a', 't', 'i', 'c', '_'> StrType1;
Unfortunate? Is that one of those understatement jokes Canadians are known 
for? I'd say it is way worse that "unfortunate" - it is ugly and error 
prone.

Lack of internationalization support is also a serious concern.

There are questions that come to mind:

* Can you come up with a small, workable language extension that eases 
those problems?

* Can you come up with an alternate design that gives up a tiny bit of 
efficiency (one pointer indirection perhaps) but then allows reasonable 
construction and internationalization?

Wondering-out-loud,

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] coding style

[Brian Gray]

I'd say it's primarily the 80-column terminal limit that is the 
reasoning for this.  I personally only go to 79 columns so that when I 
work on a terminal and I type that 80th line the insertion pointer 
doesn't wrap.

Aside from that, on my current monitor (1152 pixels wide), I can get 2 
CodeWarrior source windows side-by-side at 80 columns, but not much 
more if I want to be able to see desktop icons on the side of it.  And 
it's very useful to have those two, usually a source file and its 
accompanying header.  So even if there were no such thing as a 
text-based terminal anymore, I'd still be in favor of limiting the 
number of columns to about what we're using.

 -- Brian

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] coding style

[David Abrahams]

"Rozental, Gennadiy" <[EMAIL PROTECTED]> writes:

>> 
>> > in favor of 80-column text is just that
>> 
>> > So I wondered what the general opinion of boost developers 
>> is on this issue,
>> 
>> I am in favor of 72 column lines myself.  This allows me to have three
>> comfortable columns of code on the screen at once.  
>
> This is namely the reason why I would prefer longer lines. On majority on
> modern monitors 80-column text fit to left 1/3 of monitor space, leaving 2/3
> blank.
>>From "idiological prospective" you won't find too many reasons to defend
> 80-column limitation. We tend to use more and more explicit namespace
> specifications, a lot of template parameters, effectively making even simple
> assignment to spread on multiple lines (and less readable) would you stick
> to 80-column. Unless you try to put several statements on the same line, I
> prefer to see it long not separated. On the other hand, I admit that there
> are still as lot of people using vi through terminal connection. 

OK, this is getting OT.  Let's get back to library design, please.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] solaris, once again

[Mark Rodgers]

From: "Marc Borgers" <[EMAIL PROTECTED]>
> I am having problems with the shared_ptr on Forte 6.2: when I compile 
> my code into an application, it all seems to work. When I am compiling 
> a static library, I had to compile it with the -misalign option. 

Interesting. I haven't got as far as running anything yet but when (if!) 
I do, I'll let you know if I have the same problem.

Mark

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] coding style

[Rozental, Gennadiy]

> 
> > in favor of 80-column text is just that
> 
> > So I wondered what the general opinion of boost developers 
> is on this issue,
> 
> I am in favor of 72 column lines myself.  This allows me to have three
> comfortable columns of code on the screen at once.  

This is namely the reason why I would prefer longer lines. On majority on
modern monitors 80-column text fit to left 1/3 of monitor space, leaving 2/3
blank.
>From "idiological prospective" you won't find too many reasons to defend
80-column limitation. We tend to use more and more explicit namespace
specifications, a lot of template parameters, effectively making even simple
assignment to spread on multiple lines (and less readable) would you stick
to 80-column. Unless you try to put several statements on the same line, I
prefer to see it long not separated. On the other hand, I admit that there
are still as lot of people using vi through terminal connection. 

Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Re: Eric Ford's Unit package

[Paul A. Bristow]

I assumed you knew it did - I'll give it a go with MSVC 7.0.

Paul


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Eric Ford
> Sent: Thursday, March 06, 2003 7:15 PM
> To: [EMAIL PROTECTED]
> Subject: [boost] Re: Eric Ford's Unit package
>
>
> > > This promises to meet a massive need,
> > > but for me must wait until I get MSVC 7.1
> > > which I understand includes partial specialisation.
> > I don't see why partial specialization should be required for this
> > application.
>
>
> I suppose the most relevant thing is for someone to try it with a
> compiler that doesn't like them.  Paul, did you actually try compiling
> my code?  If not, may you could give it a try?  If so, can you let me
> know exactly where your compiler wasn't happy?
>
> Thanks,
> Eford
>
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers

[David Abrahams]

"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:

> --- David Abrahams <[EMAIL PROTECTED]> wrote:
>> "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
>> 
>> > Is the __BORLANDC__ branch different from (not as good as) the
>> > is_base_and_derived implementation in 1.29.0?
>> 
>> cvs diff knows for sure.
>
> Sure, but this "chasing tails" game is impractical. If nobody else
> cares about MIPSpro compatibility we will just keep using 1.29.0.

What will you do when 1.31.0 comes out?

> I'd like to suggest opening a 1.29 maintenance branch. I've
> accumulated a few minor patches that make Boost.Python 1.29.0
> compatible with Python 2.3. If I could check these patches in they
> would be available to everybody.

You're welcome to do that as far as I'm concerned.  I think it would
be better to make the trunk work, but only you can decide what's worth
spending your time on.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Re: Eric Ford's Unit package

[David Bergman]

Hugo wrote:

[snip]
> I have found in the past that there is a need to
> distinguish between dimension handling and unit handling.
> 
> In the case of a physical calculation, I usually ensure that 
> the code works with a self consistent set of units, and thus 
> only need dimensionality, compile time, code.
> 
> Units then become important only in the user interface, and
> I have a list of the units used in the physical calculation
> for each dimension.
> 
> This is obviously only one way of using dimensions and units, 
> but I think an important one. The usual exception to the 
> above is for money where you are working with multiple currencies.

One could actually regard the different currencies as realizing
different dimensions. After all, a dollar bill is quite different from a
British pound bill, although one can apply a certain process
(exchange...) to convert between these dimensions.

For some ideas about how one can implement the dimension/unit framework,
look at the Java-based system Frink
(http://futureboy.homeip.net/frinkdocs/) implemented by Alan Eliasen.

/David

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Eric Ford's Unit package

[Eric Ford]

> > This promises to meet a massive need,
> > but for me must wait until I get MSVC 7.1
> > which I understand includes partial specialisation.
> I don't see why partial specialization should be required for this
> application.

Actually, I'm not sure if what I'm doing counts.  I've never really paid attention
to this.  

It is important to allow appropriate arithmetic operations between
quantities with different dimensions.  It is also be important to
allow for numeric type promotion.  (Although, this is only crudely
implemented (as promote_numeric+type for now).  I'm hoping
someone else will offer code for this.  Fernando C?)  It's important
to keep separate dimensioned quantities which are in different unit
systems (e.g., we don't want to add meter (length in SI) and second
(length in relativistic units).

So I use templates which take multiple parameters, and then specialize
them where some of the template parameters are fixed and other
template parameters are not fixed.  Sorry if this is bad terminology.

Here's an example of the code...

Each Dimensioned type is a typedef for base_dimen.
NumT is the numeric type used to store the number.
SystemT specifies what dimension system (e.g., standard, relativistic) is being used.
DimListT is a list of fractions which specifies the dimensions of the particular 
variable in terms of the base dimensions.

When a user multiplies (divides) two dimensioned quantities, they generally get
back another dimensioned quantity.  However, if they multiply (divide)
two quantities with the same (inverse) dimensions, then they can get back a pure 
number.

 using ebf::units::mks_double;
 length l = 3 * meter, w = 2 * meter;
 area a = l * w;  // length * length must return an area
 pure r = l / w;  // length / length can return a pure number (pure's DimListT = 
0,0,0,...)
 double rr = l / w; // length / length can also return a non-dimensioned type 
(double/double -> double)

I acheive this flexibility with the following code in 
base_dimen:

  // helper classes to allow returning scalar when possible
  template
  struct div_return_type
  {
  private:
BOOST_CLASS_REQUIRE(ArgNumericType, ebf, NumericConcept);
BOOST_CLASS_REQUIRE(ArgDimList, ebf::dimensions, DimlistConcept);
typedef typename ebf::promote_numeric_type::type 
return_numeric_type;
typedef typename div_diml::diml_type return_diml_type;
  public:
typedef base_dimen type; 
 
  };
  
  // Specialization to allow for returning non-dimensioned quantity.  
  template
  struct div_return_type
  {
  private:
BOOST_CLASS_REQUIRE(ArgNumericType, ebf, NumericConcept);
typedef typename ebf::promote_numeric_type::type 
return_numeric_type;
  public:
typedef return_numeric_type type;   
  };
  
  // Mixed dimensions operations (within system)
  template
  const typename div_return_type::type
  operator/(const base_dimen rhs) const
  { return typename div_return_type::type 
(pure()/rhs.pure());   };

I'm not sure if this specialization above counts as partial template
specialization or not.  I'm sure some boosters must know.  

I suppose the most relevant thing is for someone to try it with a
compiler that doesn't like them.  Paul, did you actually try compiling
my code?  If not, may you could give it a try?  If so, can you let me
know exactly where your compiler wasn't happy?

Thanks,
Eford

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: CVS repository locked?

[Beman Dawes]

At 11:04 AM 3/6/2003, Vladimir Prus wrote:

>I see this, when doing update:
>
>cvs server: [07:46:57] waiting for beman_dawes's lock in
>/cvsroot/boost/boost/tools/build
>.
>cvs server: [08:02:58] waiting for beman_dawes's lock in
>/cvsroot/boost/boost/tools/build
>
>Beman, is there anything you can do about it? Like killing client or
>updating again? Or
>ony sourceforge admins are in position to fix this?
If it really was a hung lock, only the sourceforge people can unlock it.

But more likely you just happened to access during the more than an hour it 
took to apply the merged_to_RC_1_30_0 tag. There was a delay of more than 
ten minutes right at the end with no apparent activity.

I don't know why it took so long, unless it had to do with tagging at a 
past date rather than the current state.

Let me know if you continue to have problems,

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers

[Ralf W. Grosse-Kunstleve]

--- David Abrahams <[EMAIL PROTECTED]> wrote:
> "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> 
> > Is the __BORLANDC__ branch different from (not as good as) the
> > is_base_and_derived implementation in 1.29.0?
> 
> cvs diff knows for sure.

Sure, but this "chasing tails" game is impractical. If nobody else cares about
MIPSpro compatibility we will just keep using 1.29.0.

I'd like to suggest opening a 1.29 maintenance branch. I've accumulated a few
minor patches that make Boost.Python 1.29.0 compatible with Python 2.3. If I
could check these patches in they would be available to everybody.

Ralf
 

__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] New release procedure?

[Beman Dawes]

At 11:38 AM 3/6/2003, Beman Dawes wrote:

>At 11:35 AM 3/5/2003, David Abrahams wrote:
>
> >>> The multiple merge thing is probably much less of an issue when
> >>> working from trunk to branch, but it still could be useful to have
> >>> the tag.  I would call the tag "merged_to_".
> >>
> >> So this is something each developer would do when merging to
> >> the branch from MAIN if they want 'extra' information
> >> in CVS about where the merge took place?  If this is
> >> correct, I'm generally opposed to this extra step as
> >> I don't see what it is going to buy you above and beyond
> >> what you can get in CVS log command.  Am I missing
> >> something?
> >
> >If you make a big change on the trunk and need to merge to the
> >branch, and then you do it again, you want
> >
> > cvs merge -jmerged_to_RC_whatever -jHEAD
> >
> >In order to make the merge work properly.  If the release manager
> >doesn't tag the head at the merge point, the first person to merge
> >from trunk to branch messes up that arrangement.
more/release_procedures.htm has been updated to reflect these discussions.

The changes to more/release_procedures.htm were made on the main trunk, and 
then merged into RC_1_30_0, and the process repeated several times as the 
instructions were refined and corrected.

In other words, the procedure was applied to its own documentation:-)

At least in WinCVS, this was a good deal easier than the old way IMO.

Please take a look at more/release_procedures.htm and suggest any 
corrections necessary.

Thanks,

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Eric Ford's Unit package

[Hugo Duncan]

On 6 Mar 2003 00:34:23 -, Eric Ford <[EMAIL PROTECTED]> wrote:

This looks most interesting, and there most definitely remains a great 
need for a units handling package.
Definitely!

- SIUnits includes some "advanced" features which introduce run-time
cost, while my library does not include such features.  The main
example is the ability within SIUnits to change at runtime that a
dimensioned quantity should be displayed in terms of various units
(introducing an automatically applied scale factor) and with various
labels (used when printing).  While I "power user" could implement
this within my framework (e.g., by specializing scale and label in
mks_tag), I don't see much point.  If I want a time in years rather
than seconds (default in mks), I can easily write cout <<
time_till_graduation / year;
I have found in the past that there is a need to
distinguish between dimension handling and unit handling.
In the case of a physical calculation, I usually ensure that
the code works with a self consistent set of units, and thus
only need dimensionality, compile time, code.
Units then become important only in the user interface, and
I have a list of the units used in the physical calculation
for each dimension.
This is obviously only one way of using dimensions and units,
but I think an important one. The usual exception to the above
is for money where you are working with multiple currencies.
A couple of use cases, that I am unsure would be handled by the
current proposal:
I have a "Cost" class that records costs for different factories
in different countries.  The "unit" used for each is factory
is different, eg USD for factories in US, GBP for those in UK.
ie the unit varies per instance.
A similar situation occurs for "dimensions" of physical units.
eg. if you want a list of quantities used per output weight
or output pieces, then each item in the list has different
dimensions, eg. Watt seconds/time, Litre/piece, number/kg.
In this case I obviously have to give up the type checking,
but still need to be able to record a dimension, to allow
display in appropriate units.
- My library allows for users to add qualifiers to dimensioned
quantities which are strongly typed by default.  Users may choose weak
typing (e.g., automatic conversion from mass of apples to mass of
fruit or allowing a sum of mass of apples and mass of oranges to equal a
mass of fruit) by relatively easy specializations.
Excellent!

Hugo

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] coding style

[Joel Young]

From: Paul Beardsley <[EMAIL PROTECTED]>

> in favor of 80-column text is just that

> So I wondered what the general opinion of boost developers is on this issue,

I am in favor of 72 column lines myself.  This allows me to have three
comfortable columns of code on the screen at once.  It also makes printing
easy.  It means that I don't have to scan my eyes over and over and over
to the right to see what a line means.  I don't have to keep scanning
six inches from left to right, rather than up and down a half cm.

Also editing long lines is more difficult.  It is much easier (for me)
to comment out lines and insert different lines of a multi-line
statement.  It is easier to see what is changed with shorter lines.
Patches are clearer with short line lengths.

I find other people's code with long linelengths is cause by either too
much nesting or by putting too many concepts on one line...

Joel
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers

[David Abrahams]

"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:

> Is the __BORLANDC__ branch different from (not as good as) the
> is_base_and_derived implementation in 1.29.0?

cvs diff knows for sure.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers

[Ralf W. Grosse-Kunstleve]

--- David Abrahams <[EMAIL PROTECTED]> wrote:
> There are any number of ways you could try reformulating this to make
> the error go away.  At worst you could try the __BORLANDC__ branch in
> is_base_and_derived.hpp.
> 
> Another approach:
> 
> template 
> static type_traits::yes_type bd_helper(D const volatile *, T);
> 
> template 
> static type_traits::no_type  bd_helper(B const volatile *, int);

That doesn't work because older EDG's don't support the bd_helper syntax.
To be sure I just tried it again and it failed.

Using the __BORLANDC__ branch got me a little further. Some Boost.Python tests
compile and run.

Is the __BORLANDC__ branch different from (not as good as) the
is_base_and_derived implementation in 1.29.0?

There are many new errors when compiling the Boost.Python tests, but most of
them are identical:

mipspro-C++-action
/var/tmp/rwgk/bjam/libs/python/test/bin/embedding.test/mipspro/debug/embedding.o
cc-3192 CC: ERROR File =
/u1/rwgrosse/rc_1_30_0/boost/boost/mpl/fold_backward.hpp, Line = 47
  The nontype "boost::mpl::fold_backward>::rebind"
  is not a class template.

  BOOST_MPL_AUX_LAMBDA_SUPPORT(3,fold_backward,(Sequence,State,BackwardOp))
  ^

I've preprocessed the source of test/embedding.cpp and stripped out all #line
directives. The error message then becomes:

cc-3192 CC: ERROR File = zzstrip.cpp, Line = 71667
  The nontype "boost::mpl::fold_backward>::rebind"
  is not a class template.

  static const int arity = 3; typedef Sequence arg1; typedef State arg2;
typedef BackwardOp arg3;   struct rebind; }; template< typename T1,typename
T2,typename T3 > struct fold_backward ::rebind { template< typename
U1,typename U2,typename U3 > struct apply : fold_backward< U1,U2,U3 > { };
   
   
   ^

With the ^ pointing to the beginning of ::rebind.

The full prepocessed, stripped file is here:

http://cci.lbl.gov/~rwgk/tmp/zzstrip.cpp

Are there any insights what the compiler is choking on here?

Thanks,
Ralf


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] [BGL]edge connectivity code won't compile

[J-S Lin]

Hi, Volodya

Following arethe error messages:
--
\boost-g\boost_1_29_0\boost\property_map.hpp(151) : error C2039: 'reference'
: is not a member of 'boost::property_traits'
with
[
PA=boost::default_color_type *
]
g:\boost-g\boost_1_29_0\boost\graph\properties.hpp(52) : see
declaration of 'boost::property_traits'
with
[
PA=boost::default_color_type *
]
g:\boost-g\boost_1_29_0\boost\concept_check.hpp(46) : see reference
to class template instantiation 'boost::ReadablePropertyMapConcept' being
compiled
with
[
PMap=boost::default_color_type *__w64 ,
Key=Vertex
]
g:\boost-g\boost_1_29_0\boost\property_map.hpp(209) : see reference
to function template instantiation 'void
boost::function_requires(boost::type *)' being compiled
with
[
T=boost::ReadablePropertyMapConcept
]
g:\boost-g\boost_1_29_0\boost\property_map.hpp(208) : while
compiling class-template member function 'void
boost::ReadWritePropertyMapConcept::constraints(void)'
with
[
PMap=boost::default_color_type *__w64 ,
Key=Vertex
]
g:\boost-g\boost_1_29_0\boost\concept_check.hpp(46) : see reference
to class template instantiation 'boost::ReadWritePropertyMapConcept' being
compiled
with
[
PMap=boost::default_color_type *__w64 ,
Key=Vertex
]
g:\boost-g\boost_1_29_0\boost\graph\breadth_first_search.hpp(76) :
see reference to function template instantiation 'void
boost::function_requires(boost::type *)' being compiled
with
[
T=boost::ReadWritePropertyMapConcept
]
g:\boost-g\boost_1_29_0\boost\graph\breadth_first_search.hpp(116) :
see reference to function template instantiation 'void
boost::breadth_first_visit(const IncidenceGraph
&,boost::graph_traits::vertex_descriptor,boost::queue<_Tp,_Sequence>
&,boost::bfs_visitor,boost::default_color_type *__w64 )' being compiled
with
[
IncidenceGraph=boost::filtered_graph::type>,boost::keep_all>,
G=boost::filtered_graph::type>,boost::keep_all>,
_Tp=vertex_t,
_Sequence=std::deque>,

Visitors=boost::edge_predecessor_recorder::directed_category,boost::adjacenc
y_list_traits::vertex_descriptor> ,boost::on_tree_edge>
]
g:\boost-g\boost_1_29_0\boost\graph\edmunds_karp_max_flow.hpp(118) :
see reference to function template instantiation 'void
boost::breadth_first_search(const VertexListGraph
&,boost::graph_traits::vertex_descriptor,boost::queue<_Tp,_Sequence>
&,boost::bfs_visitor,boost::default_color_type *__w64 )' being compiled
with
[
VertexListGraph=boost::filtered_graph::type>,boost::keep_all>,
G=boost::filtered_graph::type>,boost::keep_all>,
_Tp=vertex_t,
_Sequence=std::deque>,

Visitors=boost::edge_predecessor_recorder::directed_category,boost::adjacenc
y_list_traits::vertex_descriptor> ,boost::on_tree_edge>
]
g:\boost-g\boost_1_29_0\boost\graph\edge_connectivity.hpp(159) : see
reference to function template instantiation
'boost::property_traits::value_type boost::edmunds_karp_max_flow(Graph
&,boost::graph_traits::vertex_descriptor,boost::graph_traits::vertex_descrip
tor,boost::property_map::type,boost::property_map::type,boost::property_map:
:type,boost::default_color_type *__w64 ,boost::detail::edge_desc_impl )'
being compiled
with
[
PA=boost::property_map::type,
Graph=FlowGraph,
G=FlowGraph,
Property=boost::edge_capacity_t,
Directed=boost::adjacency_list_traits::directed_category,
Vertex=boost::adjacency_list_traits::vertex_descriptor
]


Thanks. I will look into CVS version, meanwhile.

J-S
- Original Message -
From: "Vladimir Prus" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Thursday, March 06, 2003 2:08 AM
Subject: Re: [boost] [BGL]edge connectivity code won't compile


> J-S Lin wrote:
>
> > Hi, I  ran into problems trying to compile the BGL example code,
> > edge_connectivity.cpp. (There are two codes, this is the short one with
> > underscore, the other is hyphen  edge-connectivity.) I used VC7. I have
> > been running other codes without any problem.
>
> Hi,
>
> > Basically, I got two errors:
> > 1)C1076--I have changed from /Gm to /Zm1000, and it went way.
> > 2) C2039--it flagged error "reference is not a member of property map"
and
> > points to boost/property_map.hpp in boost-1-29-0. I have no idea how to
> > fix this one.
>
> I think that in order for somebody to look into the problem, you should
> provide *exact* error messages. The property_map.hpp file is big, and
> guessing what line upsets VC7

Re: [boost] coding style

[David Abrahams]

Paul Beardsley <[EMAIL PROTECTED]> writes:

> I have a question about coding style which maybe fits the list
> criteria of "technical discussion about a library'.
>

You can find answers to your questions at
http://groups.yahoo.com/group/boost/files/coding_guidelines.html

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] coding style

[Greg Colvin]

(d) It makes it easier to work with a fixed-width terminal
or terminal emulator.

You may think this is an obsolete requirment, but I spend
most of my working days using a VT-100 emulator connected
to various servers running just Oracle, gdb, gcc, vi, and
a shell.

At 09:34 AM 3/6/2003, Paul Beardsley wrote:

>Hello,
>
>I have a question about coding style which maybe fits the list criteria of "technical 
>discussion about a library'.
>
>The Boost style guide recommends 80 column text without giving any justification for 
>this.  What is your opinion of this constraint?
>
>The three supporting arguments I hear are 
>
>(a) It makes it possible to print code.  Personally I never print code.  I understand 
>it might be useful given, say, 15 people in a room doing a code review but even then 
>I think it would be better to bring in laptops and PCs and look at the electronic 
>version.  For one thing at least then everyone ends up with the same annotations.
>
>(b) It makes it possible to do side-by-side comparisons of two slightly differing 
>pieces of code.  Occasionally I need to do a comparison but I really try to avoid it 
>- there is something wrong if the development process keeps throwing up the need for 
>a laborious (error-prone) manual comparison of pieces of code.
>
>(c) Reading test over 80 columns makes your eyes tired, that's why typesetters 
>traditionally converged on the 80 column solution.  I think that reading 
>highly-structured code is different to reading straight text, so I don't know if the 
>lessons from straight text carry over.
>
>My arguments for longer-than-80-column lines would be the following.  These arguments 
>apply specifically to header files -
>
>(i) It's easier to parse a header file with one method per line.  Longer lines make 
>this more likely.
>
>(ii) It's preferable to have inline method definitions with the declaration, for 
>short methods.  Longer lines again make this more likely.
>
>(iii) The structure of the code throws up other cases where one method per line makes 
>for readability e.g. overloaded methods benefit from being on consecutive lines so 
>that the first part of the text corresponds directly and only the signatures differ.
>
>The most powerful argument in favor of 80-column text is just that 'everyone does 
>it', or that you cannot anticipate that somebody-somewhere might have a device that 
>needs 80-column text.  But these seem more like arguments by inertia and surely 
>readability is more important.  So I wondered what the general opinion of boost 
>developers is on this issue,
>
>Thanks,
>
>Paul Beardsley.
>
> 
>
>
>
>Do you Yahoo!?
>Yahoo! Tax Center - 
>forms, calculators, tips, and more 

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] coding style

[Paul Beardsley]

Hello,
I have a question about coding style which maybe fits the list criteria of "technical discussion about a library'.
The Boost style guide recommends 80 column text without giving any justification for this.  What is your opinion of this constraint?
The three supporting arguments I hear are 
(a) It makes it possible to print code.  Personally I never print code.  I understand it might be useful given, say, 15 people in a room doing a code review but even then I think it would be better to bring in laptops and PCs and look at the electronic version.  For one thing at least then everyone ends up with the same annotations.
(b) It makes it possible to do side-by-side comparisons of two slightly differing pieces of code.  Occasionally I need to do a comparison but I really try to avoid it - there is something wrong if the development process keeps throwing up the need for a laborious (error-prone) manual comparison of pieces of code.
(c) Reading test over 80 columns makes your eyes tired, that's why typesetters traditionally converged on the 80 column solution.  I think that reading highly-structured code is different to reading straight text, so I don't know if the lessons from straight text carry over.
My arguments for longer-than-80-column lines would be the following.  These arguments apply specifically to header files -
(i) It's easier to parse a header file with one method per line.  Longer lines make this more likely.
(ii) It's preferable to have inline method definitions with the declaration, for short methods.  Longer lines again make this more likely.
(iii) The structure of the code throws up other cases where one method per line makes for readability e.g. overloaded methods benefit from being on consecutive lines so that the first part of the text corresponds directly and only the signatures differ.
The most powerful argument in favor of 80-column text is just that 'everyone does it', or that you cannot anticipate that somebody-somewhere might have a device that needs 80-column text.  But these seem more like arguments by inertia and surely readability is more important.  So I wondered what the general opinion of boost developers is on this issue,
Thanks,
Paul Beardsley.
 Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more

[boost] Re: Formal Review for Boost I/O Library

[Gennaro Prota]

On Wed, 26 Feb 2003 23:00:11 -0600, "Ed Brey" <[EMAIL PROTECTED]>
wrote:

>The formal review for the updated Boost I/O Library begins today and runs through 
>March 7.

Just some quick comments:

>The I/O library contains various components for use with the standard I/O library.  
>The components are as follows:
>  State-saving classes for various IOStream attributes.

These are already into boost, aren't they? Are you asking for a
further review? Or weren't they reviewed when they should have been?

>  Class templates to ease making streams off a new stream-buffer class.
>  Stream and stream-buffer class (templates) that use an internal array.

 
>  Additional I/O manipulator function (templates).


This part looks quite extemporaneous and incomplete. For instance, why
aren't there


  template 
  std::basic_ostream&
  htab (std::basic_ostream& os) {
  return os.put(os.widen('\t'));
  }

  template 
  std::basic_ostream&
  bel (std::basic_ostream& os) {
  return os.put(os.widen('\a'));
  }

  ... etc...

too?



As to the two manipulators provided:

- Though 'newl' and 'skipl' imitate the pattern of 'endl' I think it
would be better choosing more descriptive names, like new_line and
skip_until_newline. But, of course, these are religion issues :-)

- The implementation of skipl is erroneous as per lib issue 172; it
should be


template < typename Ch, class Tr >
std::basic_istream &
skip_until_new_line(std::basic_istream &  is)
{
return is.ignore( std::numeric_limits< std::streamsize > :: max(),
 Tr::to_int_type(is.widen( '\n' )) );
}


- The test program for iomanip.hpp could be improved, I think. Better
showing that skipl can skip any character before the newline, for
instance with something like:


// untested test program
//

char hello[] = "hello";

std::stringstream  ss;
ss << hello << "AxxA" << newl << "There";


std::string  s;
ss.seekg( 0 );
ss >> std::setw(sizeof hello) >> hello;

char c;
ss >> c;
BOOST_TEST(c == 'A');

ss >> skip_until_new_line >> s;
BOOST_TEST( s == "There" );


- in iomanip.hpp the function template declarations immediately before
the definitions just confuse the code IMO.


- as a general rule, I don't like having source file names too similar
to standard header-names (example: iomanip.hpp). BTW it tends to be
annoying to remember slight differences like  vs. "io_fwd.hpp"
and/or remembering whether the latter is iofwd or io_fwd.


>The stream buffer classes are new and deserve primary attention in this review.

Yes. Let me start from the documentation, which is IMHO absolutely
insufficient, especially in the rationale section. Informally speaking
(up to Daryle to improve the wording from a technical perspective) I
think the real rationale goes more-or-less along these lines:

When deriving from the standard basic_istream, basic_ostream,
basic_iostream classes, *you* should provide a pointer to a suitable
stream buffer (this is not the case, for instance, when deriving from
ifstream and ofstream because those classes already contain their
stream buffer). There are several ways to do this:

a) construct a stream buffer independently and associate it with a
stream object later


b) gather the buffer from another stream; this leads to a buffer
"shared" among several stream objects. Example:


template  >
class my_stream : public std::basic_ostream 
{
public:

my_stream(std::basic_ostream & os):
  std::basic_ostream(os.rdbuf())
{

 
}

};


my_stream m (std::cout);
m << "hi!\n";


Now m and std::cout share the same buffer. Sharing a stream buffer can
be useful in various situations where you want, for instance,
different format settings, or different locales, for the same stream:
in such scenarios instead of continuously switching the format
settings or the locale you use different streams which write to (or
read from) the same stream buffer


c) put a stream buffer into the derived stream; the stream buffer can
be a base sub-object or a data member. This is the typical approach
when a new buffer type is used, and _is what the following classes
help implementing_.


I've omitted, for laziness, an (obvious) example for case a).

Ok, now to the code. Sad to say, but this is the typical case where it
takes more time to understand what the existing "solution" is meant to
do than to write your own code from scratch. BTW, the fact that the
templates are identical except for the presence of 'istream',
'ostream' or 'iostream' in some places is highly suspicious. That
consideration apart, let us compare your code with what I would write
from scratch if I had to define my own stream:



struct buffer_wrapper {
std::stringbuf buffer;
};


template  >
class my_stream :
 virtual buffer_wrapper,
 public std::ostream {

public:
 my_stream() : std::ostream(&buffer) {}

 
};


Now convince me that the approach taken by this library is better than
the (immediat

Re: [boost] New release procedure?

[Beman Dawes]

At 11:35 AM 3/5/2003, David Abrahams wrote:

>>> The multiple merge thing is probably much less of an issue when
>>> working from trunk to branch, but it still could be useful to have
>>> the tag.  I would call the tag "merged_to_".
>>
>> So this is something each developer would do when merging to
>> the branch from MAIN if they want 'extra' information
>> in CVS about where the merge took place?  If this is
>> correct, I'm generally opposed to this extra step as
>> I don't see what it is going to buy you above and beyond
>> what you can get in CVS log command.  Am I missing
>> something?
>
>If you make a big change on the trunk and need to merge to the
>branch, and then you do it again, you want
>
> cvs merge -jmerged_to_RC_whatever -jHEAD
>
>In order to make the merge work properly.  If the release manager
>doesn't tag the head at the merge point, the first person to merge
>from trunk to branch messes up that arrangement.
OK, I've added the tag "merged_to_RC_1_30_0" to the CVS at the appropriate 
point in time.

It took a couple of hours experimenting with the sandbox to figure out how 
to do this correctly. WinCVS (and presumably cvs itself) seems to report 
time as UTC, but expects input times to be local.

The tagging itself took over an hour even though SourceForge CVS seemed to 
running very quickly this morning on other operations.

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] CVS repository locked?

[Vladimir Prus]

I see this, when doing update:

cvs server: [07:46:57] waiting for beman_dawes's lock in 
/cvsroot/boost/boost/tools/build
.
cvs server: [08:02:58] waiting for beman_dawes's lock in 
/cvsroot/boost/boost/tools/build

Beman, is there anything you can do about it? Like killing client or updating again? 
Or 
ony sourceforge admins are in position to fix this?

- Volodya

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: bug in random_number_generator ?

[David Pearce]

Hey,

As far as I can understand you are asking for a ranomized integer value
in the range [0,n) (i.e. n exclusive). If randomizing bits is what you
want, then the correct call is rgen(2), not rgen(1) (which basically
mean asking for an integer between 0 and 0 which doesn't exist so the
failure is expected). This may look counterintuitive to you, but you can
easily implement your own version which does not subtract 1 from n if
wanted.
"Function call f(N) N is positive. Returns a pseudo-random number of 
type Integer. [2] The return value is less than N, and greater than or 
equal to 0."

--Taken from the SGI STL webpage regarding the Random Number Generator 
concept.

Therefore, zero should be a valid result from rgen(1) as it is within 
the range [0,1). I accept there would be no valid result for rgen(0).

Furthermore, the SGI implementation of random_sample_n, which I admit is
an SGI extension, expects that rgen(1) will return 0.
Cheers,

Dave


> random_number_generator rgen(...);
> cout << rgen(1) << endl; // causes assertion failure
I encountered this problem when using random_number_generator in 
conjuction with the random_sample_n algorithm.
I have attached a simple patch which catches the case when the parameter 
is 1. If anyone can tell me whether this is a reasonable fix, I would be 
grateful.

The patch fixes a case which is wrong in the first place, so my answer
would be no :)


   result_type operator()(argument_type n) {
! if(n == 1) { 
!   return 0;
! } else {
!   return uniform_int(_rng, 0, n-1)();
! }
   }
 
Not that it matters, but the 'else' here is useless. Try avoiding
unnecessary else clauses.
Regards,
--
Tarjei
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Re: is_convertible love

[Rani Sharoni]

Shame on me! I did saw 13.3.3.1/6 before posting my answer:
[...] When the parameter has a class type and the argument expression has
the same type, the implicit conversion sequence is an identity conversion.
[...]

It seems that overloading takes place before initialization. Initialization
requires additional overloading to select the best viable constructor. In
case that the first overloading required user defined conversion then only
standard conversions are allowed in the second overloading (core issue 84).
My solution relays on the second (initialization) overloading which makes it
(and VC) wrong.

I'll be very surprise if someone will solve your challenge.

Sorry for wasting your time,
Rani

David Abrahams wrote:
> Rani,
>
> Here's what Steve Adamczyk (Mr. overload resolution) at EDG had to say
> about it:
>
> I tracked down why we do what we do.  It comes down to 13.3.3.1.2/4:
>
> 4 A conversion of an expression of class type to the same class type
>   is given  Exact  Match  rank,  and a conversion of an expression of
>   class type to a base class of that type is given Conversion rank,
>   in  spite of  the  fact that a copy constructor (i.e., a
>   user-defined conversion function) is called for those cases.
>
> Now, the idea of using the auto_ptr kind of trick (copying by
> way of an auxiliary class) was not thought of when this paragraph
> was done, but the point was that for purposes of overload
> resolution copying X to X is always an exact match even if
> something is called to do the copy.
>
> Now, we could do a core issue to find out what this paragraph means
> for the auto_ptr kind of case.  I have to say, though, that
> it would be an expensive thing to have to check everywhere that a
> copy that looks like an exact match is done, and there's nothing
> that says that calling a conversion function and copy constructor
> is less efficient than calling a copy constructor, so I'd be
> inclined to say that it should just be clarified to say that
> such a copy is considered an exact match regardless of the
> actual mechanism used to perform the copy.
>
> Steve
>
> - Rani wrote this 
>
> Interesting challenge (at least for me).
> In first glance it seems to be impossible which made it even more
> interesting.
>
> typedef char (&yes)[1];
> typedef char (&no) [2];
>
> //
> // TODO: handle types that can't be members
> // (e.g. void, abstract, functions)
> //
> template
> struct has_regular_ctor
> {
> private:
> struct ctor_tester
> {
> T   t;
> struct B {};
> operator B() const;
> ctor_tester(B);
> private:
> // VC warnings
> ctor_tester& operator=(ctor_tester const&);
> };
>
> static yes check(ctor_tester, int);
> template
> static no  check(ctor_tester const&, U);
>
> static ctor_tester const& get();
>
> public:
> static const bool value =
> sizeof(check(get(), 0)) == sizeof(yes);
> };
>
> struct A1 { A1(A1&); };
> struct A2 { A2(A2 const&); };
>
> typedef char test[!has_regular_ctor::value];
> typedef char test[!has_regular_ctor::value];
> typedef char test[ has_regular_ctor::value];
> typedef char test[ has_regular_ctor::value];
> typedef char test[ has_regular_ctor::value];
>
> The above code compiled fine with VC7.1 beta but failed to compile
> using EDG and GCC.
> Here is an explanation for why I think that it's compliant:
>
> The form of the ctor of ctor_tester is the same as its member t
> (12.8/5). In case the ctor argument has const qualifier then both
> check functions has an exact match (13.3.3.1.1/3), the first check
> using Lvalue-transformation and the second using identity. The
> ambiguity buster in this case is the non-template function.
> In case that the ctor is not const then the first version is viable
> using user defined conversion sequence (like auto_ptr: ctor_tester ->
> B) and the second is still identity.
>
> Overloading is so complex that I have doubts and I'll be happy to ear
> a second opinion.
>
> Rani



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] [config] BOOST_DEDUCED_TYPENAME

[David Abrahams]

Daniel Frey <[EMAIL PROTECTED]> writes:

> Agreed. I didn't know about the other MACROs. I just found the one (or
> two?) occasions where BOOST_DEDUCED_TYPENAME was used. Generally I think
> it's better to have things as local as possible, but if the above
> workaround is needed often, it might make sense to keep the macro and if
> I understand you correctly, the new macro will replace all of the above
> macros, right?

That would be the idea.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] [config] BOOST_DEDUCED_TYPENAME

[Daniel Frey]

David Abrahams wrote:
> 
> Daniel Frey <[EMAIL PROTECTED]> writes:
> 
> > I greped for it and it seems it is not used very often. How about using
> > BOOST_WORKAROUND to keep the code local and thus not hide the actual
> > workaround in a MACRO and spread to knowledge? Especially given it's
> > only a workaround for a single compiler. Or do you think it is
> > comparable to BOOST_STATIC_CONSTANT
> 
> I do.

The difference I see is, that BOOST_STATIC_CONSTANT switches between two
legal alternatives, while BOOST_DEDUCED_TYPENAME only hides
non-conforming code (IIUC) which is required for some compilers.

> > and will be used a lot in the future
> 
> Maybe not a lot, but often enough.  I'm sure we have quite a few
> synonyms for it in various headers.  Did you search for just
> "TYPENAME"?

No, I greped for BOOST_DEDUCED_TYPENAME

> I find
> 
>   BOOST_ARG_DEPENDENT_TYPENAME
>   BOOST_MSVC_TYPENAME
>   BOOST_DEDUCED_TYPENAME
>   BOOST_UBLAS_TYPENAME
>   BOOST_SPIRIT_TYPENAME... etc.
> 
> OK, I'm tired of typing these now.
> 
> It really uglifies code to have to add the workaround every place you
> need it.

Agreed. I didn't know about the other MACROs. I just found the one (or
two?) occasions where BOOST_DEDUCED_TYPENAME was used. Generally I think
it's better to have things as local as possible, but if the above
workaround is needed often, it might make sense to keep the macro and if
I understand you correctly, the new macro will replace all of the above
macros, right?

Regards, Daniel

-- 
Daniel Frey

aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Eric Ford's Unit package

[David Abrahams]

"Paul A. Bristow" <[EMAIL PROTECTED]> writes:

> This promises to meet a massive need,
>
> but for me must wait until I get MSVC 7.1
> which I understand includes partial specialisation.
> (How did MS ever think it wasn't absolutely essential?)
>
> Meanwhile, perhaps others can evaluate this?

I don't see why partial specialization should be required for this
application.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] [config] BOOST_DEDUCED_TYPENAME

[David Abrahams]

Daniel Frey <[EMAIL PROTECTED]> writes:

> I greped for it and it seems it is not used very often. How about using
> BOOST_WORKAROUND to keep the code local and thus not hide the actual
> workaround in a MACRO and spread to knowledge? Especially given it's
> only a workaround for a single compiler. Or do you think it is
> comparable to BOOST_STATIC_CONSTANT 

I do.

> and will be used a lot in the future

Maybe not a lot, but often enough.  I'm sure we have quite a few
synonyms for it in various headers.  Did you search for just
"TYPENAME"?

I find 

  BOOST_ARG_DEPENDENT_TYPENAME
  BOOST_MSVC_TYPENAME
  BOOST_DEDUCED_TYPENAME
  BOOST_UBLAS_TYPENAME
  BOOST_SPIRIT_TYPENAME... etc.

OK, I'm tired of typing these now.

It really uglifies code to have to add the workaround every place you
need it.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] HTML documentation imported into 1.30.0

[Beman Dawes]

At 04:39 PM 3/5/2003, Rozental, Gennadiy wrote:

>> There are still a lot of people who use dial-up lines and
>> have no viable
>> alternative. We need to limit the Boost distribution to core
>> files and put
>> the other stuff elsewhere.
>>
>> --Beman
>
>I believe that sooner or later we will be forced to prepare per-library
>download. It's quite a work, but should be doable based on lib dependency
>graph.
I agree with you, but because of the amount of work involved would like to 
put that project off for a while longer.

>We may prepare also a core module with most widely used components (for
>example the one that referred to more that N times). It should minimize
>number of different modules. So To install library L one need ot download 
L
>specific module plus core one.

Yes, I had the same thought.

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] solaris, once again

[Marc Borgers]

I am having problems with the shared_ptr on Forte 6.2: when I compile my
code into an application, it all seems to work. When I am compiling a
static library, I had to
compile it with the -misalign option. If I don't do this I get a
misalignment  error in a destructor of
the shared_ptr. I do not know whether it was the intentin to use that
switch. Should I do something
else ?





"Mark Rodgers" <[EMAIL PROTECTED]>@lists.boost.org on 06/03/2003
07:33:18

Please respond to Boost mailing list <[EMAIL PROTECTED]>

Sent by:  [EMAIL PROTECTED]


To:   <[EMAIL PROTECTED]>
cc:

Subject:  Re: [boost] solaris, once again


- Original Message -
From: "Garnet Kin-Lic Chan" <[EMAIL PROTECTED]>
> there have been a few discussions recently about the status of
> solaris and boost. as someone whose code relies on the boost::function
and
> boost::bind libraries, and who needs to port to solaris in the very near
> future, i'm happy to try and help. does anyone know what is needed, and
> has anyone had any experience with version 7 of the sun compilers? anyone
> else interested?

code now that uses bind and function extensively and having reasonable
success with Forte 6.2 (C++ 5.3).  I've had to change a few things and will
post a list when I've finished.  If you're using this version of the
compiler two things spring to mind:

1. Define BOOST_NO_INCLASS_MEMBER_INITIALIZATION fixed it.  In general,
this
compiler
does support in class member initialisation, but for some reason, the code
in type traits causes a compiler assertion.

2. Get the latest patch.  This fixes some of the problems you'll find with
segmentation faults, notably with function (so for example compiling
boost.thread used to fail but now works for me).

Mark

___
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] [config] BOOST_DEDUCED_TYPENAME

[Daniel Frey]

Aleksey Gurtovoy wrote:
> 
> David Abrahams wrote:
> > Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
> >
> > > If BOOST_DEDUCED_TYPENAME was introduced for the sake of MSVC only
> > > (which seems very likely to be the case)
> >
> > It was.

[...]

> > Well, I think you're right, but the question remains: what should we
> > do about it?  Should we just replace BOOST_DEDUCED_TYPENAME?
> 
> That's what I would do.

I greped for it and it seems it is not used very often. How about using
BOOST_WORKAROUND to keep the code local and thus not hide the actual
workaround in a MACRO and spread to knowledge? Especially given it's
only a workaround for a single compiler. Or do you think it is
comparable to BOOST_STATIC_CONSTANT and will be used a lot in the future
and doesn't fall into the category of problems BOOST_WORKAROUND is
supposed to solve?

Regards, Daniel

-- 
Daniel Frey

aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Eric Ford's Unit package

[Paul A. Bristow]

This promises to meet a massive need,

but for me must wait until I get MSVC 7.1
which I understand includes partial specialisation.
(How did MS ever think it wasn't absolutely essential?)

Meanwhile, perhaps others can evaluate this?

Paul

Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB  UK
+44 1539 561830   Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]



> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Eric Ford
> Sent: Thursday, March 06, 2003 12:34 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [boost] Eric Ford's Unit package
> 
> 
> > This looks most interesting, and there most definitely remains a 
> > great need for 
> > a units handling package. 
> >
> > I presume you have looked at W W Brown's SI units proposal 
> > http://home.fnal.gov/~wb/SItempl8.pdf 
> > and wonder why you rejected it and how your proposal is different. 
> 
> 
> Yes, I had seen his old code, but not this proposal.  (I have not seen
> a version of his code which implements his proposal.  Please let me
> know if you can point to one.)  I share many of his goals, and
> certainly benefitted from reviewing his code.  I'll outline some of
> the differences below.

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] [config] BOOST_DEDUCED_TYPENAME

[Aleksey Gurtovoy]

David Abrahams wrote:
> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
> 
> > If BOOST_DEDUCED_TYPENAME was introduced for the sake of MSVC only
> > (which seems very likely to be the case)
> 
> It was.
> 
> > , then it was given a wrong name, since there are lots of other 
> > situations, besides the "deduced typename" context, when the 
> > compiler refuses to accept 'typename', incorrectly - in particular,
> > the one demonstrated by the above test case. Classifying those 
> > situations and introducing a separate macro for each and every of 
> > them just isn't worth the troubles, in particular because MSVC is 
> > the only compiler with such peculiarity with respect to 'typename'
> > in different contexts; IMO what is needed in place of such 
> > artificial classification is a single macro that explicitly 
> > documents that what is being worked around here is a weird
> > behavior of one particular compiler, e.g. BOOST_MSVC_TYPENAME or 
> > something like it.
>
> Well, I think you're right, but the question remains: what should we
> do about it?  Should we just replace BOOST_DEDUCED_TYPENAME?

That's what I would do. John?

Aleksey

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Proposal: static_string library

[Phil Nash]

> Robert Klarer wrote:
> > The syntax for declaring a static_string is unfortunate, but once it has
> > been declared, a static_string's interface is (almost*) the same as that
> > of a const std::string.
> Yes, you right it's unfortunate and IMHO is not appropriate for a wide
use.
>
> >typedef boost::static_string<'s', 't', 'a', 't', 'i', 'c', '_'>
> > StrType1;
>
> This syntax may be good for some specific (and not widely used) tasks such
> as building hashing algorithm at compile-time for a given set of static
> strings but not for "normal" strings.
> I beveive it's better to wait for a new compiler which can optimize
dynamic
> memory allocations (a possibly even more) away.

Hmm, but on the other hand, perhaps this is an area that a simple code
generator might be practical. If you keep all your string literals
(especially localisable strings) in separate files already these string
files could be generated to use static_string - and so the syntax would not
have to be manipulated. In fact if the code generator took a C++ file of
string literal declarations as source and worked both ways swapping them in
and out maybe quite trivial.
I know code generators are not universally popular and I always template
meta-programming where possible, even if a little more complex, but this
could be a useful case for those that choose it?

I have to admit I like the idea of having a std::string interface without
the overhead of dynamic allocation.
My biggest reservation would by the char-only restriction...

Regards,

[)o
IhIL..

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Proposal: static_string library

[Alexander Nasonov]

Robert Klarer wrote:
> The syntax for declaring a static_string is unfortunate, but once it has
> been declared, a static_string's interface is (almost*) the same as that
> of a const std::string.
Yes, you right it's unfortunate and IMHO is not appropriate for a wide use.

>typedef boost::static_string<'s', 't', 'a', 't', 'i', 'c', '_'>
> StrType1;

This syntax may be good for some specific (and not widely used) tasks such 
as building hashing algorithm at compile-time for a given set of static 
strings but not for "normal" strings.
I beveive it's better to wait for a new compiler which can optimize dynamic 
memory allocations (a possibly even more) away.

-- 
Alexander Nasonov
Remove minus and all between minus and at from my e-mail for timely response

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost