> 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 Hen
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_co
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/t
>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;
> >
> > te
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
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_strin
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 g
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
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.p
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',
--- 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 mad
>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
>
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 tha
>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 i
>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 o
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
>
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.
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
CodeWar
"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 o
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 runni
>
> > 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 w
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
"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 dif
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 t
> > 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 pa
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 yo
--- 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 imprac
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 thi
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 su
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. I
"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
__
--- 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_he
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:\
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 C
(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 Be
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
(
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 a
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
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
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
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
require
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 mak
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
> > onl
"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 do
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.
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 f
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 k
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 re
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 8A
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 th
> 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.
>
> >typede
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::stati
52 matches
Mail list logo
