c99

Improving the performance of Matrix Multiplication

偶尔善良 提交于 2019-11-28 01:46:24
问题 This is my code for speeding up matrix multiplication, but it is only 5% faster than the simple one. What can i do to boost it as much as possible? *The tables are being accessed for example as: C[sub2ind(i,j,n)] for the C[i, j] position. void matrixMultFast(float * const C, /* output matrix */ float const * const A, /* first matrix */ float const * const B, /* second matrix */ int const n, /* number of rows/cols */ int const ib, /* size of i block */ int const jb, /* size of j block */ int

C99 not default C- version for GCC?

痴心易碎 提交于 2019-11-28 00:53:43
Why does not GCC compile the C99 by default? I mean why is it necessary to add --std=c99 flag everytime a code in C99 is written? Edit: As of GCC 5, -std=gnu11 is the default. See Porting to GCC 5 . See C Dialect Options , gnu89 is the default. `gnu89' GNU dialect of ISO C90 (including some C99 features). This is the default for C code. As @tsv mentioned, ISO C99 is not fully supported yet: `c99' `c9x' `iso9899:1999' `iso9899:199x' ISO C99. Note that this standard is not yet fully supported; see http://gcc.gnu.org/c99status.html for more information. The names `c9x' and `iso9899:199x' are

How is the size of a variable length array computed at runtime in C99?

浪尽此生 提交于 2019-11-28 00:10:34
问题 In C89, the length of an array is known at compile time. But in C99, with variable length arrays, the length of an array may be unknown before runtime. So how does it get computed? And why couldn't the length of a dynamically allocated array be computed in the same way? 回答1: From ISO/IEC 9899:TC3 Section 6.7.5.2: Array declarators An ordinary identifier (as defined in 6.2.3) that has a variably modified type shall have either block scope and no linkage or function prototype scope. If an

Dynamic array allocation on stack in C

痴心易碎 提交于 2019-11-28 00:04:01
I just did a experiment yesterday, and find something confusing: #include <stdio.h> int main() { int j; scanf("%d",&j); const int i = j; int arr[i]; return 0; } The number j is read from keyboard and it’s used to allocate the array arr on the stack. The compiler does not even know the size of the array at compile time (initializes j to 0?), but there is no compilation error. How is it possible? Variable length arrays were added to C99. It's described in the C99 rationale: 6.7.5.2 Array declarators C99 adds a new array type called a variable length array type. The inability to declare arrays

C Complex Numbers in C++?

荒凉一梦 提交于 2019-11-27 23:44:16
The following code compiles and runs just fine in C (at least according to 'gcc -std=gnu99'), but it fails to compile under C++, giving "line 5: error: cannot convert 'double' to 'double complex ' in initialization". Does anybody know why? #include "/usr/include/complex.h" #include <stdio.h> int main(int argc, char * argv[]) { double complex a = 3; // ERROR ON THIS LINE printf("%lf\n", creal(a)); return 0; } I realize there is another way of doing complex numbers in C++, but I have to use C complex numbers in C++, because that is how the legacy code I was given does things. Thanks if you can

Kernel's “container_of” - any way to make it ISO conforming?

房东的猫 提交于 2019-11-27 23:36:09
问题 While looking at Linux kernel's implementation of doubly linked circular lists, I've found following macro: #define container_of(ptr, type, member) ({ \ const typeof( ((type *)0)->member ) *__mptr = (ptr); \ (type *)( (char *)__mptr - offsetof(type,member) );}) The way this works is that it returns pointer to structure given only address of one of its members: struct blabla { int value; struct list_head *list; } Thus you can get pointer to blabla (and get to "value") given only pointer to

Adding two floating-point numbers

孤街浪徒 提交于 2019-11-27 23:31:53
I would like to compute the sum, rounded up, of two IEEE 754 binary64 numbers. To that end I wrote the C99 program below: #include <stdio.h> #include <fenv.h> #pragma STDC FENV_ACCESS ON int main(int c, char *v[]){ fesetround(FE_UPWARD); printf("%a\n", 0x1.0p0 + 0x1.0p-80); } However, if I compile and run my program with various compilers: $ gcc -v … gcc version 4.2.1 (Apple Inc. build 5664) $ gcc -Wall -std=c99 add.c && ./a.out add.c:3: warning: ignoring #pragma STDC FENV_ACCESS 0x1p+0 $ clang -v Apple clang version 1.5 (tags/Apple/clang-60) Target: x86_64-apple-darwin10 Thread model: posix $

Best way to compare two int arrays of the same length?

為{幸葍}努か 提交于 2019-11-27 22:23:20
what is the best way to compare int arrays b and c with a: int a[] = {0,1,0,0,1}; int b[] = {0,1,0,0,1}; int c[] = {1,1,0,0,1}; b and c are just examples, assume they can be any combination of 0s and 1s. I am trying to detect arrays identical to a. I have googled this for a while and have not found a satisfactory answer. This is a beginners question I realise, thank you for your patience. Use the standard memcmp function from <string.h> . memcmp(a, b, sizeof(a)) == 0 whenever a and b are equal. If you mean int a[] = {0,1,0,0,1}; int b[] = {0,1,0,0,1}; int c[] = {1,1,0,0,1}; then memcmp(a, b,

Is there a #define for C99?

落爺英雄遲暮 提交于 2019-11-27 20:43:32
问题 I want to do something in C99 one way, otherwise to perform it another way. What is the #define to check for? #ifdef C99 ... #else ... #endif 回答1: There is not an specific #define value. Just check __STDC_VERSION__ and define it yourself! ;-) #if __STDC_VERSION__ >= 199901L /* C99 code */ #define C99 #else /* Not C99 code */ #endif #ifdef C99 /*My code in C99 format*/ #else /*My code in C99 format*/ #endif EDIT: A more general snippet, from here. I've just changed the defined names, just in

Implicit declaration of function - C99

孤街醉人 提交于 2019-11-27 20:32:31
问题 I am currently using Xcode 4, and in my .pch file I have this macro: #define localize(s) NSLocalizedString((s), nil) . When I try to use this macro in some .m file, I receive this warning: Implicit declaration of function 'localize' is invalid in C99 . This code compiles without a problem, but how can I fix this so I don't get a warning? 回答1: I had this problem when I did a global replace of NSLog with DLog. I foolishly included the #define DLog(...) NSLog(... statements, so I ended up with