Trying to define a simple sc_fixed type in Visual Studio 2017:
#include <systemc.h>
#include <sysc/datatypes/fx/sc_fixed.h> # just in case
....
typedef sc_fixed<16, 4> fixed_type;
....
This typedef line resulted an error:
E0864: sc_fixed is not a template
Had no idea why this error popped, even included sysc/datatypes/fx/sc_fixed.h. Why does it say "not a template"?
From INSTALL file shipped with SystemC
SystemC 2.3 includes a fixed-point package that is always built.
When compiling your applications with fixed-point types, you still have
to use compiler flag -DSC_INCLUDE_FX. Note that compile times increase
significantly when using this compiler flag.
Using your code as an example
#include <systemc.h>
#include <sysc/datatypes/fx/sc_fixed.h>
#include <iostream>
typedef sc_dt::sc_fixed<16, 4> fixed_type;
int sc_main(int, char**){
fixed_type ft(1.25);
std::cout << "ft = " << ft << '\n';
return 0;
}
Gives me the output
ft = 1.25
As a caveat it is best to check the docs for your particular version of SystemC as I believe this #define may have been removed in 2.3.3 (I am using 2.3.2) I am not certain.
I got the same type of error message in one of my C++ programs - E0864 - unique_ptr is not a template
I managed to get rid of this error in my program by adding this to my header file.
#include <memory>
My program managed to compile okay using this. I am using Visual Studio 2019 if that helps.
Related
I am trying to write a C function to be executed within PostgreSQL, something that will be declared like
CREATE OR REPLACE FUNCTION ...
RETURNS ... AS 'my_c_function' LANGUAGE C;
I followed the documentation and wrote a code containing stuff like PGFUNCTION_INFO_V1(func); or PG_GETARG_VARCHAR(0);. The problem is Eclipse keeps telling me these cannot be resolved. Here are the libraries I included:
#include <libpq-fe.h>
#include <postgres.h>
#include <fmgr.h>
#include <funcapi.h>
#include <executor/executor.h>
#include <string.h>
Should I include something else ? What am I missing ?
Your index may be out of date. Try rebuilding your index from the project menu.
Project > C/C++ Index > Rebuild
Additionally, make sure your included path is specified in your project settings if there is an issue including <postgres.h>.
It's part of a series of functions that retrieve IP & Mac addresses from the phone.
strcpy(temp, (char *)ether_ntoa((const struct ether_addr *)LLADDR(sdl)));
EDIT: No equivalent function needed, there were just a few missing headers.
EDIT: Added cast to LLADDR(sdl)
As I read it, the error message isn't claiming that the function is missing, only that you don't include its declaration. (I don't know that it exists, only that the message has a different complaint.)
In case it helps, man ether_ntoa tells me:
#include <sys/types.h>
#include <sys/socket.h>
#include <net/ethernet.h>
I included following header file and source code compiled successfully:
#import <arpa/inet.h>
I have tested a bit of assembler on Linux using the AT&T syntax. One thing that struck me was that the book I was reading was written from a 32-bit standpoint. Thus, all sizes would have to be changed to the correct 64-bit versions for me. Or I could (which I did) assemble the code using the --32 flag for as and the -melf_i386 flag for ld when linking. I have also adapted some of the code and to run on Windows under Cygwin.
But that got me thinking. Is there a way to do ifdef like checks in assembler to do one thing if I'm on Windows and another under Linux and also handle 32 vs 64 bit that way? For example to have a .globl _start under Linux and a .globl _main under Windows.
Or is this handled by checking before assembling and having different source files to assemble based on the result of the checks?
I.e. foo_linux.s and foo_windows.s
If so, how do you overcome that fact that you will not know which .s files you will use, and thus have to include, when you are creating your program?
For example, say that we have a socket_linux.s and a socket_windows.s. They both present an identical interface but do the OS specific work associated to sockets. But when I work with the sockets in my program I will not know if I need the Windows or Linux version included. So I would be kinda screwed :)
So how is this handled in Assembler? In C++ for example I could include my socket.h and socket.cpp and wrap all the Linux and Windows specific code in #ifdef statements.
If you use GCC to compile your files and name them .S (with uppercase S) or .sx, it will pass them through the preprocessor before invoking the assembler.
From the docs:
file.s
Assembler code.
file.S
file.sx
Assembler code which must be preprocessed.
You can add -v to the command line to see how the various sub-processes are invoked.
in MASM (.asm), you can use ifdef, ifndef and the likes, as:
ifdef X64
endif
When writing for different platforms you can define some macro for loading target specific files:
FILE target.h
#if defined(__arm__)
#define target "arm"
#elif defined(__x86_64__)
#if defined(_WIN64)
#define target "win64"
#else
#define target "linux64" // all non-Win share the same calling convention
#endif
#else
// 32bit defs
#endif
Then you can include target specific files with the macro, two string literals successively get one single literal:
#include "target.h"
#include "target_specific_code_" target ".h"
It includes one of these files:
target_specific_code_arm.h
target_specific_code_win64.h
target_specific_code_linux64.h
...
EDIT:
Like this, you can also define target specific assembler instructions for later use in inline assembly:
#ifdef ...
#define ASM_PP_LOAD_WORD "movi "
#else
#define ASM_PP_LOAD_WORD "mov "
#endif
or as macro
#ifdef ...
// when using intel assembler there is a different
// order of parameters
#define ASM_PP_LOAD_WORD(a, b) "movi " #b ", " #a
#else
#define ASM_PP_LOAD_WORD(a, b) "mov " #a ", " #b
#endif
I am trying to compile an 32 bit application. I am aware of problems with it but that is why its being compiled on 64 bit version.
I am hanging at this problem.
Application uses lots of sql stuff.
In sqltypes.h file: (provided by MDAC)
#ifdef _WIN64
typedef INT64 SQLLEN;
typedef UINT64 SQLULEN;
typedef UINT64 SQLSETPOSIROW;
#else
#define SQLLEN SQLINTEGER
#define SQLULEN SQLUINTEGER
#define SQLSETPOSIROW SQLUSMALLINT
#endif
//For Backward compatibility
#ifdef WIN32
typedef SQLULEN SQLROWCOUNT;
typedef SQLULEN SQLROWSETSIZE;
typedef SQLULEN SQLTRANSID;
typedef SQLLEN SQLROWOFFSET;
#endif
For some reason when its compiled on 32 bit platform it works great
But when I try building it on 64 it goes berserk.
Error 61 error C2146: syntax error : missing ';' before identifier 'SQLLEN' ..\external\microsoft sdk\include\sqltypes.h 50
It does not recognize INT64, UINT64.
Is there something I need to enable so it will work under 64 build process?
Missing some #include or #define?
Any help would be great
Thanks
It turned out the problem was that somehow BaseTsd.h was not included (can't believe this is possible)
but as short fix I just included BaseTsd.h manually... i will comment on this answer if i find better solution
Use
#include <windows.h>
It contains BaseTsd.h and other relevant Windows-specific definitions.
I'm working on converting a Linux project of mine to compile on Windows using MinGW. It compiles and runs just fine on Linux, but when I attempt to compile it with MinGW it bombs out with the following error message:
camera.h:11: error: declaration does not declare anything
camera.h:12: error: declaration does not declare anything
I'm kind of baffled why this is happening, because
I'm using the same version of g++ (4.4) on both Linux and Windows (via MinGW).
The contents of camera.h is absurdly simple.
Here's the code. It's choking on lines 11 and 12 where float near; and float far; are defined.
#include "Vector.h"
#ifndef _CAMERA_H_
#define _CAMERA_H_
class Camera{
public:
Vector eye;
Vector lookAt;
float fov;
float near;
float far;
};
#endif
Thanks for your help.
EDIT: Thanks both Dirk and mingos, that was exactly the problem!
Edit If you happen to include windef.h (either directly or indirectly), you will find
#define FAR
#define far
#define NEAR
#define near
there. I think, that this is the culprit.
Try
#undef near
#undef far
before your class definition.
Try giving them different names, like
float my_near;
float my_far;
I recall Borland using "near" and "far" as keywords (my 1992 Turbo C had these, back in MS-DOS era). Dunno if this is the case with gcc, but you can always try that.
In <windef.h>, you'll find on the following lines:
#define NEAR
#define near
Simple answer: you can't #undef them because they're a part of the Windows headers (_WINDEF_H will still be defined even if you #undef those definitions, so it won't be re-included if you try to #include <windef.h> again, not to mention the fact that if you #undef _WINDEF_H before using #include <windef.h> after your class definition, you'll end up with duplicate definitions for things like RECT, LONG, PROC and more), so the only other solution is to change your variable names.