I have an interesting problem where I can't include malloc.h in my project.
I need malloc.h for Paul Nettle's mmgr tool (I'm not keen on using instruments)
Problem is I can't find the system library for memalign.
Xcode keeps failing because it cannot this definition & neither can I.
Anyone else seen this?!
If you just need to use malloc then you can grab it from the stdlib like so:
#include <stdlib.h>
Otherwise, you can directly call malloc.h like so:
#include <malloc/malloc.h>
EDIT:
A posix_memalign() exists in stdlib.h. The implementation looks like:
int posix_memalign(void **, size_t, size_t);
Perhaps you can make an alias to this and use it?
Related
I define a user class to hold all object. But the yacc is going to made a header file, which the yylval's type must be YYSTYPE. If I do not use %union, it will hold it as a int. But if I use %union, it will a union. and union is ugly - It cannot hold a class or a shared_ptr (can but not a good idea), It only want me to use pointer.
I just want to make YYSTYPE has a type as a user class type. How can I do it?
Don't use YYSTYPE.
With bison -- which is what you are actually using as a yacc implementation-- the correct way to define the semantic value type is
%define api.value.type { MyType }
If you require that one or more header files be included for the declaration to be valid, put them inside a %code requires block:
%code requires {
#include "MyType.h"
}
The code generated by these two directives is copied into the header file which bison produces, so other files need only include the generated header file.
Warning: Note that unless you use bison's C++ interface, the semantic value type must be trivially copyable, which will eliminate most standard C++ library types. Failing to obey this rule will produce undefined behaviour which may go undetected until you attempt to parse a sufficiently complex input. In other words, tests with simple inputs may not reveal the bug.
As you see, the source file that made by lex and yacc need the header file that made by yacc.
the header is short so we can look for some solution in it.
the part that define the type of yylval is this:
/* Value type. */
#if ! defined YYSTYPE && ! defined YYSTYPE_IS_DECLARED
typedef int YYSTYPE;
# define YYSTYPE_IS_TRIVIAL 1
# define YYSTYPE_IS_DECLARED 1
#endif
extern YYSTYPE yylval;
so we can define YYSTYPE before we include the yacc's header file, looks like:
#include "your-header-file-that-define-the-class.h"
#define YYSTYPE your-class-type
#include "the-header-file-that-made-by-yacc.h"
I'm currently porting a large project to Atmel Studio from ICCAVR as I need to use some of the ASF libraries for the project I'm working on.
I'm getting this error with the code example below in regards to trying to convert the following line to Atmel Studio
void debugoutf(__flash char * header, __flash char * msg);
Error pointer targeting address space '__flash' must be const in
function parameter 'header'
I tried using the macro in the documentation so that it can compile in Atmel Studio.
#ifndef FLASHVAR_H_
#define FLASHVAR_H_
#include <avr/pgmspace.h>
#if defined(__ICCAVR__) // IAR C Compiler
#define FLASH_DECLARE(x) __flash x
#endif
#if defined(__GNUC__) // GNU Compiler
#define FLASH_DECLARE(x) x __attribute__((__progmem__))
#endif
IAR to AVR Conversion
void debugout(FLASH_DECLARE (char * header), char * msg);
My question is have I done the conversion correctly, as I don't think I've done it correctly as nothing is getting printed out in my UART debugging.
The problem with using __attribute__((__progmem__)) on a variable is that whenever you want to read data from such a variable, you can't just access it in the usual way that you would access a variable from RAM. Instead, you have to use special functions provided by the avr/pgmspace.h header in avr-libc, like pgm_read_byte.
That's pretty annoying, but you don't have to do it that way because why they added named address spaces like __flash to recent versions of GCC (assuming you are using C, not C++). I recommend you stop using __attribute__((__progmem__)) and use __flash instead, if your version of GCC supports it. If the compiler gives you an error or warning because it expects items stored in flash to be marked as const, you can simply add const to the declaration/definition (in the right position). If you have trouble doing that, please post a new question or edit this question so it contains a MCVE.
For the example code you gave, you should try writing:
void debugoutf(const __flash char * header, const __flash char * msg);
Hi all I have an enum type that holds my error codes.
The problem is that they are not sequential i.e.
enum{
ErrorCode1 = 1,
ErrorCode2 = 4,
ErrorCode3 = 74
}; typedef NSInteger MyErroCodes;
Also there are maybe 50 codes + so I really wouldn't want to have to duplicate the data or do it manually, which is what I've seen so far in my searches. Any help would be greatly appreciated.
The enum construct only exists at compile time. At run time, your MyErrorCodes instances are plain integers, and the ErrorCodeN values are just plain integer constants. There is no way to extract metadata from your enum in runtime (well, maybe there is in the debug info etc, but you don't want to go there...).
I suggest:
Create a small script (Python, Perl or whatnot) to generate functions that map the numeric code to string values. In XCode, you can even run code generators during the compilation phase if you really want.
Use metaprogramming or preprocessor macros to generate these functions during compilation. This requires some thought, but it can be done.
this is often accomplished using an include of a file which contains all the values within some body and sometimes using macros:
ErrorCode_enum.h
MON_ENUM_VALUE(ErrorCode1, 1)
MON_ENUM_VALUE(ErrorCode2, 4)
MON_ENUM_VALUE(ErrorCode3, 74)
where MON_ENUM_VALUE would be a variable macro expansion.
and your enum declaration might take this form:
enum {
#include "mon_enum_value_begin.h" // defines MON_ENUM_VALUE and such
#include "ErrorCode_enum.h"
#include "mon_enum_value_end.h" // undefines MON_ENUM_VALUE and everything else defined in mon_enum_value_begin.h
};
typedef NSInteger MyErroCodes;
then later you might write:
#include "mon_enum_NSNumber_begin.h" // defines MON_ENUM_VALUE and such
#include "ErrorCode_enum.h"
#include "mon_enum_NSNumber_end.h" // undefines MON_ENUM_VALUE and…
or
#include "mon_enum_NSError_begin.h" // defines MON_ENUM_VALUE and such
#include "ErrorCode_enum.h"
#include "mon_enum_NSError_end.h" // undefines MON_ENUM_VALUE and…
which may add or stringize those tags and values to other types.
Personally, I think the macros are gross, and just take alternate approaches (which, admittedly, may be more tedious to write).
When generating an interface module with SWIG, the generated C/C++ file contains a ton of static boilerplate functions. So if one wants to modularize the use of SWIG-generated interfaces by using many separately compiled small interfaces in the same application, there ends up being a lot of bloat due to these duplicate functions.
Using gcc's -ffunction-sections option, and the GNU linker's --icf=safe option (-Wl,--icf=safe to the compiler), one can remove some of the duplication, but by no means all of it (I think it won't coalesce anything that has a relocation in it—which many of these functions do).
My question: I'm wondering if there's a way to remove more of this duplicated boilerplate, ideally one that doesn't rely on GNU-specific compiler/linker options.
In particular, is there a SWIG option/flag/something that says "don't include boilerplate in each output file"? There actually is a SWIG option, -external-runtime that tells it to generate a "boilerplate-only" output file, but no apparent way of suppressing the copy included in each normal output file. [I think this sort of thing should be fairly simple to implement in SWIG, so I'm surprised that it doesn't seem to exist... but I can't seem to find anything documented.]
Here's a small example:
Given the interface file swg-oink.swg for module swt_oink:
%module swt_oink
%{ extern int oinker (const char *x); %}
extern int oinker (const char *x);
... and a similar interface swg-barf.swg for swt_barf:
%module swt_barf
%{ extern int barfer (const char *x); %}
extern int barfer (const char *x);
... and a test main file, swt-main.cc:
extern "C"
{
#include "lua.h"
#include "lualib.h"
#include "lauxlib.h"
extern int luaopen_swt_oink (lua_State *);
extern int luaopen_swt_barf (lua_State *);
}
int main ()
{
lua_State *L = lua_open();
luaopen_swt_oink (L);
luaopen_swt_barf (L);
}
int oinker (const char *) { return 7; }
int barfer (const char *) { return 2; }
and compiling them like:
swig -lua -c++ swt-oink.swg
g++ -c -I/usr/include/lua5.1 swt-oink_wrap.cxx
swig -lua -c++ swt-barf.swg
g++ -c -I/usr/include/lua5.1 swt-barf_wrap.cxx
g++ -c -I/usr/include/lua5.1 swt-main.cc
g++ -o swt swt-main.o swt-oink_wrap.o swt-barf_wrap.o
then the size of each xxx_wrap.o file is about 16KB, of which 95% is boilerplate, and the size of the final executable is roughly the sum of these, about 39K. If one compiles each interface file with -ffunction-sections, and links with -Wl,--icf=safe, the size of the final executable is 34KB, but there's still clearly a lot of duplication (using nm on the executable one can see tons of functions defined multiple times, and looking at their source, it's clear that it would be fine to use a single global definition for most of them).
I'm fairly sure SWIG doesn't have an option for doing this. I'm speculating now, but I think the reason might well be concern about visibility of this for modules built with different versions of SWIG. Imagine the following scenario:
Two libraries X and Y both provide an interface to their code using SWIG. They both opt to make the "SWIG glue" stuff visible across different translation units in order to reduce code size. This will all be well and good if both X and Y are using the same version of SWIG. What happens though if X uses SWIG 1.1 and Y uses SWIG 1.3? Both modules work fine on their own, but depending on how the platform treats shared objects and how the language itself loads them (RTLD_GLOBAL?) some potentially very bad things would happen from the combination of the two modules being used in the same VM.
The penalty of the code duplication is pretty low I suspect - the cost of swapping between VM and native code is typically quite high, which probably dwarfs the slightly reduced instruction cache hits, although it might be interesting to see real benchmarks. On the up side this is code no users ever need to worry about it, since it's all auto generated and all correctly kept with interfaces written for the corresponding version.
I might be a bit late, but here is a workaround:
In SWIG (<= 1.3 ) there is -noruntime command-line option
Since SWIG 2.0 -noruntime was deprecated, so now one should pass -DSWIG_NOINCLUDE to the C preprocessor - not to the swig itself
I am completely not sure that this is correct, but it at least works for me. I am going to clarify this question in the SWIG's mailing list.
The following simple program can't be compiled with gcc 4.4.3
#include "rapidxml.hpp"
#include "rapidxml_utils.hpp"
#include "rapidxml_print.hpp"
#include "rapidxml_iterators.hpp"
int main()
{
return 0;
}
Compile produces following errors:
rapidxml_iterators.hpp:21: error: expected nested-name-specifier
rapidxml_iterators.hpp:21: error: invalid declarator before ‘value_type’
rapidxml_iterators.hpp:22: error: expected nested-name-specifier
rapidxml_iterators.hpp:22: error: invalid declarator before ‘&’ token
..........
What I am doing wrong?
These errors are caused by the rapidxml_iterators.hpp header. It seems including this header is not necessary for regular xml parsing. Apparently, the iterators defined in there are not really usable anyway. It might be something still under development. See also here.
The rapidxml_iterators.hpp have some problem with it. You have to change it to this:
typedef xml_node<Ch> value_type;
typedef xml_node<Ch> &reference;
typedef xml_node<Ch> *pointer;
typedef typename std::ptrdiff_t difference_type;
typedef typename std::bidirectional_iterator_tag iterator_category;
Simple solution for simple case
You don't actually need rapidxml_iterators.hpp but were doing a sanity check, right ?
Solution: only #include the headers you actually need.
It's a general rule. #include'ing everything is like eating too much : it turns the situation fat and slow.
By contrast, including only what you need:
keeps you aware of your actual code dependency,
helps keeping you safe from namespace pollution and the occasional name clashes and sometimes even portability issues,
alerts you when you are starting to mess together things that should be kept separated.
If you really need rapidxml_iterators.hpp
At this point, the problem is probably solved. If you really need rapidxml_iterators.hpp, it's indeed buggy (looks like this particular error is a Microsoftism). This problem and others were reported on February 2010 on http://sourceforge.net/p/rapidxml/bugs/10/ with suggested solutions different from #user437634's, still open and present in current release as of July 2013.