An observation of the self-reflection kind: the vast majority of problem-threads i start to write - i never actually post. It goes like this:
* problem
* need to explain the problem
* need to understand the problem to explain it
* ...
* never mind

Oh, well. Since the problem i had was a simple one (the facepalm moment arrived in the middle of writing the very first sentence for me) - i post it anyway for readers benefit as i have encountered variations of this problem fairly often.

------------
Why cannot "Foo *" be implicitly converted to "Foo const *&"?

silly-made-up-simplified-mini-example:

void skipX(char const *&at) {
    if(*at == 'X') at++;
}
void snafu() {
    char *buf = ...
    skipX(buf); // not OK! -> 'Conversion loses qualifiers' !
    ...
}

Noticed the problem? Did you think about it? Did thinking about it help?
------------

Oh, well - my take on the pesky WHY:

Foo const constFoo;
Foo *ptrFoo;
Foo const **snafu = &ptrFoo; // *** ie. if it WOULD allow this then the following can legally happen ***
*snafu = &constFoo; // exact type match: both sides are "Foo const *"
*ptrFoo = @#$%! // completely valid to do whatever with the Foo ... ow, crap - it just happens to be constFoo.

Aliasing issue, lovely. Compiler errs on the side of caution (validity of the code is the goal, not some version of const correctness in and of itself ... but that is a rant for another time deep in the complicated waters of language design not relevant to C++ with its constraints of history).

... and this kind of mind-wrappers are why one generally tries to avoid low level C++.

C++, the sledgehammer of const correctness.

------------
So, what C++ thread did you not make lately?

It's always faster to copy POD types than reference them.

I think you meant to say 'primitive types', not 'POD types'. POD types include structs made out of other POD types, which can include as many fields as you want. As a POD gets bigger, copying gets slower.

I have a rubber duck at my desk for this exact reason. If I'm stuck, I explain the problem to the duck and half the time figure out the solution in the process.

I have a rubber duck at my desk for this exact reason. If I'm stuck, I explain the problem to the duck and half the time figure out the solution in the process.

Hehe, sweet. ... also, pics or didn't happen

Either do:

void skipX(char const* const& at)

or

void skipX(char*& at)

However, I advise you not to take a reference to a pointer because that's one extra memory read you'll be doing (i.e. it's slower). It's always faster to copy raw types than reference them.

void skipX(char* at)

Erm, ...
* the first one will cause a syntax error given the function body.
* the second: the first step in fixing const-correctness is not to just abandon it all.
* the example code was marked with: "silly-made-up-simplified-mini-example" ... it is obviously meant to expose a language quirk and not to micro optimize a nonsense algorithm.
* any compiler worth anything will inline that silly snippet -> hence there wont be any redirections and nothing to optimize.
* obviously, my real case uses pass by reference because it needs to affect the variable used in function parameter.
* no-one cares about micro optimizations without a bloody good reason.
edit:
* oh, and the third one changes what the function does - likely emitting an warning that something got fucked up.

Cheers.

Well excuse me princess, I'm sorry for helping you.

X_X, seems my "Cheers" was not good enough to soften my criticism. Sorry about that.

As the OP indicated - there was no problem in need of help with. Either way OP does not contain enough information to even give any meaningful help (Actual case: since the function was correct and used the correct qualifiers - then my usage of the function needed to be fixed. As it happens, the pointer going in was meant to be "Foo const *").