[boost] Re: Problem on the CVS version of the top web page
On Friday, August 22, 2003, at 8:14 AM, David Abrahams wrote: Daryle Walker [EMAIL PROTECTED] writes: The CVS version of BOOST_ROOT/index.htm does not have Latest News entries for 1.30.1 and 1.30.2. (I guess they haven't been copied from the 1_30_x branch yet.) Feel free to make the copy, Daryle. Obviously, I can blindly copy the missing entries to the main-trunk's version of the top page. But, isn't there some sort of CVS procedure to fuse all the changes in a branch back into the main trunk? I wouldn't want to potentially mess up that procedure. (I've barely figured out how to download, update, and upload changes to/from the main trunk, so I suggest finding a CVS expert to do the merge.) Daryle ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::format on gcc2.96?
On Friday, August 22, 2003, at 8:20 AM, David Abrahams wrote: Jarl Friis [EMAIL PROTECTED] writes: All true. Unfortunately, 2.96 was released by RedHat with one popular version of Linux, which makes it (in many peoples' eyes) an important compiler to support anyway. I will in line with the announcement suggest that any support needed for or related to this particular gcc version should be redirected to the supplier of the compiler (i.e. redhat). That's a very nice way to avoid extra work for Boost library developers which they shouldn't have to do in the first place, but since RedHat isn't actually going to do anything for users, leaves them in the cold. I don't think we support beta versions of compilers, so why should we support a version of a compiler that its creators (AFAIK) don't even support? For example, if a Boost incompatibility is the fault of the GCC 2.96 complier, are we supposed to figure out the internal difficulties and corrections/workarounds that even GCC.org won't bother with? Anyway, support for certain compiler versions seem to fade as new versions are released (e.g. we don't really support CodeWarrior Pro 5.x or MSVC++ 5.x). Do we even support GCC 2.95 that much? The user can resolve the problem by downloading the 2.95 or 3.x versions, which gains the user a lot more support, especially if the resolution to a Boost incompatibility is beyond our ability to fix (like a compiler patch). I am noticing a theme in your postings today: you seem remarkably unsympathetic to anyone who hasn't made what you consider to be the right choice of software systems. At Boost we *generally* try not to hold these kinds of missteps against our users, because we're more interested in seeing our software widely used than in avoiding the hassles of platform dependencies; I don't think you're going to change that culture with a few postings (at least I hope not)! Daryle ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: lexicographic: review request?
On Friday, August 22, 2003, at 6:01 PM, Jan Langer wrote:
what is needed for the lexicographic class to be included into boost?
if it is a formal review (probably a really short one) i want to
request it. maybe it can also be reviewed together with other utility
components.
Do you have anything else forthcoming? If not, then don't bother
holding up this class for other potential co-components.
the current version is in the boost-sandbox and consists of the
following three files:
boost/utility/lexicographic.hpp
libs/utility/doc/lexicographic.html
libs/utility/test/lexicographic_test.cpp
There's also a Jamfile in the test directory.
and again a small decription
It is a small class which helps to avoid error-prone if-else cascades
if a certain lexicographic order for different sorting criteria has to
be implemented.
example:
struct person
{
int age;
std::string firstname, lastname;
};
bool operator (person const p1, person const p2)
{
return boost::lexicographic
(p1.lastname, p2.lastname, cmp_lower)
(p1.firstname, p2.firstname, cmp_lower)
(p2.age, p1.age);
}
...
std::set person group;
now the member of group are sorted after last name in ascending order
independent of lower or upper case. if the last name is equal they are
sorted after the first name in the same manner, and if the whole name
is equal they are sorted according to their age, with old people in
front of the set.
Seems like a nice class. There is a std::lexicographical_compare. It
works on comparing two iterator sequences. It can automatically deal
with different sequence lengths, but your class can be used with any
method of component access. Your class can also spread out the
comparison code.
Daryle
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Virus defense
Jarl Friis [EMAIL PROTECTED] skrev i meddelandet news:[EMAIL PROTECTED] [EMAIL PROTECTED] writes: Hello, Boosters - I am sure that many of you have received many e-mails from the [EMAIL PROTECTED] (http://securityresponse.symantec.com/avcenter/venc/data/[EMAIL PROTECTED] m.html ) e-mail virus. The problem with this virus is that it will spread itself to e-mail addresses - not just from Outlook's address book - but to any addresses it finds in the user's files. e.g., HTML files on the user's hard drive. e.g., HTML files that are part of the Boost distribution. That is not true! On the OS I am using it does not spread at all. All this is a *Windows* related issue/problem, No, it is not. It is a market penetration problem. It is no fun writing a virus for Linux, becase all 12 users would be infected immediately, and there it ends. If you write for Windows, you can infect a hundred million. Bo Persson ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: what happened to allocators in boost?
Douglas Gregor wrote: The allocator design focused on the benefits one could get from specialized allocators for containers, e.g., data structures that may allocate large chunks of memory that are expected to be used together. They don't really give us much for components like shared_ptr that allocate one thing (and note that shared_ptr does not allocate the pointer it stores, although it does allocate a reference count). boost::function supports an allocator argument, but the C++ committee is considering removing this allocator from the library TR version of function for precisely this reason. If function no longer has the allocator argument, how should we then use function in a hard real-time environment? Does the committee assume that such systems have deterministic allocators or that users replace global new/delete anyway? Thanks Regards, Andreas ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0-1.30.2: no more thread support for Linux?
One more thing: what exactly can go wrong with 1.30.0 if -pthread isn't used? Is it boost specific or a general thing (e.g. issues w/ respect to libstdc++)? A general thing - without this then: Your std lib is not thread safe. Your C lib is not thread safe. g++ will not emit thread safe exception handling code. Thus while for C programs enabling thread support is just a question of linking to the right libraries, for C++ you also need to ensure that the compiler knows that you want thread safe code. John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] operator(path, path)?
Daryle Walker [EMAIL PROTECTED] writes: On Thursday, August 21, 2003, at 10:12 PM, Beman Dawes wrote: At 06:38 PM 8/21/2003, David Abrahams wrote: I need to make a mapping over paths. Is there any important reason there's no operator provided? I don't think it has been discussed. I've had the need myself, but worked around it by using path::string() to generate the key. There were a number of discussions about operator== and !=. They can be subject to serious abuse and misunderstanding, and so are left out. I'm still not sure if that was the right decision, so might be willing to review it. Anyhow, we should be able to support maps and sets of paths. I'll try to give it some thought in the morning when I'm wider awake. If it isn't safe to even have the equality operators, then having the ordered inequality operators may not be safe either. If David has an ordering he wants to use in mind, then a custom comparison function object class can be made. I've seen quite a few requests for operator() for class that don't have it (e.g. std::complex) just for the purpose of using it as an element type of an associative container. Forcing a type of have such an operator, even when it's inappropriate (i.e. the type doesn't suggest an overwhelmingly-natural ordering), defeats the purpose of the associative container class templates having comparator types in the first place! But paths do have such an ordering. It's a lexicographic compare on the conceptual underlying vector they contain. In other words x.m_name y.m_name Unfortunately, that vector isn't available to clients of path so you have to use x.string() y.string(), which is only a poor substitute for the actual vector. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problem on the CVS version of the top web page
Daryle Walker [EMAIL PROTECTED] writes: On Friday, August 22, 2003, at 8:14 AM, David Abrahams wrote: Daryle Walker [EMAIL PROTECTED] writes: The CVS version of BOOST_ROOT/index.htm does not have Latest News entries for 1.30.1 and 1.30.2. (I guess they haven't been copied from the 1_30_x branch yet.) Feel free to make the copy, Daryle. Obviously, I can blindly copy the missing entries to the main-trunk's version of the top page. But, isn't there some sort of CVS procedure to fuse all the changes in a branch back into the main trunk? No. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::format on gcc2.96?
Daryle Walker [EMAIL PROTECTED] writes: That's a very nice way to avoid extra work for Boost library developers which they shouldn't have to do in the first place, but since RedHat isn't actually going to do anything for users, leaves them in the cold. I don't think we support beta versions of compilers, so why should we support a version of a compiler that its creators (AFAIK) don't even support? I'm not saying that we should. I'm saying that some of us will anyway, and we shouldn't automatically tell 2.96 users with problems to go away until the library maintainers have had a chance to decide if they're going to try to fix the problem. For example, if a Boost incompatibility is the fault of the GCC 2.96 complier, are we supposed to figure out the internal difficulties and corrections/workarounds that even GCC.org won't bother with? We do that stuff all the time with vc6/7, Borland, gcc 2.95.x, SunPro, HP, Intel 5/6... The list goes on. Even when the compiler is current, the vendor is often of no help finding a workaround. Anyway, support for certain compiler versions seem to fade as new versions are released (e.g. we don't really support CodeWarrior Pro 5.x or MSVC++ 5.x). Do we even support GCC 2.95 that much? The user can resolve the problem by downloading the 2.95 or 3.x versions, which gains the user a lot more support, especially if the resolution to a Boost incompatibility is beyond our ability to fix (like a compiler patch). Downloading and installing a new compiler for a linux system is beyond the capacities, and sometimes the permissions, of many users. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
Andreas Huber wrote: If function no longer has the allocator argument, how should we then use function in a hard real-time environment? In this context, an allocator parameter is only an excuse for implementors to avoid doing the necessary work to make function useful out of the box. You can always use a custom allocator, right? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost 1.30.2 thread support issue under cygwin
I just downloaded and tried to build boost 1.30.2 under cygwin using gcc 3.2 (20020927 (prerelease) if you want to be precise). libboost_thread.dll won't compile because it gives the Thread support is unavailable! error. A sample is: === gcc-C++-action libs/thread/build/bin/libboost_thread.dll/gcc/debug/runtime-link-dynamic/threading-multi/condition.o In file included from libs/thread/src/condition.cpp:12: /cygdrive/c/proj/nrl/main/BARS/tracking/DDF/toolkits/boost-1.30.2/boost/thread/condition.hpp:17:5: #error Thread support is unavailable! In file included from libs/thread/src/condition.cpp:14: /cygdrive/c/proj/nrl/main/BARS/tracking/DDF/toolkits/boost-1.30.2/boost/thread/thread.hpp:17:5: #error Thread support is unavailable! In file included from /cygdrive/c/proj/nrl/main/BARS/tracking/DDF/toolkits/boost-1.30.2/boost/thread/thread.hpp:22, from libs/thread/src/condition.cpp:14: /cygdrive/c/proj/nrl/main/BARS/tracking/DDF/toolkits/boost-1.30.2/boost/thread/mutex.hpp:17:5: #error Thread support is unavailable! g++ -c -Wall -ftemplate-depth-100 -DBOOST_THREAD_BUILD_DLL=1 -g -O0 -fno-inline -mthreads -Ilibs/thread/build -I /cygdrive/c/proj/nrl/main/BARS/tracking/DDF/toolkits/boost-1.30.2 -o libs/thread/build/bin/libboost_thread.dll/gcc/debug/runtime-link-dynamic/threading-multi/condition.o libs/thread/build/../src/condition.cpp === From the g++ man pages, -mthreads Support thread-safe exception handling on Mingw32 and only defines _MT for Mingw32. Therefore, after threading support is disabled on line 53 of boost/config/compiler/gcc.hpp, nothing actually enables it again for a non-Mingw32 cygwin build. Is this the desired behaviour? (If I removed the check for __CYGWIN__ in gcc.hpp, everything compiles and the tests seem to run correctly). Cheers, Simon ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexicographic: review request?
On Sat, Aug 23, 2003 at 11:21:03AM +0200, Daniel Frey wrote:
a) Short-circuiting
b) Unnamed functions
Jan Langer wrote:
bool operator (person const p1, person const p2)
{
return boost::lexicographic
(p1.lastname, p2.lastname, cmp_lower)
(p1.firstname, p2.firstname, cmp_lower)
(p2.age, p1.age);
}
The two points listed above are both visible here: Even if there are no
persons with the same name, age is accessed. Even worse, it may be a
costly method age() and the unaware user creates much worse code than
using nested if-else-structures.
Also, you might not want to define operator. Sometimes, you just need
it in one place, e.g. std::sort( v.begin(), v.end(), /*HERE*/ );
I have imagined another syntax which addresses the issues somewhat:
// use boost::lamdba
boost::lexicographicperson
( _1.first,cmp_lower )/* see below */
( _1.last, cmp_lower )
( bind(T::age,_1) /* use default cmp */ )
( p1, p2 )
The basic idea is you say lexicographicT to start creating a
comparator for T objects, and then use continual argument lists (as in
the original example), but where each argument list is either
( lambda(T){ return T.component }, component_comparator )
or
( lambda(T){ return T.component } ) // uses default comparator
Finally, when you see an argument list with arguments of type
( T, T )
you know you are done and it is time to compare now. Of course, if you
leave off this final argument list, then you get back a function object
which can be passed, e.g., to std::sort() as in the example above.
The problem (cited see below) is that since operator . isn't
overloadable, the boost::lambda expressions like _1.first don't
actually exist. Offhand I dunno if C++ in general or Boost in
particular offers a nice way to lambda-ify such a member-variable
expression.
Anyway, just wanted to share some ideas which I think may be a good
direction to go to address the issues Daniel raised.
--
-Brian McNamara ([EMAIL PROTECTED])
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexicographic: review request?
On Sat, Aug 23, 2003 at 09:45:42AM -0400, Brian McNamara wrote: // use boost::lamdba boost::lexicographicperson ( _1.first,cmp_lower )/* see below */ ( _1.last, cmp_lower ) ( bind(T::age,_1) /* use default cmp */ ) ( p1, p2 ) ... The problem (cited see below) is that since operator . isn't overloadable, the boost::lambda expressions like _1.first don't actually exist. Offhand I dunno if C++ in general or Boost in particular offers a nice way to lambda-ify such a member-variable expression. I just looked at the boost::lambda documentation and see that they were clever enough to make bind() work on member variables as well as member functions. So the actual syntax would be // Assume p1.first, p1.last, and p1.age() are all legal boost::lexicographicperson ( bind(T::first,_1), cmp_lower ) ( bind(T::last,_1), cmp_lower ) ( bind(T::age,_1) /* use default cmp */ ) // above returns a comparator object; can add ( p1, p2 ) // to call it if desired -- -Brian McNamara ([EMAIL PROTECTED]) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Deprecation/removal of libraries
I'd like to deprecate or remove two libraries: - min_rand has been the only entry in our list of Obsolete Libraries for quite some time. Random is quite mature, so let's just eliminate min_rand now. - compose has been surpassed by bind to the point where we dissuade users from using compose if they ask, and tell them to use bind instead. Let's deprecate this in 1.31.0 and remove it in 1.32.0. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [bgl] typo in adjacency_list_io.hpp
Hi all
gcc 3.2 generates warnings about implicit typename in line 313 in file
adjacency_list_io.hpp. I think either there should be EdgePrinterG,E
call or class G should be renamed to Graph, as is in the rest of
templates in this file.
Regards,
Janusz
// line 301, cvs head
templateclass G, class E
struct GraphPrinterG,no_property,E
: public EdgePrinterG,E
{
GraphPrinter( G g )
: EdgePrinterG,E(g)
{}
const GraphPrinter operator () ( std::ostream out ) const
{
out n num_vertices(graph) std::endl;
EdgePrinterGraph,E::operator ()( out );
// ^
return (*this);
}
};
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- Peter Dimov [EMAIL PROTECTED] wrote:
In this context, an allocator parameter is only an excuse for implementors
to avoid doing the necessary work to make function useful out of the box.
You can always use a custom allocator, right?
Considering the variety of real life requirements and platforms, it is not practical
to make a
library that work out of the box. That is why STL has allocators. In one project, if
STL did not
have allocators, I would have to implement my own containers. I was so happy that I
didn't have
to do it.
At least a library should be consistent about memory management.
The issue is how consistent boost is about it (STL is very consistent)? It seems that
boost
doesn't have any idea about how it manages its memory.
For example if a boost class X uses std::list, does it have to expose the std::list
allocator or
should it use the standard std::allocator.
templatetypename T
struct X
{
std::listT l;
};
OR
templatetypename T, typename A=stl::allocatorT
struct X
{
std::listT, A l;
};
Which definition is more friendly to boost?
Is it allowed for a boost libarary to use global new/delete? If so, should it be
documented?
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [filesystem] operator(path, path)?
At Friday 2003-08-22 13:06, you wrote: At 11:35 PM 8/21/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: At 06:38 PM 8/21/2003, David Abrahams wrote: I need to make a mapping over paths. Is there any important reason there's no operator provided? I don't think it has been discussed. I've had the need myself, but worked around it by using path::string() to generate the key. There were a number of discussions about operator== and !=. They can be subject to serious abuse and misunderstanding, and so are left out. Whoa, really? I'm still not sure if that was the right decision, so might be willing to review it. I'm curious about it, anyway. Is path(abc)==path(ABC) true in the sense of being the same path? The correct answer is yes, no, or maybe, depending on the operating system. There are a ton of other examples where two paths which are textually different are sometimes the same path. The counter argument is that defining path equality as path::string() equality seems natural, even if it doesn't answer the are they the same path? question. But this does lead to fragile programs; we can see that in the Boost regression test reporting where slight changes in the way bjam reports paths often break the status tables (which rely on assumptions about path equality.) operator== on paths can be a sign of poor, or at least fragile design. are we going to suggest to the core committee that somefloat == someotherfloat be removed from the language. Certainly the fragility on path can be no worse. --Beman PS: I just changed the FAQ entry to use that example; it is clearer than the one given before. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: There oughta be a law ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Bug in boost/empty.hpp with variant??
I just tried to use boost::variant with the HEAD version of boost and I
am getting multiply defined symbols in empty.hpp. (gcc 3.2 on Linux)
I fixed it by adding inline to the two non-template methods (see below):
inline bool operator==(const empty, const empty)
{
return true;
}
inline bool operator(const empty, const empty)
{
return false;
}
Is this a bug in the code or is there some other way to wrok around it?
Thanks,
Allen
--
-- Allen Bierbaum [EMAIL PROTECTED]
-- Research Assistant and PhD Candidate
-- VR Juggler Team www.vrjuggler.org
-- Virtual Reality Applications Center www.vrac.iastate.edu
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: feed_args.hpp bug (and patch)
Paul Hamilton wrote:
Peter Dimov [EMAIL PROTECTED] wrote:
This will work, although I had
templateclass Tr, class Ch inline
void empty_buf(BOOST_IO_STD basic_ostringstreamCh,Tr os) {
os.str( std::basic_stringCh, Tr() );
}
in mind as it is a smaller change.
This works just fine also:
*** feed_args.hpp.orig Thu Aug 21 22:45:28 2003
--- feed_args.hpp Fri Aug 22 10:19:55 2003
***
*** 35,40
templateclass Tr, class Ch inline
void empty_buf(BOOST_IO_STD basic_ostringstreamCh,Tr os) {
! static const std::basic_stringCh, Tr emptyStr;
! os.str(emptyStr);
}
--- 35,39
templateclass Tr, class Ch inline
void empty_buf(BOOST_IO_STD basic_ostringstreamCh,Tr os) {
! os.str(std::basic_stringCh, Tr());
}
Paul.
ok, I'll commit that on monday. I had made the empty string as a static
variable hoping it could help avoid re-allocating memory for the
temporary strings, but it doesnt seem to, so it's best to simplify that
anyway.
But, for curiosity, isn't this static-variable in function supposed to
work here, according to the standard ?
--
Samuel
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [thread_dev] Fix for compilation failure on linux (pthreads)
Hello,
I have tried to compile thread_dev branch on linux, but it fails. Patch
below fixes this issue, but it is not tested.
I would also like to ask, if there is any plan to merge thread_dev branch
into the standard boost (I need thread pools, that's the reason for
question). The second question is, if there is an intention to submit
boost thread API to the C++ standard commitee as a C++ thread API
proposal...
Thanks,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
Index: src/mutex.cpp
===
RCS file: /cvsroot/boost/boost/libs/thread/src/mutex.cpp,v
retrieving revision 1.11.4.4
diff -u -r1.11.4.4 mutex.cpp
--- src/mutex.cpp 3 Apr 2003 22:56:49 - 1.11.4.4
+++ src/mutex.cpp 23 Aug 2003 22:05:14 -
@@ -228,7 +228,8 @@
do_unlock();
}
#elif defined(BOOST_HAS_PTHREADS)
-mutex::mutex()
+mutex::mutex(const char* name)
+: boost::detail::named_object(name)
{
int res = 0;
res = pthread_mutex_init(m_mutex, 0);
@@ -268,7 +269,8 @@
state.pmutex = m_mutex;
}
-try_mutex::try_mutex()
+try_mutex::try_mutex(const char* name)
+: boost::detail::named_object(name)
{
int res = 0;
res = pthread_mutex_init(m_mutex, 0);
@@ -317,8 +319,9 @@
state.pmutex = m_mutex;
}
-timed_mutex::timed_mutex()
-: m_locked(false)
+timed_mutex::timed_mutex(const char* name)
+: boost::detail::named_object(name),
+ m_locked(false)
{
int res = 0;
res = pthread_mutex_init(m_mutex, 0);
Index: src/shared_memory.cpp
===
RCS file: /cvsroot/boost/boost/libs/thread/src/Attic/shared_memory.cpp,v
retrieving revision 1.1.4.11
diff -u -r1.1.4.11 shared_memory.cpp
--- src/shared_memory.cpp 18 Mar 2003 23:30:51 - 1.1.4.11
+++ src/shared_memory.cpp 23 Aug 2003 22:05:14 -
@@ -131,7 +131,7 @@
int cflag = (flags create) ? O_CREAT|O_TRUNC|O_EXCL : 0;
for (;;)
{
- m_hmap = shm_open(m_name.c_str(), oflag|cflag, 0);
+ m_hmap = shm_open(this-name(), oflag|cflag, 0);
if (m_hmap == -1)
{
if (errno != EEXIST || (flags exclusive))
@@ -144,7 +144,7 @@
assert(res);
throw thread_resource_error();
}
- m_hmap = shm_open(m_name.c_str(), oflag, 0);
+ m_hmap = shm_open(this-name(), oflag, 0);
if (m_hmap == -1)
{
if (errno == ENOENT)
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
