I have question how to put strings in progmem? Here is sample program.
void ParAdd(uint8_t type, const char *ParName){
#do something meaningful here
}
int main (void){
ParAdd(11, "Name1");
ParAdd(22, "Name2");
ParAdd(30, "Name3");
}
Is there a way to declare string parameter in function call as PROGMEM? I know for 'clasic' way like:
char string_1[] PROGMEM = "String 1";
char string_2[] PROGMEM = "String 2";
..but in my case I prefer to be in single line if possible. The example program is meninglles but in real case there are many parameters and many "ParAdd" calls. But can't find solution to use something like:
ParAdd(11, (PROGMEM) "Name1");
Someone know solution for that? Something like F() macro in arduino?
...fell stupid as solution is so easy.
ParAdd(11, PSTR("Name1"));
is the solution.
Related
I'm pretty much trying to make a AddInputEvent but, after a month, can't find a way to turn a local "function from FunctionCallbackInfo"(i'll just call this argf) in to a Persistent Function so that garbage collection doesn't erase the pointers.
Most stakeoverflow threads and example code I can find just say to Cast argf with a Local Function; then to throw that in to a Persistent New. This results in a error: cannot convert 'v8::Local<v8::Function>' to 'v8::Function*'
here is the code, not completely sure why I can't convert it
class inputevnt_feld{
public:
char* call_on;
v8::Persistent<v8::Function> func;
};
int entvcount = -1;
vector<inputevnt_feld> event_calls; //this is pretty much a array of events that we can call later
// in js looks like this "AddInputEvent("string", function);"
void AddInputEvent( const v8::FunctionCallbackInfo<v8::Value>& args ) {
v8::HandleScope handle_scope(args.GetIsolate());
//gotta make sure that we ain't letting in some trojan horse that has nothing in it
if (args[1]->IsFunction() && args[0]->IsString()) {
inputevnt_feld newt;
//converts js string to char array
v8::String::Utf8Value str(args.GetIsolate(), args[0]);
const char* cstr = ToCString(str);
newt.call_on = (char*)cstr;
//here is where the problem is with function casting
v8::Local<v8::Function> callback = v8::Local<v8::Function>::Cast(args[1]);
newt.func = v8::Persistent<v8::Function>::New(args.GetIsolate(), callback);
//push the new stuff in to even array
event_calls.push_back(newt);
//getting vector array size is too much for my smol brain
//so I'ma just do this myself
entvcount++;
//cout << event_calls[entvcount].call_on << endl; //debug
}
}
Most stakeoverflow threads and example code I can find just say to Cast argf with a Local Function; then to throw that in to a Persistent New
Yes, that's correct. If you know how to read it, the C++ type system is your friend for figuring out the details.
If you look at the definition of v8::PersistentBase<T>::New, you'll see that it takes a T* (for its template type T). If you look at the v8::Local<T> class, you'll see that a way to get a T* from it is to use its operator*. That leads to:
v8::Local<v8::Function> callback = ...Cast(args[1]);
... = v8::Persistent<v8::Function>::New(..., *callback);
Alternatively, you can use the Persistent constructor directly, and pass it the Local without dereferencing it first:
v8::Local<v8::Function> callback = ...Cast(args[1]);
... = v8::Persistent<v8::Function>(..., callback);
Both options are entirely equivalent. Personally I'd prefer the latter as it takes slightly fewer characters to spell out, but that's really the only difference.
(Your current code as posted does something else: it ignores the result of the cast and passes the original args[1] directly to Persistent::New -- that's not going to work.)
If I have a function foo() and use -ffunction-sections, gcc will place foo() inside its own .text.foo section. Is it possible to change the prefix of .text? Such that I get .customName.foo instead of text.foo.
I have the same problem, and I solved it using the section attribute.
The following solution is the simplest but does not create a section for each function (as the -ffunction-section parameter allows to do)
#define AT_FLASH_TEXT_SECTION(var) \
__attribute__((section(".text.flash"))) var
AT_FLASH_TEXT_SECTION(int myFunction(float param1, long param2));
So the function myFunction will appear in the section .text.flash, but also all other functions that are declared using the macro AT_FLASH_TEXT_SECTION.
To get the desired behavior I modified the macro as follows:
#define AT_FLASH_TEXT_SECTION_SYM(var, subsectionName) \
__attribute__((section(".text.flash." #subsectionName))) var
AT_FLASH_TEXT_SECTION_SYM(int myNewFunction(float param1, long param2), myNewFunction);
This is the best solution I've found so far.
Unfortunately, it is error-prone: the function name must be repeated identically in the subsectionName parameter of the AT_FLASH_TEXT_SECTION_SYM macro.
Furthermore, if two c modules contain two static functions with the same name, they will be emitted in the same section, going back to the previous problem.
I hope this helps, and maybe you can find a better solution starting from this.
No, that does not seem possible. See gcc/varasm.c (I haven't run the debugger, but am fairly sure this is the code that computes section names.)
void
default_unique_section (tree decl, int reloc)
{
[...]
switch (categorize_decl_for_section (decl, reloc))
{
case SECCAT_TEXT:
prefix = one_only ? ".t" : ".text";
break;
[...]
name = IDENTIFIER_POINTER (id);
name = targetm.strip_name_encoding (name);
[...]
string = ACONCAT ((linkonce, prefix, ".", name, NULL));
set_decl_section_name (decl, string);
}
Besides, that might be a bad idea, as e.g. linker scripts treat sections based on their names (see ld --verbose). Something like .text.customprefix.foo might be a better choice, but I don't know why you want custom prefices.
As a workaround, you can assign sections manually with the section attribute.
'section ("SECTION-NAME")'
Normally, the compiler places the code it generates in the 'text'
section. Sometimes, however, you need additional sections, or you
need certain particular functions to appear in special sections.
The 'section' attribute specifies that a function lives in a
particular section. For example, the declaration:
extern void foobar (void) __attribute__ ((section ("bar")));
puts the function 'foobar' in the 'bar' section.
Problem: I have a class of parameters which I'm passing around as const Some_Class& param because these parameters aren't changing. I need to pass these parameters to external library (GSL) which is accepting void* param. I can't cast from const& to void*, except with using const_cast. I heared that const_cast is not generally right solution, is this the correct use case for it?
My solution: As a solution I'm now using wrapper structure
struct wrapper{const Some_class& param;};
void gsl_func(void* param){
const Some_class& my_param = static_cast<wrapper*>(param)->param;
}
void my_func(const Some_class& my_param){
wrapper my_wrapper = {my_param};
gsl_func(&my_wrapper);
}
Which doesn't seems like the most elegant solution as I have to do this before every call to GSL. Is there some standardize way how to do this better?
I want to know data type using variable name
My final goal is getting a function signature for making a function stub(skeleton code)
but GCC error message just notify only undefined function name
Can I see a symbol table? (for inferencing function signature)
for example, foo.c is like below
#include <stdio.h>
int main() {
int n = 0;
n = foo();
return 0;
}
I want to make a function stub
so I want to know function foo has no parameter and returns an integer value
What should I do?
I think below:
linker error message say function foo is undefined
read line 5
n = foo();
inspect type of n using symbol table
is it right?
sorry for my bad english
please teach me inferencing a function signature
Inject his code into your source file:
typedef struct { int a; char c; } badtype_t;
badtype_t badtype;
then replace the error line like this:
n = badtype; //foo();
or if you want the type foo returns:
badtype = foo();
then you will get some error like this:
incompatible types when initializing type ‘int’ using type ‘badtype_t’
and you can get the type int.
or if you want the type of foo itself:
foo * 2
then you will get some error like this:
invalid operands to binary * (have 'int (*)()' and 'int')
and you can get the type int (*)() (that is, function taking nothing and returning an int).
It seems ok, but this strategy will not be good enough. Using the left-hand side of an expression is not enough to determine the return-type of the function. In particular, there may be no left-hand side at all, simply: foo();. What then?
If you just want to see a symbol table, that's what nm is for.
For example, if you get an error linking foo.o and bar.o together, you can do this:
nm -a foo.o
That will show you all the symbols defined in module foo.
But I don't see why you think this would help. C symbols do not have any type information. There may be enough metadata to distinguish extern linkage, and/or to tell whether a symbol function or data, but that's it. There is no way to tell an int from a float, or a function taking two ints and returning a double from a function taking a char * and returning a different char *.
So, you have some function named foo defined somewhere, and you want to know what its type is.
If you don't actually have a prototype for foo somewhere in your #included header files, this is easy:
If you're using C99, your code is invalid.
Otherwise, foo must take no arguments and return int, or your code is invalid.
And this isn't one of those "technically invalid, but it works on every platform" cases; it will break. For example, with gcc 4.2 for 64-bit x86 linux or Mac, if you do this:
double foo(double f) { return f*2; }
Then, without a header file, call it like this:
double f = foo(2.0);
printf("%f\n", f);
If compiled as C89, this will compile and link just fine (clang or gcc 4.8 will give you a warning; gcc 4.2 won't even do that by default), and run, and print out 2.0. At least on x86_64; on ARM7, you'll corrupt the stack, and segfault if you're lucky. (Of course it actually does double something—either your 2.0 or some random uninitialized value—but it can't return that to you; it's stashed it in an arbitrary floating-point register that the caller doesn't know to access.)
If it is in a header file, you can always search for it. emacs, graphical IDEs, etc. are very good at this. But you can use the compiler to help you out, in two ways.
First, just do this:
gcc -E main.c > main.i
less main.i
Now search for /foo, and you'll find it.
Or you can trick the compiler into giving you an error message, as in perreal's answer.
I have heard a lot about the importance of programming style. In my opinion, indention is easy to deal with. But other things frustrated me a lot. Considering a particular example to demonstrate the use of inet_makeaddr.
/* demonstrate the use of host address functions */
#include <stdio.h>
#include <arpa/inet.h>
#include <netinet/in.h>
int
main(void)
{
/* inet_makeaddr demo */
uint32_t neta = 0x0a3e5500;
uint32_t hosta = 0x0c;
struct in_addr alla = inet_makeaddr(neta, hosta);
printf("makeaddr of net: %08x and host: %08x = %08x\n",
neta, hosta, alla);
return 0;
}
Somebody may want to write as follows:
uint32_t neta;
uint32_t hosta;
struct in_addr alla;
neta = 0x0a3e5500;
hosta = 0x0c;
alla = inet_makeaddr(neta, hosta);
Then others may always initialize the variable when defined:
uint32_t neta = 0;
uint32_t hosta = 0;
struct in_addr alla = {0};
neta = 0x0a3e5500;
hosta = 0x0c;
alla = inet_makeaddr(neta, hosta);
Is any one of these better than the other ones, or it is just a personal taste?
I think the first of the three examples is the best: the second example one has uninitialized variables, and the third example has variables initialized to a meaningless (zero) value. I prefer to initialize variables (with a meaningful value) as soon as I define them (so that I don't have uninitialized variables). See also Should Local Variable Initialisation Be Mandatory?
I like to initialize values when defining. At least you know you won't have any "silly" NULL reference errors.
The bottom one has the small advantage that even if you change the code so that the initialization is no longer performed, you'll never have garbage in the variables, but only zeros. The top one has the same advantage though. My own preference in C is for functions to be extremely short, so that you never have to worry about those kinds of things, so I use the top form or the second form. But if your functions are long-winded, initializing everything to zero might be the way to go.
Personally I define the variables close to the function call if they are interesting for the function call. If it is an uninteresting variable I usually define it it in the declaration.
It is usually always better to initialise variables in any language. Somehow it's just oen of those little things that make your life easier, just like leaving a trailing comma.
Although if you are going to initialise your variables it's probably best to do it with a value that means something to your algorithm, otherwise you're not solving anything, just changing the way everything behaves when you create a bug.