My shared_ptr changes will be in GCC 4.4.0 and I've solved the remaining issue with result_of, so I hope that will be in 4.4.0 too.
My shared_ptr changes will be in GCC 4.4.0 and I've solved the remaining issue with result_of, so I hope that will be in 4.4.0 too.
I found some time at the weekend to finish updating GCC's
std::shared_ptr
with the changes from n2637.
operator<
on shared_ptrs now compares the
contained pointers instead of comparing the address of the
control block. This makes operator<
a
partial function, which is consistent with comparisons on
raw pointers ... but makes it useless in nearly all cases
where you might use shared_ptr!
LSB
Wow, they haven't finished flogging that dead horse yet.
cinamod, the simplest solution is to add an overload with the parameters reversed. That's easy if you use a function object instead of a function pointer:
struct my_pred
{
bool operator()(const ComplexType& v1, int v2) const
{ return v1.field < v2; }
bool operator()(int v1, const ComplexType& v2) const
{ return v1 < v2.field; }
};
...
lower_bound(begin, end, val, my_pred());
What MSVC is doing is not unreasonable, lower_bound requires a StrictWeakOrdering and one of the properties of a strict weak ordering is anti-symmetry. It's not possible to verify your predicate is antisymmetric if the order of the argument types matters.
Also, see the definition of equivalence used by the STL. Your predicate makes it impossible to test for equivalence.
I'm working on a short article about StrictWeakOrderings, which I'll post here when it's ready.
Formatting of diary previews is very broken, especially if you use <pre> or try to control the layout. It makes posting code annoying. The problem seems to be related to blank lines inside <pre> blocks, which get <p> elements added. The auto-paragraph-break feature should not apply to text within a <pre> which is by definition already formatted.
result_of
Some ramblings about result_of, a little utility available from Boost. It was proposed for standardisation in n1454, was included in TR1, and will be in C++0x. It's used inside some other Boost libraries, but many C++ programmers will never need to use it directly, or know any of what follows. If you do need to know about it, there's a much better description in Pete Becker's book.
The syntax, e.g. result_of<Func(Arg1*,
Arg2&)>::type
may not obvious at first glance,
even if you know C++ fairly well. Result_of is a unary metafunction,
a template with one
parameter:
template<typename Signature>
struct result_of;
There is no definition for the primary template, only for
partial specializations where the template parameter is a
function type:
template<typename Fn, typename... ArgTypes>
struct result_of<Fn(ArgTypes...)>
{
typedef ??? type;
};
The specialization contains a typedef, type
.
In the earlier example, the function type used as the
template argument to result_of is Func(Arg1*,
Arg2&)
That type is a function taking a pointer to Arg1 and an lvalue-reference to Arg2, and returning Func. Compare it to the more familiar declaration of a pointer to such a function:
Func (*)(Arg1*, Arg2&)
This doesn't mean there is a function taking those
arguments and returning Func, it's just a made-up type
passed to result_of, which extracts the necessary
information from the type using a bit of template
metaprogramming from the school of Boost. The function-type
syntax is used to mimic the syntax of invoking some callable
type, Func
, with arguments of those types, as in
Func func;
Arg1 arg1;
Arg2 arg2;
func(&arg1, arg2); // compare with Func(Arg1*,Arg2&);
So result_of<Func(Arg1*,Arg2&)>::type
is a
typedef for
the return type of the call above, which due to overloading
and implicit conversions could be pretty much
anything!
// type is int if Func is:
typedef int (*Func)(Arg1*,const Arg&);
// type is char if Func is:
struct Func {
void operator()(int);
char operator()(void*, Arg2) const;
};
// type is double given:
struct Base { };
struct Arg1 : Base { };
struct Arg2 : Base { };
struct Functor {
int operator()(Arg1*, Arg2&);
double operator()(Base*, Base&, Base* = 0) const;
};
typedef const Functor Func;
In the last example the first operator, which matches the
argument types exactly, is not const, so cannot be called on
a const Functor
, so the second operator is
chosen, converting the arguments and using the default for
the third argument. Getting result_of to give the right
answer was a fun little exercise.
C++0x support in GCC
I'm still working on std::result_of
for
libstdc++. Implementing it to
follow the current
C++0x draft was easy ... unfortunately I think the
current draft is wrong.
struct X {
void operator()(int&) { }
int operator()(int&& i) { return i; }
} x;
std::result_of< X(int&&) >::type i = x(0);
I think the code above should compile, but if I follow the
draft wording it won't, because result_of selects the first
overloaded function-call operator, which has a void return type.
struct Y {
int i;
};
typedef int Y::*MemPtr;
std::result_of< MemPtr(Y*) >::type i;
The example above works with tr1::result_of
but
not with std::result_of
, because this is not valid:
MemPtr mp = &Y::i
Y y = { };
mp(&y); // ERROR - must use (y.*mp) instead
N1695
addressed this topic and suggested making
pointers-to-members callable as above. Without that change
it's harder to write generic code that works with all callable
types. This is just one of the places where C++ syntax isn't
as regular as it could be (to put it politely) but once geniuses
such as Peter Dimov and Doug Gregor have done the hard work
(e.g. std::bind, std::function) the rest of us can use
higher-order functions in C++ without caring that the
implementations aren't always pretty.Softkid is surprised V8 support x86 and ARM but not ia64. He must know more people than I do who run Windows desktops or mobile phones on Itanium.
Top Tips
GNU maintainers, tease your users by automatically inserting this boilerplate into man pages, then don't provide texinfo docs, so they get the same man page via info.
The full documentation for fubar is maintained as a Texinfo manual. If the info and fubar programs are properly installed at your site, the command info fubar should give you access to the complete manual.
Amazingly the BSDs and OpenSolaris seem to be sticking with manpages. Maybe GNU should finally give up on texinfo? Please?
C++0x update
The troublesome
swap() overloads are still in the latest C++0x draft, so
I've added them to libstdc++. The
std::shared_ptr
on GCC's trunk is now complete,
except for the constructor from std::nullptr_t
which isn't available yet in GCC.
My next goal is to extend result_of
to meet the
C++0x requirements. The TR1 requirements allow result_of to
fail if it can't determine the result of a function
invocation, but C++0x requires it to do the Right Thing,
using magic if necessary. With decltype
and
variadic templates in GCC,
it's pretty easy. I've seen The Future, and it kicks ass.
adulau says an OS is useless without Git. Even if I ignore the existence of non-developers, I can think of some more important tools. adulau's own recipe for updating screen is useless without make and a compiler and he could download a tarball of the screen sources instead of using git. Am I alone in not being sexually aroused by Git?
If DrDeniro isn't spammer scum I don't know who is. A huge <div> obscures the button to flag the account as spam and on Internet Explorer also redirects to a pharmacy site. This seems like a mod_virgule bug that should be addressed.
Click here to flag the account as spam.
robogato, I've emailed you the problematic markup in the "Notes" section.
Uh oh.
pa.swap(pb)
still works even without the new swap()
overloads, and is still equivalent to pa = pb
.
Stay tuned for more live C++0x.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!