|
|
Boost : |
From: Kevin Lynch (krlynch_at_[hidden])
Date: 2001-06-25 11:39:58
boost_at_[hidden] wrote:
>
> Info: http://www.boost.org Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]>
> ------------------------------------------------------------------------
>
> There are 20 messages in this issue.
>
> Topics in this digest:
>
> 1. Question about leading underscores
> From: rwgk_at_[hidden]
> 2. Re: MSVC, STLport, and allocators
> From: "David Abrahams" <david.abrahams_at_[hidden]>
> 3. Re: A Physical Quantity library for boost?
> From: John Max Skaller <skaller_at_[hidden]>
> 4. Re: Question about leading underscores
> From: "Greg Colvin" <gcolvin_at_[hidden]>
> 5. Re: int64_t/boost/gcc 2.95.3
> From: John Max Skaller <skaller_at_[hidden]>
> 6. Re: Question about leading underscores
> From: Beman Dawes <bdawes_at_[hidden]>
> 7. Re: Question about leading underscores
> From: "Greg Colvin" <gcolvin_at_[hidden]>
> 8. Re: Question about leading underscores
> From: "Corwin Joy" <cjoy_at_[hidden]>
> 9. Re: Re: Boost.Threads - name of the "thread" type
> From: John Max Skaller <skaller_at_[hidden]>
> 10. RE: Question about leading underscores
> From: <jeff_at_[hidden]>
> 11. Re: Question about leading underscores
> From: "Corwin Joy" <cjoy_at_[hidden]>
> 12. Re: MSVC, STLport, and allocators
> From: Douglas Gregor <gregod_at_[hidden]>
> 13. Re: Not keen on Boost.Threads? [was: name of the "thread" type]
> From: Ross Smith <ross.s_at_[hidden]>
> 14. Re: Re: Boost.Threads - name of the "thread" type
> From: Beman Dawes <bdawes_at_[hidden]>
> 15. Re: Question about leading underscores
> From: Beman Dawes <bdawes_at_[hidden]>
> 16. Re: Re: Boost.Threads - name of the "thread" type
> From: "Greg Colvin" <gcolvin_at_[hidden]>
> 17. Re: Question about leading underscores
> From: "Corwin Joy" <cjoy_at_[hidden]>
> 18. Re: int64_t/boost/gcc 2.95.3
> From: Jens Maurer <Jens.Maurer_at_[hidden]>
> 19. Special functions, octonions, quaternions in the CVS
> From: Jens Maurer <Jens.Maurer_at_[hidden]>
> 20. Re: MSVC, STLport, and allocators
> From: Jens Maurer <Jens.Maurer_at_[hidden]>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 1
> Date: Fri, 22 Jun 2001 22:18:16 -0000
> From: rwgk_at_[hidden]
> Subject: Question about leading underscores
>
> In the header file boost/utility.hpp, leading underscores are
> are used for some variable names:
>
> template <class A, class B>
> class tied {
> public:
> inline tied(A& a, B& b) : _a(a), _b(b) { }
> /...
> protected:
> A& _a;
> B& _b;
> };
>
> I always thought that identifiers with leading underscores
> should not be used. Is this only true for identifieres
> in the global namespace?
>
> Thanks!
> Ralf
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 2
> Date: Fri, 22 Jun 2001 18:21:42 -0400
> From: "David Abrahams" <david.abrahams_at_[hidden]>
> Subject: Re: MSVC, STLport, and allocators
>
> Constructs like that one can be made to work with MSVC, although
> occasionally you have to break them up, e.g.:
>
> typedef Allocator::template rebind<T> rebind;
> typedef typename rebind::other t_allocator_type;
>
> -Dave
>
> ----- Original Message -----
> From: "Douglas Gregor" <gregod_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Friday, June 22, 2001 5:54 PM
> Subject: [boost] MSVC, STLport, and allocators
>
> > Hello all,
> > I've been analyzing a failure in Boost.Function with MSVC and STLport 4.0.
> > It appears that, even though STLport has a conforming allocator, MSVC
> won't
> > allow use of it. The 'rebind' member template, which is conspicuously
> absent
> > from the standard library that ships with MSVC, cannot be used so far as I
> > can tell. The standard usage (template parameters Allocator and T):
> >
> > typedef typename Allocator::template rebind<T>::other t_allocator_type;
> >
> > causes an internal compiler error. I was not able to find a real
> workaround.
> >
> > It seems that only regex rebinds allocators. The method used in regex is
> to
> > create a new class that derives from Allocator but handles the allocations
> > for the new type T. This requires Allocator to allocator chars so that the
> > derived allocator can work.
> >
> > So now come the questions. It would appear that MSVC6sp5 cannot support
> > standard allocators. Possible remedies are:
> > 1) Export the regex hack so that other libraries can use it.
> > 2) Define BOOST_NO_STD_ALLOCATOR for MSVC, always.
> > 3) Find another magic hack
> >
> > Help?
> >
> > Confusedly-yours,
> > Doug
> >
> > Info: http://www.boost.org Unsubscribe:
> <mailto:boost-unsubscribe_at_[hidden]>
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 3
> Date: Sat, 23 Jun 2001 08:38:52 +1000
> From: John Max Skaller <skaller_at_[hidden]>
> Subject: Re: A Physical Quantity library for boost?
>
> Msk_at_[hidden] wrote:
> >
> > Would there be any interest in a small domain library for
> > boost that handles dimensions (e.g. length, mass, power)
> > and units (e.g. meters, feet, furlongs) of physical
> > quantities?
>
> > I would appreciate feedback on three main questions:
> >
> > 1) Is this appropriate for boost?
>
> IMHO, yes.
>
> > 2) Has this already been done?
>
> Yes.
>
> > 3) Does anyone see any fatal flaws in the general approach,
>
> It looks good to me.
>
> Some operations seems to be missing.
> Suppose I write:
>
> pow(x,y)
>
> and x,y have units. What is the result?
> A more pragmatic example is Pythagoras:
>
> sqrt(x * x + y * y)
>
> Here, x is in metres, so the argument to sqrt is
> square metres, and the result should be in metres.
> More generally, root(n,x) yields division
> of the dimension by n (and an error if it isn't
> integral -- unless you want to support fractal dimensions :-).
> pow(x,n) yields multiplication of the unit by n.
> So log(n,x) also yields division. (Guess?)
>
> When it comes to trig functions ...
> I guess I'm saying: dimensional correctness is a problematic
> thing in physics, because all sorts of approximations
> and kludges and special functions are used. At some stage,
> you need to 'cast away' dimensions, do a pure computation,
> then add the dimensions back.
>
> sin ( undim(x) ) metres()
>
> It would be kind of nice to wrap this up in a single
> 'cast away/cast back' operation (but I can't see how).
> [A way to wrap existing 'pure' functions with dimensions?]
>
> Is there a cast away function?
>
> --
> John (Max) Skaller, mailto:skaller_at_[hidden]
> 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
> checkout Vyper http://Vyper.sourceforge.net
> download Interscript http://Interscript.sourceforge.net
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 4
> Date: Fri, 22 Jun 2001 16:40:28 -0600
> From: "Greg Colvin" <gcolvin_at_[hidden]>
> Subject: Re: Question about leading underscores
>
> From: <rwgk_at_[hidden]>
> > In the header file boost/utility.hpp, leading underscores are
> > are used for some variable names:
> >
> > template <class A, class B>
> > class tied {
> > public:
> > inline tied(A& a, B& b) : _a(a), _b(b) { }
> > /...
> > protected:
> > A& _a;
> > B& _b;
> > };
> >
> > I always thought that identifiers with leading underscores
> > should not be used. Is this only true for identifieres
> > in the global namespace?
>
> The safe rule is not to use leading underscores, although I
> think those above are technically OK, if useless.
>
> 17.4.3.1.2 Global names [lib.global.names]
>
> 1 Certain sets of names and function signatures are always reserved to
> the implementation:
>
> --Each name that contains a double underscore __) or begins with an
> underscore followed by an uppercase letter (_lex.key_) is reserved
> to the implementation for any use.
>
> --Each name that begins with an underscore is reserved to the imple-
> mentation for use as a name in the global namespace.22)
>
> _________________________
> 22) Such names are also reserved in namespace ::std (_lib.re-
> served.names_).
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 5
> Date: Sat, 23 Jun 2001 09:26:33 +1000
> From: John Max Skaller <skaller_at_[hidden]>
> Subject: Re: int64_t/boost/gcc 2.95.3
>
> Jens Maurer wrote:
> >
> > John Max Skaller wrote:
> > >
> > > 0. My system is linux/gcc 2.95.3.pentium:
> > >
> > > g++ -Wno-long-long -pedantic -ansi -shared -Iboost_1_22_0 ...
> >
> > What is your versioh of glibc?
> > (find out with "ldd --version")
>
> ldd (GNU libc) 2.1.2
>
> > > 6. /usr/include/stdint.h exists, and it defines (u)int64_t
> >
> > Note that the definition of (u)int64_t is not (primarily) a
> > feature of your compiler, but of your standard library. On
> > Linux, these are separate things.
>
> Right.
>
> > There is also a definition of (u)intXX_t in /usr/include/sys/types.h,
> > at least here on glibc 2.2.3. Unfortunately, for (u)int64_t, these
> > definitions are slightly different. In particular,
> > stdint.h says (note the absence of any dependency on __GNUC__):
> >
> > # if __WORDSIZE == 64
> > typedef long int int64_t;
> > # else
> > __extension__
> > typedef long long int int64_t;
> > # endif
> >
> > But (on one #ifdef branch) sys/types.h says:
> >
> > # ifdef __GNUC__
> > __extension__ typedef long long int int64_t;
> > # endif
>
> Yes, I've got that.
>
> > That means when using non-gcc compilers with these headers,
> > it depends on the order of #include's (sys/types.h first or
> > stdint.h first) whether int64_t is available or not. I
> > therefore decided not to depend on stdint.h.
>
> Fair enough.
>
> > The preprocessor conditions look for one of the <limits.h>
> > macros for "long long". Note that gcc defines these
> > only when special #defines are given. Try -D_GNU_SOURCE.
>
> Now it doesn't recognize long long constants :->
>
> ----------------------------------------------------
> [root_at_pelican] ~/links/flx>g++ -Wno-long-long -D_GNU_SOURCE -ansi
> -pedantic -Iboost_1_22_0 tmp.cpp
> In file included from tmp.cpp:1:
> boost_1_22_0/boost/cstdint.hpp:149: too many `l's in integer constant
> boost_1_22_0/boost/cstdint.hpp:160: #error defaults not correct; you
> must hand modify boost/cstdint.hpp
> --------------------------------------------------
>
> The test file tmp.cpp is:
> -------------------------------------
> #include <boost/cstdint.hpp>
> //#include <stdint.h>
> int main()
> {
> boost::int64_t i = 1;
> boost::uint64_t u = 1;
> return 0;
> }
> -----------------------------------------
>
> What I might do is this:
>
> #ifdef BOOST_NO_INT64_T
> namespace boost {
> typedef long long int64_t;
> typedef unsigned long long uint64_t;
> }
> #endif
>
> The problem is that it won't work if long long
> isn't defined. But it will fix the problem temporarily
> for the demo, which only works on Linux anyhow.
>
> --
> John (Max) Skaller, mailto:skaller_at_[hidden]
> 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
> checkout Vyper http://Vyper.sourceforge.net
> download Interscript http://Interscript.sourceforge.net
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 6
> Date: Fri, 22 Jun 2001 19:40:27 -0400
> From: Beman Dawes <bdawes_at_[hidden]>
> Subject: Re: Question about leading underscores
>
> At 06:40 PM 6/22/2001, Greg Colvin wrote:
>
> >The safe rule is not to use leading underscores, although I
> >think those above are technically OK, if useless.
>
> Why? Lots of programmers (me included) use a single leading underscore in
> private member names. It never causes any problems, and is completely
> standard conforming.
>
> That choice was based in an experiment some years ago trying several
> candidates (including none, trailing underscore, and some others I can't
> remember.) Leading underscore won.
>
> --Beman
>
> >17.4.3.1.2 Global names [lib.global.names]
> >
> >1 Certain sets of names and function signatures are always reserved to
> > the implementation:
> >
> > --Each name that contains a double underscore __) or begins with an
> > underscore followed by an uppercase letter (_lex.key_) is reserved
> > to the implementation for any use.
> >
> > --Each name that begins with an underscore is reserved to the imple-
> > mentation for use as a name in the global namespace.22)
> >
> > _________________________
> > 22) Such names are also reserved in namespace ::std (_lib.re-
> > served.names_).
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 7
> Date: Fri, 22 Jun 2001 17:54:43 -0600
> From: "Greg Colvin" <gcolvin_at_[hidden]>
> Subject: Re: Question about leading underscores
>
> From: Beman Dawes <bdawes_at_[hidden]>
> > At 06:40 PM 6/22/2001, Greg Colvin wrote:
> >
> > >The safe rule is not to use leading underscores, although I
> > >think those above are technically OK, if useless.
> >
> > Why? Lots of programmers (me included) use a single leading underscore in
> > private member names. It never causes any problems, and is completely
> > standard conforming.
>
> So long as you remember not to follow the underscore with
> a capital letter.
>
> Also, some shops use a leading underscore for unavoidable
> variables in statement macros that might interfere with
> other names. I know, don't use macros ...
>
> > That choice was based in an experiment some years ago trying several
> > candidates (including none, trailing underscore, and some others I can't
> > remember.) Leading underscore won.
>
> OK. I still dislike such warts. But I've quoted the
> standard so people can choose accordingly.
>
> > --Beman
> >
> > >17.4.3.1.2 Global names [lib.global.names]
> > >
> > >1 Certain sets of names and function signatures are always reserved to
> > > the implementation:
> > >
> > > --Each name that contains a double underscore __) or begins with an
> > > underscore followed by an uppercase letter (_lex.key_) is reserved
> > > to the implementation for any use.
> > >
> > > --Each name that begins with an underscore is reserved to the imple-
> > > mentation for use as a name in the global namespace.22)
> > >
> > > _________________________
> > > 22) Such names are also reserved in namespace ::std (_lib.re-
> > > served.names_).
> >
> >
> > Info: http://www.boost.org Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]>
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
> >
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 8
> Date: Fri, 22 Jun 2001 19:09:18 -0500
> From: "Corwin Joy" <cjoy_at_[hidden]>
> Subject: Re: Question about leading underscores
>
> ----- Original Message -----
> From: "Beman Dawes" <bdawes_at_[hidden]>
> To: <boost_at_[hidden]>; <boost_at_[hidden]>
> Sent: Friday, June 22, 2001 6:40 PM
> Subject: Re: [boost] Question about leading underscores
>
> > At 06:40 PM 6/22/2001, Greg Colvin wrote:
> >
> > >The safe rule is not to use leading underscores, although I
> > >think those above are technically OK, if useless.
> >
> > Why? Lots of programmers (me included) use a single leading underscore in
> > private member names. It never causes any problems, and is completely
> > standard conforming.
> >
> >
>
> The trouble with putting two underscores in a variable name is that you
> might end up colliding with a preprocessor / #define macro defined by the
> standard library. Since these #defines don't have scope you can't be safe
> from them and so and so as noted below the standard reserves certain names
> which it may replace by #define macros. Here is a related post that
> appeared recently on comp.c++.moderated.
>
> ----- Original Message -----
> From: "Pete Becker" <petebecker_at_[hidden]>
> Newsgroups: comp.lang.c++.moderated
> Sent: Monday, June 18, 2001 4:05 PM
> Subject: Re: Header protection against forbidden marcos
>
> > Attila Feher wrote:
> > >
> > > Hi All,
> > >
> > > I need some help in this trouble. As far as I know the only portable
> > > way for protecting header multiply inclusion is the good-old #ifndef,
> > > #define, stuff, #endif. However the C++ standard (for whatever reason)
> > > reserves _all_ macros for the standard library...
> >
> > No, it doesn't. Basically, all names that begin with an underscore
> > followed by a capital letter or by another underscore are reserved, just
> > as in C (it's actually a little broader: any name containing two
> > underscores is reserved, not just ones that begin with two underscores).
> > Users are free to guard their headers with their own macros, and
> > typically name them after the header:
> >
> > #ifndef Whatever_hh
> > #define Whatever_hh
> > // ...
> > #endif
> >
> > --
> > Pete Becker
> > Dinkumware, Ltd. (http://www.dinkumware.com)
> >
> ----- End Original Message from comp.c++.moderated-----
>
> <..Beman continues...>
> > That choice was based in an experiment some years ago trying several
> > candidates (including none, trailing underscore, and some others I can't
> > remember.) Leading underscore won.
> >
> > --Beman
> >
> > >17.4.3.1.2 Global names [lib.global.names]
> > >
> > >1 Certain sets of names and function signatures are always reserved to
> > > the implementation:
> > >
> > > --Each name that contains a double underscore __) or begins with an
> > > underscore followed by an uppercase letter (_lex.key_) is reserved
> > > to the implementation for any use.
> > >
> > > --Each name that begins with an underscore is reserved to the imple-
> > > mentation for use as a name in the global namespace.22)
> > >
> > > _________________________
> > > 22) Such names are also reserved in namespace ::std (_lib.re-
> > > served.names_).
> >
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 9
> Date: Sat, 23 Jun 2001 10:08:48 +1000
> From: John Max Skaller <skaller_at_[hidden]>
> Subject: Re: Re: Boost.Threads - name of the "thread" type
>
> williamkempf_at_[hidden] wrote:
>
> > You're too pessimistic.
>
> Realistic.
>
> Don't underestime how hard it will be to
> extend the abstract machine to support threading,
> and to change the core language to meet all the issues
> that raises -- AND to reach a consensus. Not to mention
> examining the whole Standard library again in the light
> of concurrent execution. This is a BIG job.
>
> If you think it is easy -- please write a paper,
> including modifications to the existing wording.
> I'm sure it would be welcomed. [Send me a copy!]
>
> --
> John (Max) Skaller, mailto:skaller_at_[hidden]
> 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
> checkout Vyper http://Vyper.sourceforge.net
> download Interscript http://Interscript.sourceforge.net
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 10
> Date: Fri, 22 Jun 2001 20:26:25 -0400
> From: <jeff_at_[hidden]>
> Subject: RE: Question about leading underscores
>
> > -----Original Message-----
> > From: Greg Colvin [mailto:gcolvin_at_[hidden]]
> > Sent: Friday, June 22, 2001 7:55 PM
> > To: boost_at_[hidden]
> > Subject: Re: [boost] Question about leading underscores
> >
> >
> > From: Beman Dawes <bdawes_at_[hidden]>
> > > At 06:40 PM 6/22/2001, Greg Colvin wrote:
> > >
> > > >The safe rule is not to use leading underscores, although I
> > > >think those above are technically OK, if useless.
> > >
> > > Why? Lots of programmers (me included) use a single leading underscore in
> > > private member names. It never causes any problems, and is completely
> > > standard conforming.
> >
> > So long as you remember not to follow the underscore with
> > a capital letter.
> >
> > Also, some shops use a leading underscore for unavoidable
> > variables in statement macros that might interfere with
> > other names. I know, don't use macros ...
>
> Just this week I wasted a couple hours when I got killed by a platform header
> file (socket.h) that has _send, _shutdown, _recv as macro definitions. This did
> very nasty things to some C++ code. Macros are EVIL, and sometimes you can't
> avoid them....
>
> Jeff
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 11
> Date: Fri, 22 Jun 2001 19:43:33 -0500
> From: "Corwin Joy" <cjoy_at_[hidden]>
> Subject: Re: Question about leading underscores
>
> > > From: Beman Dawes <bdawes_at_[hidden]>
> > > > At 06:40 PM 6/22/2001, Greg Colvin wrote:
> > > >
> > > > >The safe rule is not to use leading underscores, although I
> > > > >think those above are technically OK, if useless.
> > > >
> > > > Why? Lots of programmers (me included) use a single leading
> underscore in
> > > > private member names. It never causes any problems, and is completely
> > > > standard conforming.
> > >
> > > So long as you remember not to follow the underscore with
> > > a capital letter.
> > >
> > > Also, some shops use a leading underscore for unavoidable
> > > variables in statement macros that might interfere with
> > > other names. I know, don't use macros ...
> >
> > Just this week I wasted a couple hours when I got killed by a platform
> header
> > file (socket.h) that has _send, _shutdown, _recv as macro definitions.
> This did
> > very nasty things to some C++ code. Macros are EVIL, and sometimes you
> can't
> > avoid them....
> >
> > Jeff
> >
> >
>
> My aversion to underscore comes from the reverse. I used to prefix #include
> guard macros with an underscore ... until I had the fun of wasting several
> days tracking down why I couldn't get a standard library to compile when I
> included it. (way deep in the include heirarchy a variable type definition
> got ifdefed out by my include guard..)
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 12
> Date: Fri, 22 Jun 2001 21:16:47 -0400
> From: Douglas Gregor <gregod_at_[hidden]>
> Subject: Re: MSVC, STLport, and allocators
>
> On Friday 22 June 2001 06:21, you wrote:
> > Constructs like that one can be made to work with MSVC, although
> > occasionally you have to break them up, e.g.:
> >
> > typedef Allocator::template rebind<T> rebind;
> > typedef typename rebind::other t_allocator_type;
> >
> > -Dave
>
> Doesn't work :(
>
> Take a very simple test program:
>
> template<typename Allocator, typename T>
> struct foo {
> typedef Allocator::template rebind<T> new_alloc; // #1
> typedef typename new_alloc::other allocator_type;
> };
>
> MSVC tries to look up "rebind" for some reason, and chokes. So I try to fake
> a rebind, assuming it will fix things later:
>
> template<typename T> struct rebind { struct other {}; };
>
> Now I get an internal compiler error at the line marked #1.
>
> All this occurs before it's even tried to instantiate anything :(
>
> Doug
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 13
> Date: Sun, 24 Jun 2001 01:23:02 +1200
> From: Ross Smith <ross.s_at_[hidden]>
> Subject: Re: Not keen on Boost.Threads? [was: name of the "thread" type]
>
> Beman Dawes wrote:
> >
> > Ross Smith wrote:
> >
> > >(Then again, possibly I'm not the best guy to be putting his oar in at
> > >the moment; I'm not very keen on what I've seen of the Boost threads
> > >library so far, so clearly your aims are different to mine.)
> >
> > Could you explain why you aren't "very keen"?
> >
> > Because the library isn't cast in concrete yet, knowing what people dislike
> > about it would be helpful.
> >
> > If it is a matter of philosophy or aims rather that design details, that is
> > important and helpful. We need to understand other views.
>
> Well, judging from the current partial implementation, it's partly that
> it seems a bit too heavyweight -- something of a "kitchen sink"
> approach, trying to put every conceivable need into the API. I'd prefer
> something a bit more spartan.
>
> It also seems to be following the pthreads architecture too closely for
> my taste. It doesn't really "feel" like a designed-from-scratch C++
> library to me -- more like a thin OO wrapper around the pthreads API,
> and an attempt to emulate it on Windows. (I'm thinking in particular of
> condition variables, a pthread-specific concept that I don't think
> belongs in a generic threading library.)
>
> (When I have a bit more spare time, I'll polish up my own thread library
> and post it somewhere for comparison.)
>
> --
> Ross Smith <ross.s_at_[hidden]> The Internet Group, Auckland, New Zealand
> ========================================================================
> "Unix has always lurked provocatively in the background of the operating
> system wars, like the Russian Army." -- Neal Stephenson
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 14
> Date: Fri, 22 Jun 2001 21:28:05 -0400
> From: Beman Dawes <bdawes_at_[hidden]>
> Subject: Re: Re: Boost.Threads - name of the "thread" type
>
> John Max Skaller wrote:
>
> > This is an issue which needs to be addressed by the
> >Standardisation committee. But first, the abstract machine
> >needs to be extended to support the notion of threads. :-)
>
> I've written a first draft of a Formal Definition of "Thread". It attempts
> the definition in terms of the C++ Standard. It doesn't contain exact
> wording that would go in a future standard, but it at least identifies a
> number of areas of concern.
>
> Because it is checked in on a branch, the URL is a beauty:
>
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/boost/boost/libs/thread/doc/Attic/thread_formal_definition.html?rev=1.1.2.1&content-type=text/html&hideattic=0
>
> Comments would be appreciated. Are there areas of the behavior of the C++
> abstract machine that need to be mentioned that I've missed? I'm sure
> there are; I'm a library person rather than a core language person. In
> some ways the document is just a strawman to stimulate interest from core
> experts.
>
> Two points to bring up over and over again when you talk to core language
> people (the compiler writers) are that:
>
> 1) The LWG is talking purely in terms of an optional thread library. A
> compiler will not have to support it if they don't wish to. The standard
> will not mandate whether or not a compiler must supply a threading library;
> it is up to the vendor.
>
> 2) For many them what we are asking is that the standard be changed to
> reflect what their compilers are already doing. Their compilers are
> already supporting threading libraries; the idea is to standardize existing
> behavior, not invent a whole new set of behaviors.
>
> --Beman
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 15
> Date: Fri, 22 Jun 2001 21:33:14 -0400
> From: Beman Dawes <bdawes_at_[hidden]>
> Subject: Re: Question about leading underscores
>
> At 08:09 PM 6/22/2001, Corwin Joy wrote:
>
> >The trouble with putting two underscores in a variable name is that you
> >might end up colliding with a preprocessor
>
> The discussion was about single underscores never followed by an uppercase
> letter, never at namespace scope. IOW, totally standard conforming.
>
> --Beman
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 16
> Date: Fri, 22 Jun 2001 20:34:12 -0600
> From: "Greg Colvin" <gcolvin_at_[hidden]>
> Subject: Re: Re: Boost.Threads - name of the "thread" type
>
> A very useful start, thanks.
>
> From: Beman Dawes <bdawes_at_[hidden]>
> > John Max Skaller wrote:
> >
> > > This is an issue which needs to be addressed by the
> > >Standardisation committee. But first, the abstract machine
> > >needs to be extended to support the notion of threads. :-)
> >
> > I've written a first draft of a Formal Definition of "Thread". It attempts
> > the definition in terms of the C++ Standard. It doesn't contain exact
> > wording that would go in a future standard, but it at least identifies a
> > number of areas of concern.
> >
> > Because it is checked in on a branch, the URL is a beauty:
> >
> >
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/boost/boost/libs/thread/doc/Attic/thread_formal_definition.html?rev=1.1.2.
> 1&content-type=text/html&hideattic=0
> >
> > Comments would be appreciated. Are there areas of the behavior of the C++
> > abstract machine that need to be mentioned that I've missed? I'm sure
> > there are; I'm a library person rather than a core language person. In
> > some ways the document is just a strawman to stimulate interest from core
> > experts.
> >
> > Two points to bring up over and over again when you talk to core language
> > people (the compiler writers) are that:
> >
> > 1) The LWG is talking purely in terms of an optional thread library. A
> > compiler will not have to support it if they don't wish to. The standard
> > will not mandate whether or not a compiler must supply a threading library;
> > it is up to the vendor.
> >
> > 2) For many them what we are asking is that the standard be changed to
> > reflect what their compilers are already doing. Their compilers are
> > already supporting threading libraries; the idea is to standardize existing
> > behavior, not invent a whole new set of behaviors.
> >
> > --Beman
> >
> >
> > Info: http://www.boost.org Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]>
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
> >
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 17
> Date: Sat, 23 Jun 2001 00:21:53 -0500
> From: "Corwin Joy" <cjoy_at_[hidden]>
> Subject: Re: Question about leading underscores
>
> ----- Original Message -----
> From: "Beman Dawes" <bdawes_at_[hidden]>
> To: <boost_at_[hidden]>; <boost_at_[hidden]>
> Sent: Friday, June 22, 2001 8:33 PM
> Subject: Re: [boost] Question about leading underscores
>
> > At 08:09 PM 6/22/2001, Corwin Joy wrote:
> >
> > >The trouble with putting two underscores in a variable name is that you
> > >might end up colliding with a preprocessor
> >
> > The discussion was about single underscores never followed by an uppercase
> > letter, never at namespace scope. IOW, totally standard conforming.
> >
>
> Fair enough. But I claim you are still not technically safe if you prefix
> with an underscore, because, as specified in the standard 17.4.3.1.2, "Each
> name that begins with an underscore is reserved to the implementation for
> use as a name in the global namespace". [note that this says nothing about
> whether the underscore is followed by an uppercase letter].
>
> So let's take a paranoid example where things could go wrong:
>
> // your library might define
> #define wchar_t _long_char
> // The above is allowed by 17.4.3.1.4 which says that types from the
> Standard C library can live at the global namespace level (are reserved to
> the implementation), wchar_t is such a type.
>
> so if you have a class e.g.
> foo {
> private:
> int _long_char;
> wchar_t _wide_char;
> ...
> }
> you may be in for a surprise. Really the above only happens if your
> compiler defines a macro for a type or function - so hopefully you will be
> safe, OTOH, consider how the old (deprecated) version of <ctype.h> worked on
> many compilers:
>
> extern unsigned short *_pctype;
> #define isspace(_c) ( _pctype[_c] & _SPACE )
> #define ispunct(_c) ( _pctype[_c] & _PUNCT )
> #define isalnum(_c) ( _pctype[_c] & (_UPPER|_LOWER|_DIGIT) )
> #define isprint(_c) ( _pctype[_c] &
> (_BLANK|_PUNCT|_UPPER|_LOWER|_DIGIT) )
> #define isgraph(_c) ( _pctype[_c] & (_PUNCT|_UPPER|_LOWER|_DIGIT) )
>
> again, a problem if you have a member variable called _pctype.
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 18
> Date: Sat, 23 Jun 2001 09:55:58 +0200
> From: Jens Maurer <Jens.Maurer_at_[hidden]>
> Subject: Re: int64_t/boost/gcc 2.95.3
>
> John Max Skaller wrote:
> > Now it doesn't recognize long long constants :->
> >
> > ----------------------------------------------------
> > [root_at_pelican] ~/links/flx>g++ -Wno-long-long -D_GNU_SOURCE -ansi
> > -pedantic -Iboost_1_22_0 tmp.cpp
> > In file included from tmp.cpp:1:
> > boost_1_22_0/boost/cstdint.hpp:149: too many `l's in integer constant
> > boost_1_22_0/boost/cstdint.hpp:160: #error defaults not correct; you
> > must hand modify boost/cstdint.hpp
> > --------------------------------------------------
>
> You're running the compiler with "-ansi -pedantic", thus you
> explicitly asked to ban any non-standard construct, such as
> "long long" (which is not standard C++). Try removing the
> "-ansi -pedantic".
>
> Jens Maurer
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 19
> Date: Sat, 23 Jun 2001 10:16:57 +0200
> From: Jens Maurer <Jens.Maurer_at_[hidden]>
> Subject: Special functions, octonions, quaternions in the CVS
>
> The special functions, octonions, and quaternions by Hubert Holin
> are now added to the CVS.
>
> They're in a new sub-directory libs/math (and boost/math), expected
> to contain other libraries in the future. However, I just noticed
> that the namespace is still boost::octonion (and not
> boost::math::octonion). Is this something to worry about regarding
> consistency?
>
> Updates for the regression test results are in progress.
>
> Jens Maurer
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 20
> Date: Sat, 23 Jun 2001 10:29:15 +0200
> From: Jens Maurer <Jens.Maurer_at_[hidden]>
> Subject: Re: MSVC, STLport, and allocators
>
> Douglas Gregor wrote:
> > 2) Define BOOST_NO_STD_ALLOCATOR for MSVC, always.
>
> I've added this to the STLport section under MSVC in config.hpp.
> Please test. In particular, please check if it breaks something
> else.
>
> I'm reluctant to do so for the other libraries (with MSVC),
> because I can't test it myself.
>
> Jens Maurer
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
-- ------------------------------------------------------------------------------- Kevin Lynch voice: (617) 353-6065 Physics Department Fax: (617) 353-6062 Boston University office: PRB-565 590 Commonwealth Ave. e-mail: krlynch_at_[hidden] Boston, MA 02215 USA http://physics.bu.edu/~krlynch -------------------------------------------------------------------------------
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk