Trouble with variable types (void *)

[Olaf Martens]

Greetings!

Here's another problem that appeared recently:

I have the following function call:

l_test->Compress(&"filename.dat",l_buf);

l_test is a pointer-to-packer that I want to check here.
The file name thing should be plain enough, whereas l_buf is declared as a
char * and contains a pointer to a data buffer.
Compress() itself has the following declaration:

Compressor_Base : public Base
{
..
..
..
public:
void Compress(const char *p_name, void *p_buf);
}
p_name takes the name of a file that is to contain the (compressed) data, and
p_buf is a pointer-to-buffer, whose contents are to be compressed (the buffer
can contain any data type, and is of no relevance for the function).

l_test is declared as type Compressor_Base and should therefore correctly
reference the function Compress().

But when compiling the source I get the following error:
main.cpp:609: error: no matching function for call to `Compressor_Null::
Compress(const char (*)[31], char*&)'
compressor_base.h:88: error: candidates are: void
Compressor_Base::Compress(const char*, void*)

So, what's going on here?
I don't remember having included a *reference* to l_buf, and even prepending
(void *) to l_buf won't help.
Did I miss some peculiarities of void pointers, or is this some sort of bug?
Switching p_buf from void * to, for example, char * doesn't help, either - the
same type of error appears every time I attempt a compilation.

Any help would be appreciated.

--
Olaf Martens Linux User #246244 http://counter.li.org/
Hugo-Luther-Str. 8 E-Mail: ol*********@arcor.de
38118 Braunschweig Fon: [phone]
"Who the heck is General Failure, and why is he reading my harddisk?"

[Victor Bazarov]

"Olaf Martens" <ol*********@arcor.de> wrote in message
news:40***********************@newsread4.arcor-online.net...

Here's another problem that appeared recently:

I have the following function call:

l_test->Compress(&"filename.dat",l_buf);
What's the "&" for?

l_test is a pointer-to-packer that I want to check here.
The file name thing should be plain enough, whereas l_buf is declared as a
char * and contains a pointer to a data buffer.
Compress() itself has the following declaration:

Compressor_Base : public Base
{
.
.
.
public:
void Compress(const char *p_name, void *p_buf);
}
p_name takes the name of a file that is to contain the (compressed) data, and p_buf is a pointer-to-buffer, whose contents are to be compressed (the buffer can contain any data type, and is of no relevance for the function).

l_test is declared as type Compressor_Base and should therefore correctly
reference the function Compress().

But when compiling the source I get the following error:
main.cpp:609: error: no matching function for call to `Compressor_Null::
Compress(const char (*)[31], char*&)'
compressor_base.h:88: error: candidates are: void
Compressor_Base::Compress(const char*, void*)

So, what's going on here?
Drop the ampersand.
I don't remember having included a *reference* to l_buf, and even prepending (void *) to l_buf won't help.
Did I miss some peculiarities of void pointers, or is this some sort of bug?

No, you missed the fact that you're not supposed to take addresses
of literals.
Switching p_buf from void * to, for example, char * doesn't help, either - the same type of error appears every time I attempt a compilation.

V

[Rolf Magnus]

Olaf Martens wrote:

Greetings!

Here's another problem that appeared recently:

I have the following function call:

l_test->Compress(&"filename.dat",l_buf);
The first argument is of type const char (*)[13] (i.e. poiner to
constant array of 13 chars) here. I guess you actually meant:

l_test->Compress("filename.dat",l_buf);

where the argument is of type const char[13], which will be implicitly
converted to a pointer to its first element, i.e. a const char*.
l_test is a pointer-to-packer that I want to check here.
The file name thing should be plain enough, whereas l_buf is declared
as a char * and contains a pointer to a data buffer.
Compress() itself has the following declaration:

Compressor_Base : public Base
{
.
.
.
public:
void Compress(const char *p_name, void *p_buf);
}
p_name takes the name of a file that is to contain the (compressed)
data, and p_buf is a pointer-to-buffer, whose contents are to be
compressed (the buffer can contain any data type, and is of no
relevance for the function).

l_test is declared as type Compressor_Base and should therefore
correctly reference the function Compress().

