Is it possible to have XCode 4.6.3 automatically add the methods listed as missing by the yellow "incomplete implementation" warning sign?
If not, is it possible to have XCode automatically complete a method signature from an adopted protocol as I type?
No. You have to implement the method yourself.
Related
I am trying to re-use BlueZ code in my own C program to manage Bluetooth connection and running into compilation issues.
When I analyzed the problem further here is what I think is happening:
It all comes down to my program structure:
1.myadv.c includes myadv.h includes gio.h
2. myadv.c includes "gdbus.h" (Helper lib)
Now the problem is gdbus.h has certain symbol definitions (typedef, methods etc...) that conflict with internal defs in gio.h
Because of that I get compiler errors like this:
/usr/include/glib-2.0/gio/gioenums.h:1383:3: error: conflicting types for ‘GDBusSignalFlags’
} GDBusSignalFlags;
^~~~~~~~~~~~~~~~
conflicting types for ‘g_dbus_proxy_new’
void g_dbus_proxy_new
What is the best practice to avoid such symbol conflict errors during inclusion? Please note, I need to use both header files:
gio.h (The gnome lib)
gdbus.h (The dbus helper directly borrowed from BlueZ)
Don’t use the gdbus.h from BlueZ. It’s not compatible with GLib, yet erroneously uses the GLib symbol namespace (the g_ or G prefix).
Use the GDBus API from GLib itself, seeing as you’re already using GLib/GIO in your project.
I have been worked on M3 circuit and wrote some simple code including identifier "uint".
I got an error saying Fatal Error[Pe1696]: cannot open source file "stdint.h".
Do I have to add the source file by myself or is there any way to solve this??
stdint.h was added to C with the year 1999 version of the standard, known as "C99". To use it, you need a compiler that supports C99 or later. Some compilers support it, but it is not enabled per default. This appears to be the case here.
The latest version of IAR supports the current standard C11, and thereby also the previous standard C99. See this link: https://www.iar.com/support/resources/articles/exploring-c11-and-c14/
Click on "C11".
I am trying to embed a plplot graphics inside a gtk window at OSX. I used plplotcanvas but so far i have no success at all. At the wiki there is one example (http://archive.tcltk.co.kr/doc/plplot-html-5.9.4/gui.html) but i can find nothing else. The version i am using is 5.10.0.
Anyone knows how to do it or any advise?. At the examples on the wiki the compiler can not find plplotcanvas.h after change the libraries the compiler says the same for every function:
plem.c:62:2: warning: implicit declaration of function 'plplot_canvas_plwid' is invalid in C99 [-Wimplicit-function-declaration]
plplot_canvas_plwid(canvas,2);
It is the same with every function of plplotcanvas. Thanks in advance guys.
Either you got a version mismatch of libs and API you use, a typo, or you simply forgot to include appropriate headers.
For a more detailed diagnosis you need to post some (relevant) code chunks.
There are plenty of examples for plplot usage, each screenshot links to a full code example
Gcc nicely provides -Wformat to help with finding printf related bugs. Is there any way to get the same behavior in MSVC? Specifically I'd like the compiler to do some level of type checking on the arguments. I explicitely don't want to use C++'s iostream library for various reasons. (and I also don't want to use boost format).
To quote the source above, -WFormat basically provides the following capabilities
Check calls to printf and scanf, etc., to make sure that the arguments supplied have types appropriate to the format string specified, and that the conversions specified in the format string make sense.
The closest I can find for Microsoft so far is this warning which relates to using %d for 64 vs 32 bit builds.
I believe this is not a supported feature in Visual Studio (I'll try to find a citation for this). The closest I am aware of is to use the _Printf_format_string_ SAL annotation.
Unfortunately there is no way to generate such warning at compile time, but the VC++ code analysis tools will generate warning messages for printf-like functions with mismatching parameters.
See the /analyze option in VC++ and http://msdn.microsoft.com/en-us/library/vstudio/ms173498.aspx for more details.
As a side note, people have been complaining about this, so maybe Microsoft will do something in the future:
https://connect.microsoft.com/VisualStudio/feedback/details/799869/detection-of-format-string-errors-should-be-part-of-the-regular-c-compile-instead-of-analyze
Specifically I'd like the compiler to do some level of type checking
on the arguments.
The compiler loves to do type checking by default in C++ code. Unfortunately you're trying to use C facilities that don't offer that capability.
Just use IO streams and the compiler will do more than issue a warning when the types mismatch: It will issue an error and fail to compile your code completely!
The official documentation here only lists the minimum required version for a very small number of attributes:
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
Is there a complete list of which version each attribute was added in? Even better would be a list that also shows which ones are compatible with pcc and tcc.
For gcc versions:
http://www.ohse.de/uwe/articles/gcc-attributes.html
For pcc:
http://pcc.ludd.ltu.se/fisheye/browse/~raw,r=HEAD/pcc/pcc/cc/ccom/gcc_compat.c
For tcc:
??
For a lot of the useful ones you can copy the gcc version tests from glib's gmacros.h:
http://git.gnome.org/browse/glib/tree/glib/gmacros.h
Depending on your project you may also be able to just use GLib, and then use G_GNUC_NORETURN or whatever instead of the __attribute__ directly.
It probably would be better in principle to do HAVE_GCC_ATTRIBUTE_NORETURN as Juliano suggests, but it may also be YAGNI work, depending on your project.
I found this link which is slightly newer than the accepted answer:
https://patchwork.ozlabs.org/project/gcc/patch/20170706132518.GO3988#redhat.com/
Apparently up to 8.1.0. Not sure it is complete though.
Do yourself a favor and don't do that.
Perhaps your software has some pre-compilation configuration/setup phase (like the autoconf team... ugh! (shivers) or something more sane like CMake), use that.
Write small tests (autoconf macros) that check if the compiler accepts the __attribute__ you are interested in and if it works as expected. If successful, write a HAVE_GCC_ATTRIBUTE_XXX macro in a config.h file which is included from your source.
Then use that macro with #ifdef to test if you should put or not the attribute in the function, or perhaps if you should use another hack to emulate the lack of the attribute.