headers
David Abrahams | 1 Apr 2002 01:09
Favicon
Gravatar

Re: Need volunteer to supply Boost NNTP/newsgroup server

Dietmar,

The main thing preventing us from making this transition simply and
painlessly is lack of expertise. If we can raise the neccessary
computing resources, would you be willing to set up the system?

-Dave

----- Original Message -----
From: "Dietmar Kuehl" <dietmar_kuehl <at> yahoo.com>

> False in all accounts! Nothing requires the "moderator" of a newsgroup
> to be a human person. Almost certainly, there will  be an
administrator
> who is responsible for having things work smoothly but this is already
> the case anyway (however, with the creation of a newsgroup I can
imagine
> that a new administrator would be added to deal with the newsgroup
> related stuff).
>
> Concering posting delays, this is not required at all: Submissions to
> newsgroups can be handled by a script which eg. checks that the "From"
> header indicates a registered person and if this is the case just
sends
> the article forward. In de.comp.lang.iso-c++ we use a variation on
this
> scheme adding a little bit more control: Unknown poster's articles are
> sent to a moderator for manual processing (in this case indeed adding
a
> moderation delay) as are article containing specific keywords (like
(Continue reading)

Permalink | Reply | 8 comments |
headers
Bill Seymour | 1 Apr 2002 13:48
Picon
Favicon

Re: MSVC operator>> for __int64

Jeff wrote:
>
> I have a porting problem in GDTL with operator>> missing for
> __int64 on MSVC6.SP5.  However, another booster has successfully
> compiled this.  Anyone know if this is part of an SDK upgrade
> or something else?
>

I once wrote >> and << operators for Microsoft's __int64.
IIRC, there were some things I didn't get quite right (e.g.,
ios_base::internal); but it works for both char and wchar_t.

Would it be OK to upload the source to the Boost file section?
(It might help library authors who need a 64-bit integer type
and I/O, and want to be portable to MSVC.)

If not, Jeff, send me your e-mail address (my company's e-mail
system won't show me); and I'll mail you a copy of the source.

--Bill Seymour
Permalink | Reply | 1 comment |
headers
Jeff Garland | 1 Apr 2002 14:22

RE: MSVC operator>> for __int64

Bill -

Thanks -- I'd like to take a look at your source.  Either uploaded or emailed.
Ultimately it would be nice to figure out if there is a way to detect that this
is missing and patch it -- or if someone knows what 'upgrade' from MS fixes it,
point users to that...

Jeff

> -----Original Message-----
> From: boost-admin <at> lists.boost.org [mailto:boost-admin <at> lists.boost.org]On
> Behalf Of Bill Seymour
> Sent: Monday, April 01, 2002 4:48 AM
> To: boost <at> lists.boost.org
> Subject: Re: [boost] MSVC operator>> for __int64
>
>
> Jeff wrote:
> >
> > I have a porting problem in GDTL with operator>> missing for
> > __int64 on MSVC6.SP5.  However, another booster has successfully
> > compiled this.  Anyone know if this is part of an SDK upgrade
> > or something else?
> >
>
> I once wrote >> and << operators for Microsoft's __int64.
> IIRC, there were some things I didn't get quite right (e.g.,
> ios_base::internal); but it works for both char and wchar_t.
>
> Would it be OK to upload the source to the Boost file section?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raoul Gough | 1 Apr 2002 15:08
Picon
Favicon

boost::weak_ptr suggestions

I have some suggestions about the existing boost::weak_ptr (I hope this is
the right forum to post these issues).

Firstly, operator= and the copy constructor can currently make use of an
invalid pointer value. This kind of thing has been discussed on
comp.lang.c++.moderated, and I think the consensus was that reading an
invalid pointer value is *undefined behaviour* even in the absence of
dereferencing. Consider the following case:

shared_ptr<X> sp1 (new X);
weak_ptr<X> wp1 (sp1);

sp1.reset (); // Invalidate wp1.px
weak_ptr<X> wp2 (wp1) // Copies invalid pointer value
wp2 = wp1; // Copies invalid pointer value

The problem is that the raw pointer value (the px member variable) becomes
invalid once its target object is deleted (see section 3.7.3.2 para 4). To
be safely portable, it would be better for operator= and the copy
constructor to use the other object's get() member function to ensure that
the px value is only read if known to be valid. IIRC, the real-world
argument against even looking at an invalid pointer value was that some
architectures may use registers which perform address validation or even
cause pre-fetching of memory pages.

Secondly, I believe it would be better for the get() method to throw or
assert when called on an invalidated pointer, instead of transparently
returning 0. In my opinion, there is a fundamental difference between the
two states (null and invalid) which is not observable with the current
interface. The addition of a member function like "bool is_valid() const;"
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Dimov | 1 Apr 2002 15:58

Re: boost::bind() and Comeau

From: "Giovanni Bajo" <giovannibajo <at> libero.it>
> From: "Peter Dimov" <pdimov <at> mmltd.net>
> > The fact that you are hitting the void return workaround code path means
> > that you are using Comeau in MSVC 6 compatibility mode; either
> > BOOST_NESTED_TEMPLATE is not defined to 'template', or there is a bug in
> > Comeau.
>
> I've checked and BOOST_NESTED_TEMPLATE is correctly defined as 'template'.
> It looks like a compiler bug then.
> Undefining BOOST_NO_VOID_RETURNS worked well for me in strict mode, while
it
> fails when compiling in Microsoft compatibility mode. The #if test in
> comeau.hpp only checks if Comeau is using MSVC6 as a backend, but it does
> not check if it is working in strict mode or not. It would not be a
problem
> of course if the void return workaround compiled correctly.

