Implicit declaration of function 'ether_ntoa' is invalid in C99 - objective-c

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>

Related

typedef an sc_fixed but got template error

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.

How to call StorageFile.OpenReadAsync in C++/winrt?

In my continuing efforts to load a collection of .svg files in C++/winrt I'm encountering a mysterious link error. I'd like to try using CanvasSvgDocument.ReadAsync(resourceCreator, filestream). To get there it is first necessary to get the stream from the StorageFile, and this would appear to be the way to do it (nextFile, a StorageFile, is already loaded in this example). This is of course within a method defined as an IAsyncAction. I'll list the #includes and namespaces from the top of the file.
#include "winrt/Windows.ApplicationModel.h"
#include "winrt/Windows.Storage.h"
#include "winrt/Windows.Storage.Streams.h"
#include "winrt/Windows.Foundation.Collections.h"
#include "winrt/Windows.Storage.Search.h"
#include "winrt/Windows.UI.Core.h"
#include "winrt/Windows.UI.Xaml.Media.h"
#include "pch.h"
using namespace winrt;
using namespace Windows::Foundation;
using namespace Windows::Foundation::Collections;
using namespace Windows::Storage;
using namespace Windows::Storage::Provider;
using namespace Windows::Storage::Search;
using namespace Windows::Storage::Streams;
Here is the problematic call:
IRandomAccessStreamWithContentType fileStream = co_await nextFile.OpenReadAsync();
That produces a link error that I'll put in below. It doesn't matter whether or not I try the fully qualified name of the fileStream result:
winrt::Windows::Storage::Streams::IRandomAccessStreamWithContentType fileStream = co_await nextFile.OpenReadAsync();
either way I get this link error:
Error LNK2019 unresolved external symbol "public: struct
winrt::Windows::Foundation::IAsyncOperation
__thiscall winrt::impl::consume_Windows_Storage_Streams_IRandomAccessStreamReference::OpenReadAsync(void)const "
(?OpenReadAsync#?$consume_Windows_Storage_Streams_IRandomAccessStreamReference#UIStorageFile#Storage#Windows#winrt###impl#winrt##QBE?AU?$IAsyncOperation#UIRandomAccessStreamWithContentType#Streams#Storage#Windows#winrt###Foundation#Windows#3#XZ)
referenced in function "public: struct
winrt::Windows::Foundation::IAsyncAction __thiscall
AppEngine::ResourceManager::LoadSvgResources$_ResumeCoro$2(struct
winrt::Microsoft::Graphics::Canvas::UI::Xaml::CanvasControl)"
(?LoadSvgResources$_ResumeCoro$2#ResourceManager#AppEngine##QAE?AUIAsyncAction#Foundation#Windows#winrt##UCanvasControl#Xaml#UI#Canvas#Graphics#Microsoft#6##Z)
I've also tried using auto as the result type, no luck. What is the right way to obtain a stream using OpenReadAsync() in C++/winrt?
You are apparently compiling with precompiled headers enabled (hinted to by the #include "pch.h" directive). When doing so, the header used to generate the precompiled header must be included on the first non-empty, non-comment line in the compilation unit consuming it.
The /Yu (Use Precompiled Header File) documentation has the relevant information:
The compiler treats all code occurring before the .h file as precompiled. It skips to just beyond the #include directive associated with the .h file, uses the code contained in the .pch file, and then compiles all code after filename.
In other words, all your includes preceding the #include "pch.h" directive are ignored. Since C++/WinRT is a header-only library, this will eventually result in linker errors.
To fix the issue
Move the #include "pch.h" directive to the very top of the file, or
Replace the #include directive with the /FI (Name Forced Include File) compiler option on the relevant compilation units, or
Disable use of precompiled headers.

Use of undeclared identifier 'GL_BGRA_EXT' error in iOS 8(Xcode 6)?

I am using Unity 4.3.4f1. and untill right now when i was making Builds for iOS they were working fine.
I just upgraded my Xcode from v5.1 to v6. now the same code is giving me error like the following
/.Project DIR/Classes/Unity/CMVideoSampling.mm:51:122: Use of undeclared identifier 'GL_BGRA_EXT'
can somebody please help me?
thanks
You should try replacing gl.h with glext.h in include statements of the file which contains this error.
Replace the following:-
#include <OpenGLES/ES2/gl.h>
with this :-
#include <OpenGLES/ES2/glext.h>
your include statements should look like this:-
Previously:-
#include "CMVideoSampling.h"
#include "CVTextureCache.h"
#include "GLESHelper.h"
#include <OpenGLES/ES2/gl.h>
#include <AVFoundation/AVFoundation.h>
After replacing:-
#include "CMVideoSampling.h"
#include "CVTextureCache.h"
#include "GLESHelper.h"
#include <OpenGLES/ES2/glext.h>//replace glext.h here
#include <AVFoundation/AVFoundation.h>

How to change #import "..." into #import <...> in Objective C

I have this problem with a library. I want to add it to my Objective C (iOS) project, but their docs don't say how to do that. I simply copied it over. Now their main file has this:
#include <LIB/Class1.h>
#include <LIB/Class2.h>
...
It didn't work for me, so I changed each <> to "":
#include "LIB/Class1.h"
#include "LIB/Class2.h"
...
And with this syntax everything works fine, I can use the lib. I guess it's not a good practice, though. How should I add a library to a project so that it works without this modification?
In Xcode Build Setting, Header Search Paths (HEADER_SEARCH_PATHS) affects search path of #include <foo.h>, User Header Search Paths (USER_HEADER_SEARCH_PATHS) affects search path of #include "foo.h".
So, set HEADER_SEARCH_PATHS for your library's header path, #include <LIB/Class1.h> should be work.
Also, Always Search User Paths (ALWAYS_SEARCH_USER_PATHS) setting can change behavior for search path #include <foo.h>. When ALWAYS_SEARCH_USER_PATHS is YES, #include <LIB/Class1.h> should be work as well.
Add path to the libpath... "" relative from source and <>relative from the external libs
ALWAYS_SEARCH_USER_PATHS is deprecated now & should be avoided. Explicitly set
USER_HEADER_SEARCH_PATHS for ".h" include syntax header files.
SYSTEM_HEADER_SEARCH_PATHS for <.h> include syntax header files.
HEADER_SEARCH_PATHS: for fallback of USER_HEADER_SEARCH_PATHS for compilers which don't support separate include paths.
https://help.apple.com/xcode/mac/current/#/itcaec37c2a6?sub=deved642222b

MinGW and "declaration does not declare anything"

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.