But when compiling the source I get the following error:
main.cpp:609: error: no matching function for call to
`Compressor_Null:: Compress(const char (*)[31], char*&)'
compressor_base.h:88: error: candidates are: void
Compressor_Base::Compress(const char*, void*)

So, what's going on here?
I don't remember having included a *reference* to l_buf, and even
prepending (void *) to l_buf won't help.
The problem is not the second argument, but the first one. You are
providing a pointer to an array of char with 31 elements, while the
function wants a pointer to char.
Did I miss some peculiarities of void pointers, or is this some sort
of bug? Switching p_buf from void * to, for example, char * doesn't
help, either - the same type of error appears every time I attempt a
compilation.

Any help would be appreciated.

--
Tell a man that there are 400 billion stars and he'll believe you.
Tell him a bench has wet paint and he has to touch it.

[Olaf Martens]

Victor Bazarov schrieb:

"Olaf Martens" <ol*********@arcor.de> wrote in message
news:40***********************@newsread4.arcor-online.net...

Here's another problem that appeared recently:

I have the following function call:

l_test->Compress(&"filename.dat",l_buf);

What's the "&" for?

g++ would complain otherwise and issue a warning: Deprecated conversion of
string constants to char *...
[snip]

Drop the ampersand. It's the second parameter that bothers me, not the first!

[snip]

No, you missed the fact that you're not supposed to take addresses
of literals.

Oh, really? And why does g++ complain when omitting the &, then?
So, once more: The problem is *NOT* the string literal, but the second
parameter (l_buf)!!!

--
Olaf Martens Linux User #246244 http://counter.li.org/
Hugo-Luther-Str. 8 E-Mail: ol*********@arcor.de
38118 Braunschweig Fon: [phone]
"Who the heck is General Failure, and why is he reading my harddisk?"

[Rolf Magnus]

Olaf Martens wrote:

Victor Bazarov schrieb:

"Olaf Martens" <ol*********@arcor.de> wrote in message
news:40***********************@newsread4.arcor-online.net...

Here's another problem that appeared recently:

I have the following function call:

l_test->Compress(&"filename.dat",l_buf);

What's the "&" for?

g++ would complain otherwise and issue a warning: Deprecated
conversion of string constants to char *...

That doesn't make sense if your function really takes a const char* as
first parameter. That warning should only occur if the first parameter
is a pointer to non-const char.
[snip]

Drop the ampersand. It's the second parameter that bothers me, not the first!

Why?
[snip]

No, you missed the fact that you're not supposed to take addresses
of literals. Oh, really? And why does g++ complain when omitting the &, then?

That hasn't anything to do with it. It complains because a string
literal cannot be modified and therefore is of type array of const
char. And for that reason, you are not supposed to convert it to a
pointer to non-const char.
So, once more: The problem is *NOT* the string literal, but the second
parameter (l_buf)!!!

What makes you believe that?

[John Harrison]

"Olaf Martens" <ol*********@arcor.de> wrote in message
news:40***********************@newsread2.arcor-online.net...

Victor Bazarov schrieb:

"Olaf Martens" <ol*********@arcor.de> wrote in message
news:40***********************@newsread4.arcor-online.net...

Here's another problem that appeared recently:

I have the following function call:

l_test->Compress(&"filename.dat",l_buf);

What's the "&" for?

g++ would complain otherwise and issue a warning: Deprecated conversion of
string constants to char *...

[snip]

Drop the ampersand.

It's the second parameter that bothers me, not the first!

[snip]

No, you missed the fact that you're not supposed to take addresses
of literals.

Oh, really? And why does g++ complain when omitting the &, then?
So, once more: The problem is *NOT* the string literal, but the second
parameter (l_buf)!!!

Look at you error message, its the first parameter that is wrong.

See the bit that says const char (*)[31], that's what &"filename.dat" is
(apart from the length which is wrong). It does not match const char*.

Remove the &, and ignore the spurious and erroneous warning.

And try to believe knowledgeable people when they give you advice. If you
don't believe this, try removing the second parameter ENTIRELY (both from
the call and the function), and you will still get the same error message.

John

[David Harmon]

On Sun, 1 Feb 2004 20:14:24 -0000 in comp.lang.c++, "John Harrison"
<jo*************@hotmail.com> was alleged to have written:

Remove the &, and ignore the spurious and erroneous warning.

No, fix the cause of the perfectly legitimate warning.

If the function is going to modify the argument, it is a mistake to pass
it a quoted literal.

If it is not going to modify the argument, the argument should be const
which will get rid of the warning.

[John Harrison]

"David Harmon" <so****@netcom.com> wrote in message
news:40***************@news.west.earthlink.net...

On Sun, 1 Feb 2004 20:14:24 -0000 in comp.lang.c++, "John Harrison"
<jo*************@hotmail.com> was alleged to have written:

Remove the &, and ignore the spurious and erroneous warning.

No, fix the cause of the perfectly legitimate warning.

If the function is going to modify the argument, it is a mistake to pass
it a quoted literal.

If it is not going to modify the argument, the argument should be const
which will get rid of the warning.

In his quoted code the argument is const char*, therefore either he's
wrongly quoting his code or the compiler is wrong.

I do seem to recall one particular version of gcc getting this wrong, but I
might be imagining that.

John

[David Harmon]

On Sun, 1 Feb 2004 22:25:49 -0000 in comp.lang.c++, "John Harrison"
<jo*************@hotmail.com> was alleged to have written:

"David Harmon" <so****@netcom.com> wrote in message
news:40***************@news.west.earthlink.net. ..

On Sun, 1 Feb 2004 20:14:24 -0000 in comp.lang.c++, "John Harrison"
<jo*************@hotmail.com> was alleged to have written:

>Remove the &, and ignore the spurious and erroneous warning.

No, fix the cause of the perfectly legitimate warning.

In his quoted code the argument is const char*,

Oh well then, the warning is bogus.