1

I am a newbie in C/C++, just in case :) I have cloned an older protocol stack solution written in C with one main class in C++ imported it into VS (Visual C++ 2017 v 15.9.5 targeting Windows SDK 10.0.17134.0) it compiled correctly and working.

Now made a C++ solution (windows console application) created a folder lib copy pasted all those .h and .c files into lib added the path to additional include directories and also in linker additional library directories.

Building the Solution throwing tones of errors. the one I am trying to fix now is:

One of the header files contains type definitions 

typedef uint8_t U8;
#ifndef BOOL
typedef U8 BOOL;
#endif

but this is conflicting with minwindef.h from windows kit. though I #include types.h getting C2371 'BOOL': redefinition; different basic types in the whole solution, I want to use this definition of BOOL and all other ones defined in this header.

How should I solve the issue? Or in General in case of using C codes in C++ projects what settings and MACRO (e.g. extern "C" in methods) should I follow

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
Amir-Mousavi
  • 4,273
  • 12
  • 70
  • 123
  • 1
    I would remove the `typedef U8 BOOL` definition. The `#ifndef` macro doesn't protect against typedef. – Jean-François Fabre Jan 09 '19 at 14:35
  • 5
    As a newbie in *both* C and C++, you should take to take to heart right now an important lesson: C and C++ are ***different languages***. There is no "C/C++". Random code written in either language cannot be assumed to have the same semantics in the other, and may not even compile in the other. Writing code that has the same semantics in both languages is tricky. – John Bollinger Jan 09 '19 at 14:36
  • @Jean-FrançoisFabre I don't think it's intended to. It's adding a new type alias in the case that a macro hasn't already done that job. Unfortunately some other type alias has also already done that job in this case. – Lightness Races in Orbit Jan 09 '19 at 14:37
  • 3
    This seems to be more about compat between your old library and Windows's headers, than it is about C or C++ in particular. – Lightness Races in Orbit Jan 09 '19 at 14:38
  • Remove that whole code and replace it with `#include ` and `#include `. Done. – Lundin Jan 09 '19 at 14:45
  • 1
    You say you have "cloned an ***older*** protocol stack solution" (emphasis mine). Is it possible to get a *newer* version of that library, that have fixed Windows compatibility? Or perhaps find some other library that works on Windows? – Some programmer dude Jan 09 '19 at 14:45
  • @Someprogrammerdude bad usage of adj. :) and old (a legacy stack) which I am going to make a plugin and use that stack as the core. there is only one version of that – Amir-Mousavi Jan 09 '19 at 14:49

1 Answers1

5

I don't know anything about the library you're trying to work with, because you did not tell us what it is. But I can make some guesses:

  1. The code did not used to interface with Windows code at all;
  2. By creating a Windows C++ application you have added Windows dependencies;
  3. The Windows dependencies (well-known for poisoning the namespace with short names like BOOL) are conflicting with the library's code (which is doing the same thing with its BOOL macro, when defined, and its BOOL type alias, otherwise).

This isn't really to do with C vs C++ or anything like this, and there's no general fix you can make. You can either try to get rid of the Windows dependency (do you need that header for your task?) or you can patch your library not to touch BOOL (after making sure that Windows's BOOL is what you need it to be).

And use this as a good lesson not to pollute namespaces!

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
  • Thanks a lot, for the answer, I saw your comment in another answer which writer deleted it :( – Amir-Mousavi Jan 09 '19 at 14:52
  • That project is an old protocol stack implementing deferent layers of an standard (namely J1939 standard) no I want to use that stack and create plugin for a more modern tool. – Amir-Mousavi Jan 09 '19 at 14:53