Expected primary-expression before 'client' with WiFiEspClient client

Hi there,
I use the WiFiEsp library ( #include “WiFiEsp.h” ). Works well enough. But if I try to pass one of its classes between the parentheses of a function, the compiler throws an error.

void a_function_that_displays_the_complete_site()
{
WiFiEspClient client = server.available();
// this works…

display_a_part_of_the_site(WiFiEspClient client);
// gives an error

}

void display_a_part_of_the_site(WiFiEspClient client);
{

}

It looks as if WiFiEspClient is not accepted as a type. And in thirty years of programming I never met the “expected primary-expression…”-error.

Paai

Please post your complete sketch

The easier you make it to read and copy the code the more likely it is that you will get help

Please follow the advice given in the link below when posting code

Dear Bob, the complete sketch comprises six ino-files with 2500 lines. If you really think that is necessary, I will gladly do so. However, I hoped that somebody might have an opinion on the passing of classes as parameters.

Why not create a small but complete example of the problem and post that

maybe because you never made a so stupid error :slight_smile: but it happens to the best

display_a_part_of_the_site(WiFiEspClient client);

btw, I recommend my WiFiEspAT library

When you call your display function, you should pass client, but you don’t need (and may not provide) the type as well.

The compiler is expecting an expression, its seeing a type name. You appear to be trying to pass a declaration as a value, which makes no sense. To the compiler “primary-expression” is the non-terminal in the grammar expected in this context, this is not that rare an error.

You can only pass an instance of WiFiEspClient to a function, not the type itself.

@wildbill & Markt: thanks. Must be old age setting in. I am 73, after all.
Glad that I didn’t have to write an example sketch.

paai

If any of those 30 years of programming was in C or C++, then you probably have been exposed to the standard technique of breaking large projects in to .h / .cpp / .c files. That provides a lot more control and modularity than the “Arduino Way” of using multiple .ino files. When you do that, the IDE simply mashes all the .ino files into one big compilation unit and hands it to the compiler. Really not modular at all. See my Post #5 here.