I don't have access to Comeau C++ so I can't test how it behaves in its
various modes. I assumed that when _MSC_VER is defined, then the compiler is
in MSVC compatibility mode. Are you saying that in strict mode _MSC_VER is
still defined, but the void returns work? If so, can you post a patch to
boost/config/compiler/comeau.hpp?

Also, did you try to run Comeau in MSVC 7 mode? I'm fairly certain that void
returns work. The option was --microsoft-ver=1300 IIRC but I may be wrong.

(The void returns path is problematic in general. It works on MSVC 6 and on
EDG 2.38 (?) but few other compilers can cope.)
(Continue reading)

Permalink | Reply | 11 comments |
headers
Peter Dimov | 1 Apr 2002 16:31

Re: boost::weak_ptr suggestions

From: "Raoul Gough" <RaoulGough <at> yahoo.co.uk>
> I have some suggestions about the existing boost::weak_ptr (I hope this is
> the right forum to post these issues).

It is. :-)

> Firstly, operator= and the copy constructor can currently make use of an
> invalid pointer value. This kind of thing has been discussed on
> comp.lang.c++.moderated, and I think the consensus was that reading an
> invalid pointer value is *undefined behaviour* even in the absence of
> dereferencing. Consider the following case:
>
> shared_ptr<X> sp1 (new X);
> weak_ptr<X> wp1 (sp1);
>
> sp1.reset (); // Invalidate wp1.px
> weak_ptr<X> wp2 (wp1) // Copies invalid pointer value
> wp2 = wp1; // Copies invalid pointer value
>
> The problem is that the raw pointer value (the px member variable) becomes
> invalid once its target object is deleted (see section 3.7.3.2 para 4). To
> be safely portable, it would be better for operator= and the copy
> constructor to use the other object's get() member function to ensure that
> the px value is only read if known to be valid. IIRC, the real-world
> argument against even looking at an invalid pointer value was that some
> architectures may use registers which perform address validation or even
> cause pre-fetching of memory pages.

You are right. I am aware of the potential problem; the current
implementation seems to work in practice, so I decided to leave it as is.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stewart, Robert | 1 Apr 2002 17:50
Favicon

RE: filesystem/directory.hpp header redux

From: Dylan Nicholson [mailto:dylan_nicholson <at> yahoo.com.au]
> 
>  --- "Stewart, Robert" <stewart <at> sig.com> wrote: 
> > From: Dylan Nicholson [mailto:dylan_nicholson <at> yahoo.com.au]
> > 
> > In your own explanation, you show how two different OSes do 
> it differently.
> > Other OSes probably have other rules.  Some may offer no 
> such pattern
> > matching rules.  On Unix, the globbing is controlled by the 
> shell, so there
> > is no standard other than the de facto standard created by 
> the Bourne Shell
> > 
> Not true, it is part of the POSIX standard.  glob()/fnmatch() 
> also follows the
> same rules.

OK, I'm not well versed on POSIX, so I'll defer on that point.  However, it
doesn't change my basic premise which is that other OSes do it differently.
Again, your own example showed that Windows works differently than POSIX.

> As long as predicate methods are provided, it would be easy 
> enough to write a
> predicate that worked based on fnmatch().

Agreed.

> I also think that reg. exp. matching should be done through a 
> predicate, if
(Continue reading)

Permalink | Reply | 7 comments |
headers
Stewart, Robert | 1 Apr 2002 17:54
Favicon

RE: filesystem/directory.hpp header redux

From: Ross Smith [mailto:r-smith <at> ihug.co.nz]
> 
> "Stewart, Robert" wrote:
> > 
> > From: Ross Smith [mailto:r-smith <at> ihug.co.nz]
> > >
> > > If is_readonly() doesn't actually tell you whether the file is
> > > read-only, what possible use could it be?
> > 
> > The purpose of this library is to enable scripting.  
> Therefore, one must
> > ask, "What does a script do to test for write-ability?"  
> Answer: "test -w
> > pathname" or its equivalent in the various shells.  Who's 
> got access to
> > implementations of test or shells that do it themselves?  
> What does "test
> > -w" -- or whatever syntax your favorite shell uses -- do?  (ksh, for
> > example, provides syntactic sugar for test, but ultimately 
> calls test.  I'm
> > guessing that there are shells that do the test themselves 
> rather than
> > running test.)
> 
> What on earth does any of that have to do with it?

I thought it was obvious.  If "test -w" is good enough for Unix shell
scripting, then whatever it does should be good enough for a filesystem
scripting library implemented in C++.  If that means that the "test -w" is
not foolproof or complete, then so be it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Powell, Gary | 1 Apr 2002 18:10
Picon
Favicon

RE: Function + Lambda badness fixed

Lambda and Function play nicely now, so there is no need to unlambda()
everything before using it with Function. No changes to lambda are
required, but minor changes to Function have been checked into CVS.

	Doug
------------------------------------------------------
Thanks!
   -Gary-
Permalink | Reply | 0 comments |
headers
Beman Dawes | 1 Apr 2002 17:47
Picon
Favicon
Gravatar

Re: Need volunteer to supply Boost NNTP/newsgroup server

At 06:09 PM 3/31/2002, David Abrahams wrote:

 >Dietmar,
 >
 >The main thing preventing us from making this transition simply and
 >painlessly is lack of expertise. If we can raise the neccessary
 >computing resources, would you be willing to set up the system?

Dave's right.  Normally we could do some private experimentation, learning 
as we go, and then go public when a service is working properly.

But where Boost doesn't have our own server or Internet connection, we 
can't do that.  It is very frustrating.

--Beman
Permalink | Reply | 7 comments |

Gmane