Same name headers with different content in Ubuntu system - c++

I have two c++ projects in my Eclipse that uses same function gettimeofday(). First project compiles fine while other reports error
error: ‘gettimeofday’ was not declared in this scope
By presing F3 on function name I found that in first project case I was navigated to /usr/include/86_64-linux-gnu/sys/time.h. Second project also has #include <time.h>, but F3 navigates to sys/time.h, which has no ‘gettimeofday’ function.
Why same #include <time.h> navigates to different folders?
Why Linux has two same names includes at all?
Why both includes #include <time.h> are different?
UPD
I found that /sys/timeb.h has inclusion #include <time.h> which navigates to /usr/lib/time.h. I was expecting /sys/timeb.h will include /sys/timeb.h. How Eclipse and GCC decides to go/usr/lib/time.hor/sys/time.h` ?
Why "professional" /sys/timeb.h leaves ambiguity in code just by making #include <time.h> instead defining more exact path? I suppose <time.h> might point to both - <sys/time.h> and C <time.h>

On Linux, the function int gettimeofday(struct timeval *tv, struct timezone *tz); is defined in #include <sys/time.h>. When using it in your code you should include it exactly like that. The other time.h is the standard C library that contains time structures and functions such as time_t and mktime. When you are using this file in a C++ program you should include it as #include <ctime> which should help you avoid this type of error in the future.

Related

Where is '__find_end' present in Visual Studio 19 C/C++ Development Tools?

I was trying to compile an old code, and received the following error:
error G1A4676F8: no member named '__find_end' in namespace 'std'
I searched online and found it is defined in stl_algo.h, which I couldn't find in my Windows system. Also, the documentations were of libstdc++4 and earlier.
The code compiles fine on https://godbolt.org/ with all MSVC versions.
The include statements are:
#include <string>
#include <algorithm>
#include <iterator>
#include <ostream>
#include <iomanip>
#include <stdexcept>
The compiler shows an alternative as find_end defined in algorithm but I am not sure if __find_end has the same functionality as find_end.
So, my question is, is __find_end deprecated?
If not, where can I find it's declaration in Windows?
If yes, what are my alternatives? Is find_end a perfect substitute for __find_end?

Why does changing the order of including psapi.h gives compilation erros?(Indentifier BOOL is undefined)

