At this point in time, I vote to reject the library. My vote is based
upon a review of the interface and implementation in optional.hpp of the
zip file I downloaded from the link posted by Fernando on Dec. 12, and
following the discussion via the mailing list digests. I will qualify my
vote by
Adjusted at five points; please ignore the previous one.
-- Forwarded message --
At this point in time, I vote to reject the library. My vote is based
upon a review of the interface and implementation in optional.hpp of the
zip file I downloaded from the link posted by Fernando
I suggest adding another boost defect: BOOST_BROKEN_ADL (or similar)
How about BOOST_LIBRARY_IMPL_VULNERABLE_TO_ADL? It's not that the
compiler's ADL implementation is broken, it's that the library
implementation isn't protected against ADL lookups where it needs
to be.
Dave
Ah, that's the reason. But given my recent discomfort about
unmaintainable code, look at it again:
# if BOOST_WORKAROUND(__HP_aCC, = 33900)
templatebool cond, typename T struct enable_if;
# else
templatebool, typename T struct enable_if;
# endif
Does this really
See also the discussion about a general coding guideline to always
provide a name for template parameters. Here, the maintainer already
did the right thing when he received the patch.
If the maintainer hid the compiler brokenness completely, then they did
the wrong thing. If they didn't,
No, I would prefer
#if BOOST_WORKAROUND(__HP_aCC, =33900) ||
BOOST_WORKAROUND(__VisualAge, =12345)
template bool cond, typename T struct enable_if;
#else
template bool, typename struct enable_if;
#endif
I already explained the reason: C++ compiler vendors use Boost
I would be searching namely for smart_ptr. I know that smart pointer is
the name for the resource management idiom.
But those that don't would look for resource_manager or resource_mgr
(and might even find res_mgr). The smart_ prefix is quite useless in
this context, there isn't an old
So then reverse resource_manager and get managed_resource, or just
managed.
Why not just resource? Management is implied anyway; that's the
reason for the existence of the class.
*laugh* I was thinking exactly the opposite. To me, the resource itself
is clear from the template parameter
*laugh* I was thinking exactly the opposite. To me, the resource
itself
is clear from the template parameter -- it's the management that
needs to
be indicated.
+1 for managed.
What template parameter? That's not a part of the name.
Template parameters, just like function
of emitting the bad lexical cast error.
Dave
--
Dave Gomboc
M.Sc. Student1-41 Athabasca Hall
Department of Computing Science Edmonton, Alberta,
University of AlbertaCanada T6G 2E5
Hi,
Yes, the whitespace problem is fixed in the forthcoming version.
What's forthcoming version? Is this forthcoming Boost release?
Then I don't see any changes to lexical_cast.hpp at all. Or
lexical_cast update will be committed later?
Yeah, I was aware that work had been done on it,
Here is the current list:
It looks to me like we should hold the lexical_cast changes until the
next release. There are really two issues IIUC - some wide-character
support problems and VC++ 6.0 support. While the wide-character problems
might be possible to resolve quickly, VC++ 6.0
Just curious if anyone's doing something along these lines. A quick
google search on boost turned up only Boost.Test, which (I think?) is
something quite different.
Dave
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Page Subrules:
... yields a complex type. Thus, while it is easy to write:
int r = i | j k; // where i, j, and k are ints
Forget rules for a second. Expression templates...
The sentence seems to be cut off in the middle. I'm not sure what the
repair should be.
Dave
Section Portability
8. Intel 7.0VisualAge C++ 5.02
should be split into two lines.
Dave
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Yes. Since type_info objects can't be copied, one might instead store
pointers or references to them.
Pointers would be better because, for better or for worse (mostly for
worse), standard exceptions support assignment as part of their
interface.
Why should boost exception classes behave
Since you advocate elsewhere that exception classes be derived
from std::exception, the answer is because otherwise LSP would
be violated.
You can't access the derived class' assignment operator through a
pointer/reference to a polymorphic base, so that point is moot.
Well, you're the
It would be nice if boost::optionalT had operator defined whenever
operator was defined for T. This would allow us to use optionalT
as the key of an associative container. I suggest the following
semantics:
bool operator(optionalT const x, optionalT const y);
Returns: If y is
When I define rules x, y, and z such that
x = ch_p('a');
y = ch_p('a');
z = !x y;
it appears to operate the same as if z were defined to be
z = (ch_p('a') | epsilon_p) 'a';
which accepts aa, but rejects a.
On the other hand, if I define z as
z = (epsilon_p | ch_p('a'))
Instead of dropping elements when the buffer is full, we might also
consider waiting or throwing a failure.
I consider dropping elements to be surprising behaviour. If there's no
policy stuff, then either decide that it will throw, or leave what happens
to be implementation-defined.
Dave
The file boost/regex/v4/perl_matcher_non_recursive.hpp includes
statements such as
end += std::min((unsigned)re_detail::distance(position, last),
desired);
operator+= is appropriate for random-access iterators, but not for
merely bidirectional iterators such as std::listchar::iterator, which
http://www.boost.org/libs/regex/template_class_ref.htm#partial_matches
There are two examples given. Though the examples are different, in
both cases, the example links to a complete implementation of the
first example. This likely was a cut-and-paste error.
Dave
Thanks for the quick fixes on the other bug reports, John.
Here is what might be a new one. The code below indicates that no match
was found, but I was expecting it to indicate that a partial match was
found beginning at 'a'. If I don't push the space on beforehand, I do
get a partial match.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
At the top of signal.hpp:
namespace boost {
#ifndef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
namespace BOOST_SIGNALS_NAMESPACE {
namespace detail {
templateint Arity,
typename Signature,
typename Combiner,
typename Group,
create_directory
and
create_directories
Another option might be: create_directory_and_parents
That name is longer than create_directories although it better
describes the function.
I like create_directory_path
That one's good, and captures the essential distinction
dave const in array{] = {1, 2, 3, 4};
dave boost::arrayint ba(array);
dave std::copy(ba.begin(), ba.end(), std_ostream_iteratorint(std::cout));
dave
dave Is there already a way to do this? Or is there some reason why
dave one would never want to do this?
dave
dave AFAICR boost::array allows
-- portable_path(/foo/bar) - throws on Windows
--
-- Not sure why this would throw, what is the purpose of
-- portable_path? /foo/bar is perfectly reasonable on Windows.
-
- It's perfectly reasonable but it doesn't have a portable meaning.
- It
- is a relative
Right now I am questioning whether the
pointer-like semantics is worth it to me. I would probably prefer that
clients type more to test whether a value is initialized so that they
can type less to call a function that takes an optional as a parameter
when they have a value to pass in. Sorry
template typename T
class nilable {
Was that small enough to be considered not copyrightable, warrantable, etc.
?
If so, fine. Otherwise I guess I have to disclaim any warranty, etc. Boost
Public Licence?
Dave
___
Unsubscribe other
Here's a (contrived) example of how the implicit conversion breaks
generic code:
[example snipped]
The point is that optionalT is not a T, and most notably, a template
function will never perform the coercion. Replace the lines like
B b = get2(args);
in your example with real calls
[Dave Abrahans]
Optional is a container. I've never seen a container in C++ which didn't
have both a value interface and an element-access interface. How do
you propose to achieve that with optional?
It darn well shouldn't be a container, it should be a concrete type! ;-)
[Joel de Guzman]
[Eric Friedman]
Why not overload boost::get again for optional?
It might be a good idea for other reasons, but it doesn't solve the problem
I'm trying to solve.
[Brian McNamara]
do_something( adapt( 3 ) );
do_something( adapt( nilableint(3) ) );
do_something( adapt(
[Fernando Cacciola]
The most fundamental point is that being Haskell a pure functional
language there is no possibly undefined behaviour to worry about,
so Maybe doesn't need to address this issue as optional does.
... and later ...
I account the possibly undefined behavior of accesing an
[Fernando Cacciola]
I'm saying that the choice made by variant in this regards is to the
code using get as hopeless as undefined behaviour. I don't think that
preconditions (and exceptions thereof) should be used to arbitrarily
make the illusion of giving meaning to an operation that is
35 matches
Mail list logo
