at the beginning I have:
#include <sstream>
#include <iostream>
#include <stdio.h>
#include <iomanip>
#include <string>
#define _WIN32_WINNT 0x500 //tells that this is win 2000 or higher, without GetConsoleWindow would not work
#include <windows.h>
using namespace std;
int main() {
PCONSOLE_FONT_INFO lpConsoleCurrentFont;
GetCurrentConsoleFont(GetStdHandle(STD_OUTPUT_HANDLE), false, lpConsoleCurrentFont);
return 0;
}
And undocumented function SetConsoleFont works, but GetCurrentConsoleFont fails at compilation saying that it was not declared in this scope.
-- edit: changed to self sustained code.
GetCurrentConsoleFont is exported on NT4+ at least, the MinGW headers must be wrong.
Try adding this code after your #include's:
#ifdef __cplusplus
extern "C" {
#endif
BOOL WINAPI GetCurrentConsoleFont(HANDLE hConsoleOutput,BOOL bMaximumWindow,PCONSOLE_FONT_INFO lpConsoleCurrentFont);
#ifdef __cplusplus
}
#endif
Your code is also wrong, it should be:
CONSOLE_FONT_INFO ConsoleFontInfo;
GetCurrentConsoleFont(GetStdHandle(STD_OUTPUT_HANDLE), false, &ConsoleFontInfo);
(Any time you see PSOMETYPE as a parameter you usually allocate a SOMETYPE struct on the stack and pass a pointer to this struct as the parameter)
Hans comment above is correct. GetCurrentConsoleFont is not defined in wincon.h. Add the following lines to wincon.h to get this functionality:
BOOL WINAPI GetCurrentConsoleFont(HANDLE, BOOL, PCONSOLE_FONT_INFO );
COORD WINAPI GetConsoleFontSize( HANDLE, DWORD );
GetConsoleFontSize was also missing.
Related
I have a small snipped of code, which just produces a function to get the current directory for either Windows or Linux platform:
#include <stdio.h> /* defines FILENAME_MAX */
#include <string>
#ifdef WINDOWS
#include <direct.h>
#define GetCurrentDir _getcwd
#else
#include <unistd.h>
#define GetCurrentDir getcwd
#endif
std::string getcwd(){
char mCurrentPath[FILENAME_MAX];
GetCurrentDir(mCurrentPath, sizeof(mCurrentPath));
return *(new std::string (mCurrentPath));
}
This is all great and working; however, I'd like to make the getcwd() function inside the namespace, fUtils, hence I did this:
#include <stdio.h> /* defines FILENAME_MAX */
#include <string>
#ifdef WINDOWS
#include <direct.h>
#define GetCurrentDir _getcwd
#else
#include <unistd.h>
#define GetCurrentDir getcwd
#endif
namespace fUtils{
std::string getcwd(){
char mCurrentPath[FILENAME_MAX];
GetCurrentDir(mCurrentPath, sizeof(mCurrentPath));
return *(new std::string (mCurrentPath));
}
}
But this gives an error in VSCode which says:
no matching function for call to 'getcwd'
What mistake am I making in this? If this isn't how I put the function to the namespace fUtils, then how should I put it into the namespace?
Your fUtils::getcwd() function is attempting to call itself when the GetCurrentDir macro is evaluated (to getcwd), and this results in a function that expects no argument but is being given two arguments.
To resolve this, add the global namespace operator (::) in the definitions for GetCurrentDir, as follows:
#ifdef WINDOWS
#include <direct.h>
#define GetCurrentDir ::_getcwd
#else
#include <unistd.h>
#define GetCurrentDir ::getcwd
#endif
Then, in your function body, it is clear to the compiler that your aren't looking for a 'recursive' (and invalid) call.
Use of macros in such context is invitation to problems in future.
Just wrap those functions with own API and all problems will be resolved.
Header file:
#include <string>
namepsace fUtils {
std::string getcwd();
}
Then you can have platform specific cpp files, Windows:
namepsace fUtils {
std::string getcwd() {
char mCurrentPath[FILENAME_MAX];
::_getcwd(mCurrentPath, sizeof(mCurrentPath));
return {mCurrentPath};
}
}
Mac version is obvious.
You also can use this macros inside single cpp file and this way contain them there if you do not what to do larger clean up.
Side notes:
there is boost::filesystem which has such api also use of boost::filesystem::path is quite handy
C++17 introduces std::filesystem, but it is not well supported yet (for example MacOS)
if you wrap this functionality in classes you will open your way for better testing (mocks).
Hi I'm been struggling to get my preprocessor to quit bugging me about this:
So I added _CRT_SECURE_NO_WARNINGS in the C/C++ -> preprocessor -> definitions
But it still said the same, so I defined it below as shown in the code below.
though it didnt work. It is shown in output as an error though and not a warning. Is there anything else I should do?
#include "texture.h"
#include <iostream>
#define _CRT_SECURE_NO_WARNINGS
#include "stb_image.h"
#define STB_IMAGE_IMPLEMENTATION
Texture::Texture(const std::string& fileName)
{
int width, height, numComponents;
unsigned char* data = stbi_load((fileName).c_str(), &width, &height,
&numComponents, 4);
//rest isnt really neccesary i guess
You need to put #define _CRT_SECURE_NO_WARNINGS at the very beginning of the program:
#define _CRT_SECURE_NO_WARNINGS
#include <iostream>
int main()
{
FILE *f = fopen("a", "r");
}
But following compiles with the warning because #define _CRT_SECURE_NO_WARNINGS comes after #include <iostream>:
#include <iostream>
#define _CRT_SECURE_NO_WARNINGS
int main()
{
FILE *f = fopen("a", "r");
}
The same for #pragma warning(disable: 4996), you need to put it at the beginning of the program (or at least before #include <iostream>)
Consider using
#pragma warning(disable: 4996)
instead.
Do not define _CRT_SECURE_NO_WARNINGS or other warning suppressions, it is a workaround that is supposed to be used when upgrading code not yet utilizing security enhancements in CRT. Fix the code that is causing them.
I have a dll and header file. Now I am creating a console application using vs2015. and load this library. But while getting GetProcAddress of function. It is always returning NULL. Here is my code.
Contents of header file (test.h) (This header file is only for your reference)
#ifdef APPLYDLL_EXPORTS
#define APPLYDLL_API __declspec(dllexport)
#else
#ifdef BUILD_EXE
#define APPLYDLL_API
#else
#define APPLYDLL_API __declspec(dllimport)
#endif
#endif
#include <string>
#include <winerror.h>
APPLYDLL_API HRESULT ApplySettings(std::string input);
Contents of console application (cpp file)
#include "stdafx.h"
#include <Windows.h>
#include <string>
using namespace std;
//Define the function prototype
typedef HRESULT(CALLBACK* ApplySettings)(std::string);
int main()
{
HINSTANCE hLib = LoadLibrary(TEXT("ApplyTool.dll"));
if (NULL != hLib)
{
//Get pointer to our function using GetProcAddress:
ApplySettings applySettings = (ApplySettings)GetProcAddress(hLib,"ApplySettings");
DWORD errorcode=GetLastError(); //errorcode 127, Procedure not Found
}
return 0;
}
I don't know, Where I am doing silly mistake.
Someone please help me.
Thanks in adv.
I Agree with CrazyCoder, check the DLL using Dependency Walker with that function name.
and try to change define as like below,
#define APPLYDLL_API __declspec(dllexport)
to
#define APPLYDLL_API extern "C" __declspec( dllexport )
Thanks, Jake.
I'm trying to compile shogun toolbox and I'm getting this fault
C:/shogun-3.0.0/shogun-3.0.0/src/shogun/../shogun/mathematics/Math.h: In static
member function 'static int shogun::CMath::is_finite(double)':
C:/shogun-3.0.0/shogun-3.0.0/src/shogun/../shogun/mathematics/Math.h:1255:20: er
ror: 'ifinite' was not declared in this scope
return ifinite(f);
function itself looks like this.
inline static int is_finite(double)
{
#if defined(isfinite) && !defined(SUNOS)
return ifinite(f);
#else
return finite(f);
#endif
}
I believe similar is described here: http://www.alecjacobson.com/weblog/?p=1768, but I'm not sure as I don't include cmath. Any idea what it can be?
Function is isfinite, not ifinite.
You don't include <cmath> but according to Shogun source here, it does include both <cmath> and <math.h> in the wrong order:
#include <shogun/base/SGObject.h>
#include <shogun/lib/common.h>
#include <cmath> <<<<<<
#include <shogun/mathematics/Math.h>
#include <shogun/mathematics/lapack.h>
#include <shogun/io/SGIO.h>
#include <stdio.h>
#include <stdlib.h>
#include <math.h> <<<<<<
So you are supposed to use std::isfinite.
I just downloaded shogun-3.0.0 from here, and there is no occurrence of the string “ifinite” anywhere in the source. The definition of is_finite in Math.h is:
/// checks whether a float is finite
inline static int is_finite(double f)
{
#if defined(isfinite) && !defined(SUNOS)
return isfinite(f);
#else
return finite(f);
#endif
}
If the errors and source text you entered into the question are correct, perhaps the sources you have were corrupted. You should download the source and try again.
Trying to figure out how to get an application to compile that uses both C and C++ files. Not the entire code, but enough to get the idea:
main.cpp:
#include <windows.h>
#include <stdio.h>
#include <string.h>
#include "one.h"
#include "two.h"
int __stdcall WinMain(HINSTANCE hInst, HINSTANCE hInst2, LPSTR lpCmdLine, int nShowCmd) {
FunctionOne();
FunctionTwo();
}
one.cpp:
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#include <gdiplus.h>
#include <gdiplusflat.h>
using namespace Gdiplus;
using namespace Gdiplus::DllExports;
int FunctionOne() {
}
two.c
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
int FunctionTwo() {
}
The header files contain only definitions for those functions.
Now, if I compile this with a main.cpp, I get an "unresolved external symbol" for FunctionTwo. If I compile this with a main.c, I get the same thing for FunctionOne. Is this even possible, and if so, how would I set up the project to compile properly (Visual Studio 2010)?
It compiles fine if I comment out the alternate function depending on the extension for main.
Thanks!
The problem is two.h, it almost certainly wasn't written to allow a C++ compiler to properly compile the C function prototype. You'll want to take advantage of the predefined __cplusplus macro, like this:
two.h:
#ifdef __cplusplus
extern "C" {
#endif
int FunctionTwo();
// etc...
#ifdef __cplusplus
}
#endif
Lovely macro soup ;) If the header is pre-baked and never saw a C++ compiler before then do this in your .cpp source code file:
#include <windows.h>
#include <stdio.h>
#include <string.h>
#include "one.h"
extern "C" {
#include "two.h"
}
Some programmers name their header files .hpp if they contain C++ declarations and .h if they contain C declarations. That's a pretty good practice I personally favor. So does the Boost team. It didn't otherwise set the world on fire.
C++ does name-mangling to support function overloading while C does not. You will have to mark your function as extern "C" to prevent name mangling.
// main.cpp
extern "C" int FunctionTwo();
.. the rest ..
// two.c
extern "C" int FunctionTwo() {
// stuff
}
See http://www.parashift.com/c++-faq/mixing-c-and-cpp.html for more information on mixing C and C++.