I am using Visual Studio Community 2017 to code c++. When I run the following code everything works fine.
#include "pch.h"
#include<Windows.h>
#include<Psapi.h>
#include <iostream>
#include <conio.h>
int main()
{
std::cout << "Really!! How do you do it?";
_getch();
}
But if I change the order of #includes by including psapi.h before Windows.h, compiler goes badass and throws 198 errors at me, which surprisingly(maybe only to me) includes Identifier "BOOL" is undefined.
Why is this happening?
Since Psapi.h's include tree is trivial, I'm going to exemplify. Everything relies on VStudio 2015 (Community) (v14.0.25431.01 Update 3) and Windows Kits 8.1 (? funny, because v10 is there too) files (with default env vars and preprocessor definitions):
BOOL is defined in minwindef.h (#157: typedef int BOOL;)
Psapi.h only includes one file (#27: #include <winapifamily.h>)
winapifamily.h doesn't include any other file
So, when reaching Psapi.h (#87: BOOL WINAPI EnumProcesses (...), the compiler doesn't know anything about BOOL, so it complains.
Windows.h includes minwindef.h (indirectly, via windef.h), and that's why it works when you include it before Psapi.h.
Personally, I think it's a bug in Psapi.h, since it's not self contained, but there might be a good reason (that I'm not aware of) for that. Anyway, if this is indeed a bug, it wouldn't be MS's 1st one :)
#include <Windows.h>
#include <WinSock2.h>
// main present just for rigorosity's sake
int main() {
return 0;
}
to answer the question, I know this is DATED but the issues persist today. You need the following:
#include "stdafx.h"
#include <stdbool.h>
#include <Windows.h>
#include <stdlib.h>
#include <psapi.h>
After stdlib.h was included, the errors were gone.

Linux: Conflicts using inotify with fcntl

I'm having a strange linking issue after I included inotify in my program to monitor changes to a filesystem. The project includes <fcntl.h> in many other source files. However, when I include <sys/inotify.h> in the source file which is doing the directory monitoring, I get this error:
/usr/include/fcntl.h:30:1: error: expected initializer before ‘extern’
__BEGIN_DECLS
My project uses CMake, although that doesn't seem to be relevant for finding inotify. It IS finding the inotify declarations to my knowledge, since when I included , it threw an error that inotify_init() and the other functions I used were not defined. Inotify includes fcntl and is partially built on top of some of the functionality there, so my first thought was that it's importing a different version of fcntl than the rest of my program.
In ObjectManager.h:
#ifndef MANAGE_OBJECT_H
#define MANAGE_OBJECT_H
#include "config.h"
//includes all lua headers under extern 'C'
#include <lua.hpp>
#include <list>
#include <unordered_map>
#include <pthread.h>
class ObjectManager //...
The only thing that changed was ObjectManager.cc, with the addition of sys/notify and the implementation of the watcher (not included because this is a linking issue):
#include "config.h"
#include "ObjectManager.h"
#include "Control.h"
#ifdef OBJECT_MANAGER_ENABLED
#include <string.h>
#include <stdio.h>
#include <dirent.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <vector>
#include <unistd.h>
#include <fstream>
#include <sys/inotify.h>
//... inotify implementation
Where Control.h declares #include <fcntl.h>.
This is the closest issue I found, related to some problems in the implementation of different fcntl headers for userspace usage. https://lkml.org/lkml/2008/9/16/98
The same problem occurs on Linux 2.6 running on Centos 6 and Linux 4.0 running on Centos 7.
Any ideas on what is causing this error and how to successfully include inotify?
Resolution: A function definition lacked a semicolon at the END of ObjectManager.h right before a #endif, and the resulting GCC error that propagated through the next includes in a complicated manner, resulting in a strange preprocessor error in fcntl.h.

In what header file the function `_tcscpy_s` is declared?

Visual Studio 2015. I am reading the "Windows via C\C++" book and try to use its code samples. Author writes that the "safe" functions of string have the _s suffix and are declared in the StrSafe.h header. This header are to be the last in the list of includes. In my code I included such headers:
#include <iostream>
#include <exception>
#include <string>
#include <Windows.h>
#include <strsafe.h>
But I have a problem:
// IDE doesn't see the _tcscpy_s function
errno_t result = _tcscpy_s(szBuffer, _countof(szBuffer), TEXT("0123456789"));
I looked for info about the _tcscpy_s function, but I didn't see info about its header file (I expected that it is strsafe.h).
How can I fix it?
Just like any other "Generic Text" string function version, the _tcscpy_s() function is declared in TCHAR.H (as mentioned in the documentation).
Add #include <tchar.h> to your code.

SHGetSpecialFolderPath() Not Declared in This Scope

I am not able to compile my program SHGetSpecialFolderPath() not being declared in the scope of the program, while the correct header is being included (according to MSDN)
http://msdn.microsoft.com/en-us/library/bb762204(v=vs.85).aspx
Here are the headers for my project:
#include <iostream>
#include <iostream>
#include <windows.h>
#include <algorithm>
#include <vector>
#include <fstream>
#include <direct.h>
#include <shlobj.h>
With error:
C:\Users\user\Documents\getAppData\main.cpp|31|error: `SHGetSpecialFolderPath' was not declared in this scope
with shlobj.h being the header with the declaration in it.
Any ideas why the compiler is throwing the error? Here is how I am calling the function:
char appData[MAX_PATH];
SHGetSpecialFolderPath( NULL
,appData
,CSIDL_LOCAL_APPDATA
,1 );
cout << appData << endl;
Thanks!
From the MSDN page:
The Microsoft Internet Explorer 4.0
Desktop Update must be installed for
this function to be available.
With Windows 2000, this function is
superseded by ShGetFolderPath. You can
use this function on earlier systems
by including the redistributable DLL,
ShFolder.dll.
Perhaps this is your problem?