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
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
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
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
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
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
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
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
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
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
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
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
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_branch name.
So this is something each developer would do when merging to
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
(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
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
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 *
]
--- 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 typename B, typename D, typename T
static
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
___
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
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_branch name.
So this is
--- 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
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
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
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,
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
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
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
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.
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
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
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
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
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
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',
Andrei Alexandrescu wrote:
By the way, any chance to tweak the acknowledgments a bit. They mention
GenericProgramming: Discriminated Unions Part 1, Part 2, Part 3. C/C++
Users Journal. 2002, but the text doesn't mention the earlier
publication,
which is
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
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
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:
templateclass CharType, int N
class fixed_size_string;
templateclass CharType, int N1, int N2
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
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:
templateclass CharType, int N
class fixed_size_string;
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
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 *
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,
44 matches
Mail list logo
