I get error during build in Ubuntu.
And the error is as following:
ISO C++ forbids declaration of `wstring' with no type
In order to solve this problem,I have to define the wstring by myself.
So who knows how to define wstring?
In order to use wstring you have to add #include<string> and, preferrably, use its fully qualified name std::wstring.
UPDATE:
In the case that your compiler, for some reason, does not support std::wstring, you can try with the following typedef (taken directly from bits/string_fwd.h and tweaked to add the missing std::).
typedef std::basic_string<wchar_t> wstring;
Note that this depends on wchar_t being defined, and according to this:
In C++, wchar_t is a distinct fundamental type (and thus it is not defined in nor any other header).
If your compiler doesn't have support for wchar_t there's no (easy) way to define it as far as I know.
Related
So here is the preprocessed output of a struct:
typedef struct RPT_Item
{
wchar_t *fullPath;
RPT_ItemFlags_t itemFlags;
int isComposite;
const void *reserved;
} RPT_Item_t;
Visual Studio complains because wchar_t is not defined, its own cryptic way:
error C2016: C requires that a struct or union has at least one member
I looked at the project files and also at the particular C file where the error appears and I can confirm that "Treat wchar_t as built-in type is set to YES".
If I define the type using a typedef it compiles fine.
I used the preprocessor output so I can exclude that some nasty preprocessor #define trick play the main role.
This project contains many low-level hacks, for example the CRT is not linked (/NODEFAULTLIB).
Most of the code is not written by me, and I'm tasked to remove reference to wchar.h from a public header that uses wchar_t, because VS treats it as a built in type default. (This particular module is built only on Windows.)
I totally ran out of ideas. Is there a compiler option or a pragma that can interfere? Or could it be even a compiler bug?
Microsoft didn't explicitly document this until VS 2013, but the docs for /Zc:wchar_t says
The wchar_t type is not supported when you compile C code.
It seems that including nearly any header from the runtime or from the SDK will typedef wchar_t tounsigned short using the following sequence:
#ifndef _WCHAR_T_DEFINED
typedef unsigned short wchar_t;
#define _WCHAR_T_DEFINED
#endif
you might want to do something similar in your file that uses wchar_t.
Note that when compiling a C++ file, if /Zc:wchar_t is in effect then the compiler pre-defines _WCHAR_T_DEFINED. If /Zc:wchar_t- is in effect it doesn't - so the above snippet should work nicely with C++ as well (for MSVC anyway - I don't know how other compilers might deal with this if you're looking for something portable).
The _WCHAR_T_DEFINED macro is documented:
MSVC Predefined Macros
I have a few logging functions that I commonly use for different Arduino programs. Since I use them so much, I decided to try to make a custom library for them. Unfortunately, the compiler crashes at the header file with the error:
unknown type name 'String'
I'm a bit confused as to why this is happening because I am including the standard Arduino libraries (which I believe should contain the String class) at the top of my header. Here's the whole thing:
#ifndef logging_h
#define logging_h
#include "Arduino.h"
void logEvent(String msg);
void debugOut(String msg);
void errOut(String err);
void document(String parameter, float value);
#endif
I reinstalled the Arduino IDE (1.0.5) so I think I should have the most recent standard library. If anyone has some suggestions I would really appreciate it.
(This answer is based on our discussion in comments.)
The problem was that the source file for your library was named *.c. That caused the compiler to treat it as C code instead of C++, which means it couldn't handle classes/objects (such as String).
Naming the file *.cpp instead lets the compiler treat it correctly as C++ code.
I had same issue yesterday. The code you included in your question should be your .h file, isn't? My question is: is your library written in C or in C++?
I assume you use C code.
You can't import code from in a user C library with the Arduino IDE. The reason is that use C++ code, and it can't be called from your C library.
Solution: rewrite your library in C+, it's not too difficult.
You can find a lot of help on google on how to write library in C++. You can also check my example at https://github.com/romain-viollette/AverageFilter/
best regards,
To avoid multiple includes of a header file, one of my friend suggested the following way
#ifndef _INTERFACEMESSAGE_HPP
#define _INTERFACEMESSAGE_HPP
class CInterfaceMessage
{
/ /Declaration of class goes here
//i.e declaration of member variables and methods
private:
int m_nCount;
CString m_cStrMessage;
public:
CString foo(int);
}
#endif
where _INTERFACEMESSAGE_HPP is just an identifier
but when i declare a class using visual studio 2005 IDE I get a statement as
#pragma once
at the starting of the class definition
when i took the help of msdn to find the purpose of #pragma once
it gave me the following explanation
"Specifies that the file will be included (opened) only once by the compiler when compiling a source code file. "
Someone please tell which is the right approach?, if both are correct then what is the difference? is one approach is better than the other?
gcc has pragma once as deprecated. You should use the standard include guards. All pragma directives are by definition implementation defined. So, if you want portability, don't use them.
Pragmas are compiler-specific, so I'd use #ifndef.
Preprocessor directives are resolved during (actually, before) compilation, so they do not make a difference in runtime except maybe for compile time.
However, you will never notice a difference in compile time from these two alternatives unless you use them several thousand times I guess.
The first approach is the generic approach that works with all compilers and is also the older one around. The #pragma once approach is compiler specific.
This is part of a series of at least two closely related, but distinct questions. I hope I'm doing the right thing by asking them separately.
I'm trying to get my Visual C++ 2008 app to work without the C Runtime Library. It's a Win32 GUI app without MFC or other fancy stuff, just plain Windows API.
So I set Project Properties -> Configuration -> C/C++ -> Advanced -> Omit Default Library Names to Yes (compiler flag /Zl) and rebuilt. Let's pretend I have written a suitable entry point function, which is the subject of my other question.
I get two linker errors; they are probably related. The linker complains about unresolved external symbols __fltused and _memcpy in foobar.obj. Needless to say, I use neither explicitly in my program, but I do use memcpy somewhere in foobar.cpp. (I would have used CopyMemory but that turns out to be #defined to be identical to memcpy...)
(I thought I could get rid of the memcpy problem by using a compiler intrinsic, like #pragma intrinsic(memcpy), but this makes no difference.)
If I look at the preprocessor output (adding /P to the compiler command line), I see no references to either __fltused or _memcpy in foobar.i.
So, my question is: Where do these linker errors come from, and how do I resolve them?
__fltused implies you are using or have at least declared some floats or doubles. The compiler injects this 'useless' symbol to cause a floating support .obj to get loaded from the crt. You can get around this by simply declaring a symbol with the name
#ifdef __cplusplus
extern "C" {
#endif
int _fltused=0; // it should be a single underscore since the double one is the mangled name
#ifdef __cplusplus
}
#endif
WRT _memcpy - memcpy is a __cdecl function, and all cdecl functions get an automatic _ as part of their decoration. so, when you say "__cdecl memcpy" - the compiler & linker go looking for a symbol called '_memcpy'. Intrinsic functions - even explicitly requested - can still be imported if the build settings have debug settings that contra-indicate intrinsics. So you are going to need to implement your own memcpy and related functions at some point anyway.
I recommend setting the "generate assembly listing" (or some such) compiler option for foobar.cpp once, and then inspecting the assembler code. This should really tell you where these symbols are used.
I'm converting the header files of a C library to D modules, and was wondering how I should handle C strings.
Using DMD 1, this works:
void f(char* s); // Definition for C library's function.
But using DMD 2 (which I personally use, but I would like the modules to work for both) strings are const, so to get the same code using the modules to work requires
void f(const(char)* s); // Definition for C library's function.
What should I do? Just use char* and make the 'client' code make the strings mutable somehow? Or modify the type depending on the version of the compiler compiling the code? If the former, what's the best way to make them mutable? I thought .dup would do it, but the compiler wasn't having a bar of it. If the latter, how would I go about doing it? I tried this:
version (D_Version2) {
alias const(char)* charptr;
} else {
alias char* charptr;
}
void f(charptr s);
But alas, the DMD 2 version isn't valid code for DMD 1, and all code in version blocks must be valid code for the compiler compiling the code, even if the code wouldn't be included in the resulting executable. So currently the code compiles in both, but you have to modify the alias first which, as you can imagine, isn't ideal.
You can use the mixin construct to use language-version-specific code that isn't valid in all versions. Example:
static if(version_major<2)
{
alias char* charptr;
}
else
{
mixin("alias const(char)* charptr;");
}
Regarding your actual question, I would suggest doing the same as when interfacing C libraries with C++ - define a type that's const(char)* for D2 and char* for D1, but only use it when appropriate (for example, if a function takes a char* for a buffer to write to, it probably wouldn't be appropriate to name const(char)* something as generic as "charptr"). LPCSTR could work ;)
I didn't understand the "What's the best way to make them mutable" question.
Don't use mixins for this, it's the wrong tool for the job. What you really need is the 'version' statement, you can read about it in the Conditional Compilation page here: http://www.digitalmars.com/d/2.0/version.html
It won't compile / look at code that is for a different version. This allows to build different code for different D versions, or different OS's, different whatever.
Mixins probably works, but it's a heavy tool, doesn't have highlighted code (inside the quotes) and is just overly complicating things. The version statement is perfectly suited for this problem.