The C data type "char" (as either "char" or "car") doesn't seem to be so clearly divided by national boundaries.
In both cases I read it exactly as it's written, not as a shortened form of the word it originated from.
The C data type "char" (as either "char" or "car") doesn't seem to be so clearly divided by national boundaries.
In both cases I read it exactly as it's written, not as a shortened form of the word it originated from.
In a reply to one of his recent articles, lkcl said:
here's the secret, that you and everyone else who reads what i write, don't seem to be in on...
I take objection to "everyone else," lkcl was one of the first certs I gave on this site, and the only reason I removed the Master cert I'd given him was because of his certification of mentifex, not because I don't value his work. My feeble trust-juice will have no influence on either of their ratings, but that's not the point.
There's been some more brouhaha about KDE4 recently (well, recently when I first saved this draft diary entry) including Linus Torvalds announcing he's switched to gnome. Some commenters have said that people who aren't happy on the bleeding edge should not be using distros such as Fedora. I agree, but my problems with KDE4 are not that there are unstable, unreliable parts, which I expect from new releases. It's that basic functionality was removed, resulting in stupid regressions that still aren't fixed in KDE 4.2, despite claims that it is "a compelling offering for the majority of end users." The problems for Fedora users are exacerbated by the response to any KDE-related bug reported to Fedora bugzilla: "not our problem, report it upstream." (update: and in some cases claiming it's fixed without even bothering to check.)
Despite its flaws, I really do like my eee pc. Being able to hack on code while walking down the street is brillant.
Recently I did some hacking on std::thread for libstdc++, as I needed to make a small fix before I could finish std::bind and I got carried away making improvements to std::thread.
I also suggested a few patches for Boost to fix some problems in the (fscking excellent) new thread library. Unfortunately whether I report bugs to the boost list or to trac, they seem to fall between the cracks. The list has far too much traffic for me to follow, so I don't bother chasing them up.
I've realised that one of the things I like about smart pointers in C++ is what they tell you about the programmer. Smart programmers use smart pointers. The other group use raw, unsafe pointers.
I wonder why jcsteele also needs to syndicate his blog to selerius. I wonder why anyone needs to syndicate their twittering to advogato.
Spammer accounts seem to be on the rise again in the last few days. It's a testament to the incompetence and stupidity of most spammers and SEO twunts that they can't even enter the same thing in two fields e.g. creating an account as "ajax09" but putting the real name as "ajax 222" ... if they weren't such idiots it might be a lot harder to identify accounts created by spammers.
The Emperor's New Desktop
I still think KDE4 sucks enormous quantities of shit.
Xerces-C++ is a conspiracy to make C++ look bad
Xerces-C++ sucks even more shit. Writing a C++ API with unclear memory-ownership semantics was pretty dumb a decade ago. It just makes you look idiotic in 2009. Dynamic memory management in C++ is a solved problem. Requiring explicit calls to release memory at scope exit can be attributed to stupidity, but not providing an RAII type to restore some sanity to the API begins to look like malice.
diary of micro hacks
I had hoped to update GCC's std::tr1::bind
and
friends to also serve as std::bind
(after
breaking them and having to back out my changes a few weeks
ago) but I didn't get any hacking done over twixtmas, except
some small changes to the GCC manual and some largely
pointless changes
to the non-functional std::tr1::regex
code.
Last week I updated the RPM spec files I wrote for STLsoft & Pantheios RPMs for Fedora. They're closer to the Fedora packaging guidelines now, and all my STLsoft patches have been accepted upstream which makes life simpler.
If I get time I might release some C++ container templates I
wrote recently, worm::map<Key,T>
,
worm::set<T>
and non-unique counterparts,
which provide a similar
interface to the standard associative containers
but implemented using sorted std::vector
s. This
means they
have random-access iterators and better memory locality, but
sacrifice the nice iterator invalidation rules of the
standard associative containers. I need to remove some sharp
edges and figure out whether I can keep the same interface w.r.t
const
and ordering invariants, or whether I need to
make them immutable to
prevent self-inflicted gunshot wounds to the foot.
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.
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!