WIP Library and C++ [FIXED]

IoT Modules Development tools
1

Hello:

I’m developing a new application with M2M , this application it’s beeing written in C++, I create the application with the wizard, adding support for WIP and C-GPS. Now I’m at the point of adding functionality with the WIP library.

Does this library supports C++ interface ???

If I put the call to ‘wip_netInit()’ in a C++ file (.cpp) I’m getting this:

If I put the code in a .c file everything seems to be OK.

Does anyone tried WIP with CPP modules ???

Thanks,

2

Fixed:

Include “wip.h” this way:

extern "C"
{
	#include "wip.h"
}

For more information folow the link http://www.parashift.com/c+±faq-lite/mixing-c-and-cpp.html#faq-32.2

3

Hi again:

Another trick for using WIP in C++. The include file ‘wip_file.h’, contains this declaration:

typedef struct wip_fileInfo_t {
  u16 size;
  u16 nentries;
  union wip_fileInfo_entry_t {
    u32 u32;
    s32 s32;
    ascii *ascii;
    void  *ptr;
  } entries[1];
} wip_fileInfo_t;

As you can see some fields of the union ‘wip_fileInfo_entry_t’ are named as data types (u32, s32, ascii), this is not a best practice at all (don’t do it in your programs). This is causing this errors:

Ugly, for the moment I have changed the structure to:

typedef struct wip_fileInfo_t {
  u16 size;
  u16 nentries;
  union wip_fileInfo_entry_t {
    u32 _u32;
    s32 _s32;
    ascii *_ascii;
    void  *ptr;
  } entries[1];
} wip_fileInfo_t;

… and see what happens.

4

Isn’t it?
Why not?

Why not?

Edit (12 Nov):
I had totally missed the point of what txavinavarro was saying! :blush:

Having seen it, I totally agree that it is shockingly bad practice :!: :open_mouth:
See: viewtopic.php?f=78&t=4201&p=16652#p16652

5

Note that this is a general issue of mixing C++ and C - it is nothing specifically to do with Wavecom, or Open-AT, or WIP…

6

GCC/C++ does not allow using atomic type as variable, such as int int. I think Wavecom WIP team should know GCC/G++ constrains and list as a known issues: WIP is not supported in G++. Of course, Wavecom had better rename variable u32 to a meaning name. In my personal view, u32 u32 should be renamed to u32 dog, ascii ascii to ascii cat, etc. to make more sense.

7

Sorry - I get you now!

Yes, I totally agree - having a variable with the same name as the name of a type is absolutely ridiculous! :angry:

What on earth were they thinking :question: :exclamation: :unamused:

8

:wink: maybe you assume too much? :mrgreen:

9

Note that user code should not define symbol names with a leading underscore - that is reserved for compiler writers!

Cross-reference: viewtopic.php?f=108&t=5304&hilit=leading+underscore+underscores&p=21756#p21756