Templates and name lookup with `stdio.h` functions - c++

I'm trying to build the PCL library in a 32 bit Windows 7 with MinGW. When building the outofcore module I got several error messages about _fseeki64:
error: there are no arguments to '_fseeki64' that depend on a template parameter, so a declaration of '_fseeki64' must be available
In the octree_disk_container.h file, there is a
#ifndef WIN32
#define _fseeki64 fseeko
#endif
I have tested(generating an #error) and WIN32 is defined at the moment of processing the file. _fseeki64 seems to be available for the compiler as this little test program compiles:
#include "stdio.h"
int main(int argc, char** argv) {
FILE* f = fopen("C:/a.txt","r");
if(!f) printf("NOPE");
int seekret = _fseeki64(f,4,SEEK_SET);
(void)seekret;
return 0;
}
If I define _fseeki64 as fseeko64 the errors disappear and the module compiles, but I'm not sure if the behaviour will be the same with fseeko as was intended to be with fseeki.
So, what can I do in order to use _fseeki64 in this context? Maybe declaring a new base class, putting the #define in there and then calling it like Base<T>::_fseeki64? (got the idea from here)
What are your thoughts?

So the problem seems to be that your MinGW system does #define WIN32, yet _fseeki64 is a Microsoft-ism, not a POSIX thing that MinGW knows about. I think you should use the POSIX behavior on MinGW, which means using fseeko.

Related

_VACPP_HASH_FUNCTION_CHECK error while trying to compile C++ code with LANGLVL(*EXTENDED0X) at IBMi7.4

I'm trying to compile simple C++ program with unordered_map using LANGLVL(*EXTENDED0X) at pub400.com:
#include <stdlib.h>
#include <stdio.h>
#include <unordered_map>
#include <string>
int main(int argc, char* argv[])
{
printf("Hello world!\n");
std::tr1::unordered_map<long long, std::string> test;
test[123] = std::string("123");
return 0;
}
but it fails with the message:
"QSYSINC/STD(xhashtbl)", line 530.50: CZP0274(30) The name lookup for "_VACPP_HASH_FUNCTION_CHECK" did not find a declaration.
"QSYSINC/STD(xhashtbl)", line 530.50: CZP1226(0) Declarations for non-dependent names are resolved in the template definition.
"QSYSINC/STD(xhashtbl)", line 530.50: CZP1227(0) "_VACPP_HASH_FUNCTION_CHECK" does not depend on a template argument. The compilation failed.
Googled the same problem with IBM AIX C++ compiler back in 2016 (it was a compiler bug).
DSPJOB OUTPUT(*PRINT) show that pub400.com runs latest IBM i 7.4.
Is it compiler bug or I'm missing something? I have the same problem with IBM i 7.3 TR9 at my office.
Any ideas?
Thanks.
It's an internal error in their /QIBM/include/std/xhashtbl, you could actually fix it yourself, you just need to exclude the whole _HashFunctionCheck function via ifdef check regarding _VACPP_HASH_FUNCTION_CHECK. They fixed it on zOS (or AIX?) a long time ago but forgot to port it for IBM i.

Can't resolve namespace member 'thread'

I wanted to practice with standard C++ threads instead of UNIX ones, but soon encountered a problem, whenever I write std::thread CLion underlines it with red and says Can't resolve namespace member 'thread'. I checked my CMake file it's set for C++11. I reinstalled the latest version of MinGW (6.3.0) and ticked a box with G++ compiler. I have been told by my friend that he uses Cygwin and everything works. But is it still possible to make it work with MinGW?
#include <iostream>
#include <thread>
#define BUFFER_SIZE 3
#define PROD_NUM 3
#define CONS_NUM 2
void produce(){
//production
}
void consume(){
//consumption
}
int main() {
std::cout << "Hello, World!" << std::endl;
int i,j;
std::thread producer(produce);
std::thread consumer (consume);
return 0;
}
The code itself has literally nothing
EDIT
in thread library there is
#pragma GCC system_header
#if __cplusplus < 201103L
# include <bits/c++0x_warning.h>
#else
#include <chrono>
#include <functional>
#include <memory>
#include <cerrno>
#include <bits/functexcept.h>
#include <bits/functional_hash.h>
#include <bits/gthr.h>
#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1)
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
/**
* #defgroup threads Threads
* #ingroup concurrency
*
* Classes for thread support.
* #{
*/
/// thread
class thread
{
public:
// Abstract base class for types that wrap arbitrary functors to be
// invoked in the new thread of execution.
struct _State
{
virtual ~_State();
virtual void _M_run() = 0;
};
can you make sure if the library is available in the CLion toolchain? For example Cygwin does have the include.
CLion shows things red when it can't link codes with the library.
It is possibly a host environment variable error. Make sure your CMakeLists.txt is working and your environment variables, standard library linkage is correct as well as your compiler setup.
Compiler version and and standard libraries compatible. (e.g. you are using a cross-compiler (RasPi, Android) but environment vars shows host library etc. will make it fail)
Check this relevant post, it may help.
C++11 std::threads vs posix threads
Ok, so I finally solved the problem. I installed Cygwin and in CLion Settings I manually linked C/C++ compilers (for some reason CLion was unable to auto-detect them). Cleared all and re-indexed the project. Now it shows no errors and code compiles.
Regarding MinGW, I read on cplusplus.com some posts regarding the issue but they were about previous versions of MinGW and it was said that they finally fixed it, however I tell: No, they didn't. Here there is a nice repository and its README file suggests that thread of win32 rely on gthreads, however i found gthread file in my libraries everything seemed ok... so still need to investigate the issue. Write your ideas and experience here if you know more.
As for now solution is Cygwin, use it instead of MinGW.
P.S. Thanks #KillzoneKid for links

Link a MSVC compiled DLL in a MinGW-built project

Given two C++ projects:
a Win32 C++ project compiled as a x86 DLL under Visual Studio 2015
a Qt GUI application using Desktop Qt 5.5.1 MinGW 32 bit Kit.
What I'm trying to do is to link the first one in the second one. A MWE follows.
DLL header file: libxspectra.h
namespace XSpectra
{
#define LIBXSPECTRA_EXPORTS // already defined into Project Properties
#ifdef LIBXSPECTRA_EXPORTS
#define LIBXSPECTRA_API __declspec(dllexport)
#else
#define LIBXSPECTRA_API __declspec(dllimport)
#endif
LIBXSPECTRA_API int fnlibxspectra(void);
LIBXSPECTRA_API int gnara(void) { return 7; };
int foo() { return 1; };
int bar();
}
DLL source file: libxspectra.cpp
#include "libxspectra.h"
namespace XSpectra
{
LIBXSPECTRA_API int fnlibxspectra(void)
{
return 42;
}
int bar()
{
return 6;
}
}
Qt source file: main.cpp
#include "libxspectra.h"
int main(int argc, char *argv[])
{
XSpectra::foo();
XSpectra::bar();
XSpectra::gnara();
XSpectra::fnlibxspectra();
return 0;
}
Qt application build log
error: undefined reference to XSpectra::bar()
error: undefined reference to _imp___ZN8XSpectra13fnlibxspectraEv
While foo() and gnara() links correctly.
A few notes
I know the problem is not strictly Qt-related, but it's a matter of different compilation toolchains, a field where I'm a real novice. I'm actually asking for advices on this way.
If I comment the #define LIBXSPECTRA_EXPORTS, Visual Studio's Intellisense still marks it as defined, dll compiles, but the behaviour of external application's build process changes. The following error arises:
error: function 'int XSpectra::gnara()' definition is marked dllimport
You can only link MSVC compiled C DLLs with MinGW, and only on 32-bit Windows. The MinGW linker can link directly to the DLL (if the functions are properly exported and not only available through an import library) or the usual import library. See here and here for how to generate a MinGW import library from a DLL.
You'll do it just like with MSVC (compile the dll with the functions marked dllexport, and compile the code using the dll with the functions marked dllimport, or use a .def file or something). Remember you need to export C functions, which means they need to be marked extern "C".
I would strongly suggest though, making the code compatible with MinGW, and just compile everything with that. Or use the MSVC version of Qt.

Trying to study shine MPEG Layer-III encoder - getting "redeclaration of C++ built-in type 'bool'"

Greetings.
I am studying the way mpeg layer-III encoding works for an upcoming project. I downloaded the shine encoder as it is said to be the simpliest of all. http://www.mp3-tech.org/programmer/sources/shine.zip is the link.
I successfully compiled them in a standalone project but i need to be using them in a QT project.
I made new blank console project in QT
and added as existing all the files that previously successfully compiled for me (files from shine.zip).
This is my main.cpp:
#include <QtCore/QCoreApplication>
#include "main.h"
int main(int argc, char *argv[])
{
// QCoreApplication a(argc, argv);
// return a.exec();
mainc(argc,argv);
}
This is main.h:
#ifndef MAIN_H
#define MAIN_H
#include "main.c"
#endif // MAIN_H
everything else is untouched (i mean, without those two files it compiled successfully and worked)
I am now getting error at this part
#ifndef bool
typedef unsigned char bool; <--- "redeclaration of C++ built-in type 'bool'"
#endif
Before there was no error here. From what i understand a presence of one cpp file makes all the code compile as c++ and the shine code is c, not c++... Does it mean i cannot use c code in a project that uses QT classes QCoreApplication?
You can mix C and C++ code in the same project, but you need to compile the C code with a C compiler. Rather than trying to include main.c from a C++ file, compile the C code separately, and declare any C functions you need to call from C++ as extern "C", for example
extern "C" int mainc(int argc, char *argv[]);
Never include the implemenation file in the header file. The
#include "main.c"
is wrong. It would lead to an include recursion, if the #ifdef MAIN_H would not protect.
In your example QCoreAppplication is included twice what leads to the error message.

getting the right compiler for C++

I am trying to learn c++ but most of the tutorials and books I have read or looked up teaches you this...
(I am assuming like most tutorials, they are teaching in the beginning to code either in win32 console or CLR console. In either case the following does not work.)
#include <iostream>
int main( )
{
std::cout << "Hello World\n";
return (0);
}
The IDE that i have is Visual C++ 2008 Express edition and they accept code like this
#include "stdafx.h"
int _tmain(int argc, _TCHAR* argv[])
{
return 0;
}
Or like this
#include "stdafx.h"
using namespace System;
int main(array<System::String ^> ^args)
{
Console::WriteLine(L"Hello World");
return 0;
}
Honestly I do not no the difference in none of these and I am not sure if I should just download a older compiler so that it works. If someone can tell me what the difference in these are and where to go from there. That will help tremendously. Thanks
[Edited]
I am trying to do a simple hello world. But I get the error "system can not find path specified." I have screenshot that shows what the error looks like. It also is saying that my project is out of date when I clearly save the file before I build it. Apparently it can not find the executable file. I went to the debug fold and did not see any .exe file.
[Edited]
Ok, now When I try to build the project I get the following errors
1>------ Rebuild All started: Project: test, Configuration: Debug Win32 ------
1>Deleting intermediate and output files for project 'test', configuration 'Debug|Win32'
1>Compiling...
1>stdafx.cpp
1>Compiling...
1>test.cpp
1>c:\users\numerical25\desktop\test\test\test.cpp(1) : warning C4627: '#include <iostream>': skipped when looking for precompiled header use
1> Add directive to 'stdafx.h' or rebuild precompiled header
1>c:\users\numerical25\desktop\test\test\test.cpp(6) : error C2653: 'std' : is not a class or namespace name
1>c:\users\numerical25\desktop\test\test\test.cpp(6) : error C2065: 'cout' : undeclared identifier
1>Build log was saved at "file://c:\Users\numerical25\Desktop\test\test\Debug\BuildLog.htm"
1>test - 2 error(s), 1 warning(s)
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
Here is the code I used
#include <iostream>
#include "stdafx.h"
int main( )
{
std::cout << "Hello World\n";
return (0);
}
Note: I tried using it with and without the #include "stdafx.h" When I tried it without the #include "stdafx.h", it said I might be missing it.
Not sure what you're asking. The first two examples you gave are valid C++ programs that should (will) compile with VC++. The third example is a C++/CLI program that must be compiled with the /CLR compiler switch (this is called Managed C++).
EDIT: Adding more specific information (from a comment below):
The first two examples are standard (native) C++ (albeit, the second example has MS-proprietary macros). They compile to native code. The third is C++/CLI (a "managed" extension to C++). It compiles to managed (.NET) code. Only the third snippet interacts with the .NET framework in any way. All three are absolutely buildable and runnable using the appropriate projects in VS 2008 (no command line necessary)!
Based on your latest update, it looks like you have probably modified some project properties and changed some paths. The app is building, but when you try to run it via VS (you should do this with <Ctrl>+F5, by the way), the executable cannot be found (there are several ways you could have messed this up by changing or playing with various settings).
Please note the difference between building and running. Building is the process of compiling and linking your source code. Running is launching the resulting executable. You seem to be confused between these (judging from your complaints about the "...out of date" dialog box). It is normal to get the "...out of date" dialog box if you try to run without rebuilding after you have made a change to the project (even if that change is saved). Just make sure you click "yes." You need to build the project before you can run it.
My recommendation is to completely delete your project and solution. Create a new empty project, as suggested elsewhere in this now-very-heavyweight thread, and don't modify any project settings. If this doesn't work, something is seriously wrong!
ANOTHER EDIT: Just for completion, since this question kept changing:
As others have already pointed out, your ultimate problem with the first snippet is the use of precompiled headers (PCH). PCH are turned on by default in new VS C++ projects. Their purpose is to speed compilation when many implementation files include the same set of headers -- preventing the compiler from having to parse the header files for each compilation unit.
You have three options:
(Recommended) Disable PCH -- Project Properties --> Configuration Properties --> C/C++ --> Precompiled Headers: Set Create/Use Precompiled Header to Not Using Precompiled Headers. (You don't need to do anything with the "stdafx.h" file or the #include for it.)
Place your commonly used #includes in "stdafx.h". In your case, you would put #include <iostream> in "stdafx.h".
Place your #includes after `#include "stdafx.h". Microsoft requires that the "stdafx.h" be the first included file in a compilation unit.
A minor point, which I don't see elsewhere in the answers: When using precompiled headers, such as your stdafx.h, you need to include them first. Change it to:
#include "stdafx.h"
#include <iostream>
and that should fix the errors about it.
Alternatively, it may be easier to simply switch off precompiled headers: Project > Properties > Configuration Properties > C/C++ > Precompiled Headers > Switch first option to "Not using precompiled headers". They can be useful for big projects but will just be awkward and annoying while you're learning, since they have extra rules (like this "must be included first") which aren't requirements of standard C++ .
The "difference" is pedantic. The latter are just Microsoft-specific entry points.
As you are learning C++, I recommend you use a compiler, and preferably an operating system that lets you focus on C++, and not the platform. For this I recommend g++, on an Linux distribution such as Ubuntu.
Try this tutorial, there are many others that are similar that quickly let you overcome being tied to the tools, and focus on C++.
int main();
int main(int argc, char* argv[]);
These are standard C++.
int _tmain(int argc, _TCHAR* argv[]);
int wmain(int argc, wchar_t* argv[]);
These are Windows-specific to handle Unicode arguments. See What is the difference between _tmain() and main() in C++?.
int main(array<System::String^>^ args);
This is not C++. This is C++/CLI.
For best portability, always use the first form.
Also,
int main(int argc, char** argv, char** envp);
This is a usually seen POSIX extension. Windows supports this form of main too. The envp means (pointer to) environment variables.
int main(int argc, char** argv, char** envp, char** apple);
This is for Mac only, obviously.
void main();
And this is wrong (nonstandard, some compilers (e.g. gcc) will reject it).
Visual C++ Express will compile the first example just fine.
However, you need to ensure the proper project settings:
Create an "Empty Project"
"Add a new item..." to the project via the "Project" menu. Select C++ (.cpp) file.
Copy/Paste code into new file
Press F5 to compile and run.
When "Project is out of date" dialog appears, press "Yes" (build the project)
The steps above ensure VC++ Express does not treat your file as a special Win32/Windows console application.
EDIT: added additional step 5 to prevent "Can't find..." dialog.
I managed to get the same dialog by making sure the exe file does not exist, and answering "No" to the build dialog. With a clean, empty project the exe file does not exist yet. It must be built first. If you answer "no" don't build it, VC++ dutifully does not build the exe and later complains about not being able to find it when it tries to run it later.
As STingRaySC pointed out, all three of your examples will compile in VC2008 express; it's just that examples 2 and 3 are what VC2008 Express will load up initially when you create a project (one of the examples is for Managed C++, as STingRaySC mentioned).
You can just delete the code in your second example (the C++ Win32 Console Application project) and paste in the more standard hello world program from your first example. It should compile and run just fine in VC2008 Express - it did for me.
I. Precompiled header
#include "stdafx.h"
is some kind of tricky stuff that comes your way.
If you create a project VC will normally switch on precompiled header.
This means that one header stdafx.h is created which is compiled only once.
This is done to speed up compile time in big environments. If you start C++
it will confuse you.
If you use stdafx.h it has to be the first header in the cpp file.
II. Unicode (Utf16)
int _tmain(int argc, _TCHAR* argv[])
Microsoft uses UTF16 to implement unicode strings.
This means you get two versions of main.
int main(int argc, char* argv[])
int main(int argc, wchar_t* argv[])
This is also confusing if you start.
To simply start you can use whatever editor you want.
Create the file.
Open a Visdual studio 2008 command prompt
cl main.cpp
main.exe
and you will see Hello World using code from books.
Afterwards try to understand some of the settings of VC.
But you should always use an empty project.
Else you have to care about stdafx, UNICODE, ...
_tmain with the _TCHAR argv is the way the C runtime allows you to handle unicode. If _UNICODE is defined, then _tmain will expand to wmain, and the _TCHAR argument will be of type wchar_t. If _UNICODE is not defined, then _tmain will expand to main, which will be the ANSI standard.
Therefore, so long as _UNICODE is not defined, the second snippet you posted is compliant with the standard.
Lots of waxing lyrical and some misinformation for you sift through already, but I suggest following wonsungi's advice. But to clarify his advice:
File->New->Project
Select Project Type "Win32", then Template "Win32 Console Project"
Give the project a name and location
OK
Select "Application Settings"
Check "Empty Project"
In the "Solution Explorer", right click the "Sources" folder, then Add->New Item
Type the name of the file, in the "name" box using a .cpp extension (you can ignore the templates if you wish).
Enter your code in the new file.
Woot!! I figured it out!!! Below is my original code
#include <iostream>
int main( )
{
std::cout << "Hello World\n";
return (0);
}
It was missing the header file #include "stdafx.h" . So I had to include it in there so I added it like this
#include <iostream>
#include "stdafx.h"
int main( )
{
std::cout << "Hello World\n";
return (0);
}
I was still getting an error like what you see in my edited question at the bottom. So What I did is I took #include and added it in my header file and then it worked!!!!!
Even the the books and alot of tutorials show to add #include to the actual cpp, for some reason in express edition I had to add it to header for it to work. I don't know WHY but it's a solution and now it works.
Download and install Dev-C++ on your system. If the code doesn't work on Visual C++, try it out on Dev-C++ (which uses the GCC compiler). You may get the same results or a different error message. Whenever you get an error message you don't understand, do a Internet search for the error message.