I am attempting to generate a message box with unicode characters in it, but the output is not what I am expecting.
What am I doing wrong?
#define UNICODE
#include <windows.h>
#include <stdio.h>
#include <assert.h>
int WINAPI wWinMain(HINSTANCE , HINSTANCE , PWSTR , int )
{
MessageBox(NULL,L"cyrillic АЖ\nchinese 𠃯𠀀",L"top Ж bott 𠃯𠀀",MB_OK | MB_ICONWARNING);
return 0;
}
/*
compiled using
cl /c /Wall test4.cpp
link -out:test4.exe test4.obj user32.lib
*/
Output as run on windows 10
The compiler is Visual Studio 2017 Community Edition
What I was doing wrong was not to use the /utf-8 compiler switch, as pointed out by eryksun.
Save your file as UTF-8 and tell the compiler to use UTF-8 for the source encoding and string literals, e.g. with the /utf-8 command-line option of cl.exe. – eryksun
Related
I have a little problem, I'm writing an assembly function in x64 mode. Every time I have to write a function declaration (Extern "C" ...) in a .cpp source file it is a bit tiresome when the file already has a lot of lines. Is it possible to attach a file with the .asm extension to the project? Attaching .cpp or .h files works fine. The problem occurs when I want to add a .asm file (#include "sample.asm"). The strange thing is that something like this works (#include "sample2.h" or #include "samble3.cpp" ).
Every time I have to write a function declaration in a .cpp source file, but I would like to include the finished file ( #indluce "sample.asm") immediately, without having to declare it each time.
Of course, it uses microsoft visual studio
File source.cpp
#include <iostream>
#include <windows.h>
#include "sample2.h" // it can be...
#include "sample3.cpp" // it can be..
#include "sample.asm" //causes an error
using namespace std;
//extern "C" INT64 sum(INT64 a, INT64 b); it always works
int main()
{
return 0;
}
File sample.asm
.CODE
sum PROC
add rcx, rdx
mov rax, rcx
ret
sum ENDP
END
Errors I get when sample.asm wants to attach. It is E0169- declaration was expected and C2059-
syntax error: "."
Background
crypt has two definitions, from the docs,
One of them uses unistd.h
#define _XOPEN_SOURCE /* See feature_test_macros(7) */
#include <unistd.h>
This is defined as
#ifdef __USE_MISC
extern char *crypt (const char *__key, const char *__salt)
__THROW __nonnull ((1, 2));
#endif
One of them uses GNU crypt.h
#define _GNU_SOURCE /* See feature_test_macros(7) */
#include <crypt.h>
This is defined as
extern char *crypt (const char *__phrase, const char *__salt)
__THROW __nonnull ((1, 2));
Problem
When I compile with the definition in the first example (unistd.h)
#define _XOPEN_SOURCE
#include <unistd.h>
#include <stdio.h>
int main()
{
printf("%s", crypt("foobar", "sa"));
}
I'm getting the error
In function ‘main’:
warning: implicit declaration of function ‘crypt’; did you mean ‘chroot’? [-Wimplicit-function-declaration]
printf("%s", crypt("foobar", "sa"));
^~~~~
chroot
warning: format ‘%s’ expects argument of type ‘char *’, but argument 2 has type ‘int’ [-Wformat=]
printf("%s", crypt("foobar", "sa"));
~^ ~~~~~~~~~~~~~~~~~~~~~
%d
Out of desperation, I've tried adding this.
#define _XOPEN_VERSION 700
#define _POSIX_VERSION 200809L
#define __USE_MISC 1
On Ubuntu Trusty 14.04 I believe this works fine use the unistd.h declaration, which makes all the more confusing.
These are two declarations, not two definitions. The content of the header file has no impact on which definition of a function is included: this is determined by the linker. There is only one definition of the crypt function in the Unix C standard library, it's whatever the symbol crypt points to in libcrypt.a or libcrypt.so (depending on whether you link statically or dynamically).
Since the two declarations are compatible, it doesn't matter which header a program gets its through. It's also fine if both declarations are processed: a program can contain any number of declarations for a function as long as they're compatible. Without going into the exact details (refer to the C language specification), two function declarations are compatible if they have the same return type, the same number of arguments and the same type for each argument. The name of the argument given in a declaration is not significant.
You should ignore unistd.h. That declaration is there for POSIX compatibility but GLIB has removed the definition for crypt when they migrated to libxcrypt to develop those features in isolation of glibc. This means you can still get ABI-compatibility but must link in the crypt. You can read more about that here
Availability in glibc
The crypt (), encrypt (), and setkey () functions are part of the POSIX.1-2008 XSI Options Group for Encryption and are optional. If the interfaces are not available then the symbolic constant _XOPEN_CRYPT is either not defined or defined to -1, and can be checked at runtime with sysconf ().
This may be the case if the downstream distribution has switched from glibc crypt to libxcrypt. When recompiling applications in such distributions the
user must detect if _XOPEN_CRPYT is not available and include crypt.h for the function prototypes; otherwise libxcrypt is a ABI compatible drop-in replacement.
As for why even if you link the definition isn't pulled down with
#define _XOPEN_VERSION 700
#define _POSIX_VERSION 200809L
#define __USE_MISC 1
#define _XOPEN_SOURCE
Well there are a few things that happening there
The only header that matters in unistd.h is __USE_MISC.
unistd.h includes features.h which undefs the __USE_ macros to start with a "clean slate"
The only way to define __USE_MISC is to have defined _GNU_SOURCE.
If you want to pull in the declaration of crypt.h from unistd.h you must define _GNU_SOURCE! Those two examples cited from man page of crypt.h do the same thing and whether you include unistd.h or crypt.h you MUST also define _GNU_SOURCE in contemporary versions of glibc.
So you can either do,
#define _GNU_SOURCE
#include <unistd.h>
Or,
#define _GNU_SOURCE
#include <crypt.h>
But because you must link against crypt (-lcrypt) I would suggest using the declaration in crypt.h for sanity.
I am writing a code using other packages in C languages and some in C++ langauges. So my code, needs to work with C routines, and C++ classes as well. My plan is, to include all the header files in C with extern "C" {} method and use g++ to compile.
So, I copied all the headers in C to a directory and added headers and footers like,
#ifdef __cplusplus
extern "C" {
#endif
//...
#ifdef __cplusplus
}
#endif
However, it still doesn't compile. So I made a mock C program to make it look clear how the problem shows up.
main.C
#include <stdio.h>
#include <A.h> //This is the problematic header file.
int main()
{
struct MMM m; //some struct in A.h
printf("How many times do I have to compile this? %d\n",1000);
return 0;
}
A.h
#ifndef _A_H
#define _A_H
#ifndef ...
#define ... ...
#endif
#include <B.h>
#include <C.h>
#endif
And it gives me the same error messages while compiling the mock program as the ones during compilation of the real code I was working on. And it is about some preprocessor macro functions defined in B.h and C.h. But I want to assure you all these header files are written inside extern "C" {}. Mock program is written in C language only so I was able to check there is no error messages with gcc and it works great.
So what I am wondering is, doesn't the g++ with extern "C" work just as gcc? Or did I miss something? Is there any suggestions to go around this problem?
extern "C" does not turn a C++ compiler into a C compiler. The code still has to be valid C++ code. It cannot use new keywords as identifiers, there is no implicit cast from void * to other pointer types, and so on. extern "C" only affects linkage (basically, how the code interacts with other translation units). It does not change the source language the compiler accepts.
I have spent the day searching for an answer to what should be a simple problem. I am building a c++ program to call a fairly large amount of existing fortran. I started by changing the fortran main to a subroutine and then called it with a simple c++ main. My steps look like:
gfortran -c f1.f90 f2.f90 ......
g++ -c mn.cpp
gfortran -lstdc++ -o prog.exe mn.o f1.o ....
mn.cpp started out looking like the code below, and the above steps do work ok. I get a host of linker errors if I try to link with:
g++ -lgfortran (this never works!)
Next, I tried to instantiate a simple array class (remove the 2 commented lines). This produced linker errors concerning gxx_personality_seh0, vtable, and operator new.I get similar errors if I just create an array of doubles with new (remove comment), and if I remove the call to the fortran program completely (still linking with gfortran). Obviously, -lstdc++ does not bring in all the libraries needed. Which libraries are needed and how can I get it to link them?
I am using Windows 7 with Cygwin. The libraries it links are in ...lib/x86_64-pc-cygwin/4.9.3. I can post the linker output if it would be helpful.
mn.cpp which works (code commented out) is below:
#include <string.h>
#include <stdlib.h>
//#include "array.h"
extern "C" {
void mnf90_(const char*,int);
}
int main(int argc, char* argv[]){
// Array2D A; // first derivative
static const char *feos = "d/fld9x.dat";
int npoint = 20;
// double *xc = new double[npoint];
mnf90_(feos,strlen(feos));
}
I am trying to compile my OpenCL app with the following command in mingw32 :
mingw32-gcc -o plat plat.c
but i recieve this error :
CL/cl.h no such file or directory
I searched many times all over the net and this site but can't find any good answer.
I did every work but it still makes error.
I use AMD Radeon HD 5470 and have installed the latest catalyst Driver and AMD APP SDK 2.8 on win 7
I have installed VS 2012
in my code I use several states with hope to work but .... it still makes the same error
I also used -I & -L in compile command and it still makes error : CL/cl.h no such file or directory
how ever I don't know how could use make file to compile the code
I 'll be so thankful any one whom help me : mehdioraki59#yahoo.com
My system is : dell studio 1558
this is my very very simple testing code :
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#ifdef MAC
#include <OpenCL/cl.h>
#else
#include <C:\Program Files (x86)\AMD APP\include\CL\cl.hpp>
//#include <CL/cl.h> >>>>>>> i manually disabled this line but there is still error
#endif
int main() {
cl_platform_id *platforms;
cl_uint num_platforms;
cl_int i, err, platform_index = -1;
char* ext_data;
size_t ext_size;
err = clGetPlatformIDs(1, NULL, &num_platforms);
if(err < 0) {
perror("Couldn't find any platforms.");
exit(1);
}
free(platforms);
return 0;
}
You need to add -I"C:\Program Files (x86)\AMD APP\include" to your build command to tell mingw32-gcc where to find CL/cl.h. Using this, the line #include should work properly.
I finally found the answer also thank you mr chippies :
how ever your advise helped me more
i used this make file :
PROJ=qwerty_mehdi
CC=mingw32-gcc
CFLAGS=-Wall
LIB=-lOpenCL
ifdef AMDAPPSDKROOT
INC_DIRS="$(AMDAPPSDKROOT)include"
LIB_DIRS="$(AMDAPPSDKROOT)lib\x86"
else
ifdef NVSDKCOMPUTE_ROOT
INC_DIRS="$(NVSDKCOMPUTE_ROOT)\OpenCL\common\inc"
LIB_DIRS="$(NVSDKCOMPUTE_ROOT)\OpenCL\common\lib\Win32"
endif
endif
$(PROJ): qwerty.c
$(CC) $(CFLAGS) -o $# $^ -I$(INC_DIRS) -L$(LIB_DIRS) $(LIB)
and also deleted this line :
#include
and after this the .exe was made successfully
in the lines of make file code the qwerty.c is the codes i explained before .