Possible Duplicate:
Please help me understanding the error a+++++b in C

In a discussion today the topic of pre/post increment came up.

We tried several combinations of addition and increment:

c = a+++b //works
c = a++ + ++b //works
c = a+++ ++b //works
c = a+++++b // doesn't work, compiler error "error: invalid lvalue in increment

Where is the difference? What exactly does that additional whitespace add for the parser so the program compiles?

Compilers are written in stages. The first stage is called the lexer and turns characters into a symbolic structure. So "++" becomes something like an enum SYMBOL_PLUSPLUS. Later, the parser stage turns this into an abstract syntax tree, but it can't change the symbols. You can affect the lexer by inserting spaces (which end symbols unless they are in quotes).

Normal lexers are greedy (with some exceptions), so your code is being interpreted as

a++ ++ +b

The input to the parser is a stream of symbols, so your code would be something like:

[ SYMBOL_NAME(name = "a"), 
  SYMBOL_PLUS_PLUS, 
  SYMBOL_PLUS_PLUS, 
  SYMBOL_PLUS, 
  SYMBOL_NAME(name = "b") 
]

Which the parser thinks is syntactically incorrect. (EDIT based on comments: Semantically incorrect because you cannot apply ++ to an r-value, which a++ results in)

a+++b 

is

a++ +b

Which is ok. So are your other examples.

Can you think of any legitimate (smart) uses for runtime code modification (program modifying it's own code at runtime)?

Modern operating systems seem to frown upon programs that do this since this technique has been used by viruses to avoid detection.

All I can think of is some kind of runtime optimization that would remove or add some code by knowing something at runtime which cannot be known at compile time.

There are many valid cases for code modification. Generating code at run time can be useful for:

• Some virtual machines use JIT compilation to improve performance.
• Generating specialized functions on the fly has long been common in computer graphics. See e.g. Rob Pike and Bart Locanthi and John Reiser Hardware Software Tradeoffs for Bitmap Graphics on the Blit (1984) or this posting (2006) by Chris Lattner on Apple's use of LLVM for runtime code specialization in their OpenGL stack.
• In some cases software resorts to a technique known as trampoline which involves the dynamic creation of code on the stack (or another place). Examples are GCC's nested functions and the signal mechanism of some Unices.

Sometimes code is translated into code at runtime (this is called dynamic binary translation):

• Emulators like Apple's Rosetta use this technique to speed up emulation. Another example is Transmeta's code morphing software.
• Sophisticated debuggers and profilers like Valgrind or Pin use it to instrument your code while it is being executed.
• Before extensions were made to the x86 instruction set, virtualization software like VMWare could not directly run privileged x86 code inside virtual machines. Instead it had to translate any problematic instructions on the fly into more appropriate custom code.

Code modification can be used to work around limitations of the instruction set:

• There was a time (long ago, I know), when computers had no instructions to return from a subroutine or to indirectly address memory. Self modifying code was the only way to implement subroutines, pointers and arrays.

More cases of code modification:

• Many debuggers replace instructions to implement breakpoints.
• Some dynamic linkers modify code at runtime. This article provides some background on the runtime relocation of Windows DLLs, which is effectively a form of code modification.

Hi all,

I'm an undergraduate CS student, and I'm currently taking my required Operating Systems course. I originally thought the material would be quite dry, but to my surprise I'm really interested in it.

What I'm wondering is, how are everyday machines (not so much computers and mobile devices as appliances, digital watches, etc) programmed? What kind of code goes into the programming of a Coca-Cola vending machine? How does my coffee maker accept a pre-programmed time and begin brewing a pot of coffee hours later, when that time arrives?

Do these kinds of machines have operating systems inside of them, or is it something even more basic? Are they written in Assembly, C, or some other language?

And, I would really like to find some resource that lists these operating systems or underlying code systems, possibly even with source code if possible. If anyone knows of such a resource (searching yielded nothing for me), that would be fantastic.

Most of what you're talking about are embedded based systems where C is a luxury often not available. They don't have software in the traditional sense. Most of the time the software is written in C, assembly, or even machine code. C and ASM require compilers to be written to use them for that platform. Machine code is written as binary w/o a compiler.

Your coffee pot and most simple systems like that don't carry an operating system. They simply load from a start address in memory and you put your code there. Often these systems have their "code" burned into EEPROMS that act as the hard drive of the system. Screw up the code after burning the proms, throw the chips away reburn the code on the chip, and start over. There are newer chips FPGA that higher end devices use to make testing, deploying, etc easier, but they are the same thing.

Coca-cola machines, routers, etc. typically use a realtime OS like QNX, EMBOS, or sometimes RTlinux if you're lucky. Most of these are proprietary OS you license for lots of money, but they have C compilers, drivers to work with hardware, etc.

http://www.qnx.com/

http://www.segger.com/cms/embos.html

http://www.microsoft.com/windowsembedded/en-us/campaigns/compact7/default.aspx?WT.srch=1&WT.mc_ID=SEARCH

RTLinux

Well, this is going to be a short one...

I want to parse /proc/net/tcp/, but is it safe? I mean, how to open and read it and not be afraid, that some other process (or the OS) will be changing it in the same time?

Although the files in /proc appear as regular files in userspace, they are not really files but rather entities that support the standard file operations from userspace (open, read, close). Note that this is quite different than having an ordinary file on disk that is being changed by the kernel.

All the kernel does is print its internal state into its own memory using a sprintf-like function, and that memory is copied into userspace whenever you issue a read(2) system call.

The kernel handles these calls in an entirely different way than for regular files, which could mean that the entire snapshot of the data you will read could be ready at the time you open(2) it, while the kernel makes sure that concurrent calls are consistent and atomic. I haven't read that anywhere, but it doesn't really make sense to be otherwise.

My advice is to take a look at the implementation of a proc file in your particular Unix flavour. This is really an implementation issue (as is the format and the contents of the output) that is not governed by a standard.

The simplest example would be the implementation of the uptime proc file in Linux: http://lxr.free-electrons.com/source/fs/proc/uptime.c. Note how the entire buffer is produced in the callback function supplied to single_open.

According to (c) ANSI ISO/IEC 14882:2003, page 127:

Linkage specifications nest. When linkage specifications nest, the innermost one determines the language. A linkage specification does not establish a scope. A linkage-specification shall occur only in namespace scope (3.3). In a linkage-specification, the specified language linkage applies to the function types of all function declarators, function names, and variable names introduced by the declaration(s).

extern "C" void f1(void(*pf)(int));
// the name f1 and its function type have C language
// linkage; pf is a pointer to a C function

extern "C" typedef void FUNC();
FUNC f2;
// the name f2 has C++ language linkage and the
// function's type has C language linkage

extern "C" FUNC f3;
// the name of function f3 and the function's type
// have C language linkage

void (*pf2)(FUNC*);
// the name of the variable pf2 has C++ linkage and
// the type of pf2 is pointer to C++ function that
// takes one parameter of type pointer to C function

What does all this mean? For example, what linkage does the f2() function have, C or C++ language linkage?

As pointed out by @Johannes Schaub, there is no real explanation of what this means in the Standard so it can be interpreted differently in different compilers.

Please explain the differences in the object file:

• a function's name with C language linkage and C++ language linkage.
• a function's type with C language linkage and C++ language linkage.

Language linkage is the term used for linkage between C++ and non-C++ code fragments. Typically, in a C++ program, all function names, function types and even variable names have the default C++ language linkage.

A C++ object code can be linked to another object code which is produced using some other source language (like C) using a predefined linkage specifier.

As you must be aware of the concept of name mangling, which encodes function names, function types and variable names so as to generate a unique name for them. This allows the linker to differentiate between common names (as in the case of function overloading). Name mangling is not desirable when linking C modules with libraries or object files compiled with a C++ compiler. To prevent name mangling for such cases, linkage specifiers are used. In this case, extern "C" is the linkage specifier. Let's take an example (c++ code mentioned here):

typedef int (*pfun)(int);  // line 1
extern "C" void foo(pfun); // line 2
extern "C" int g(int)      // line 3
...
foo( g ); // Error!        // line 5

Line 1 declares pfun to point to a C++ function, because it lacks a linkage specifier.

Line 2 therefore declares foo to be a C function that takes a pointer to a C++ function.

Line 5 attempts to call foo with a pointer to g, a C function, a type mis-match.

Diff in function name linkage:

Let's take two different files:

One with extern "c" linkage (file1.cpp):

#include <iostream>
using namespace std;

extern "C"
{
void foo (int a, int b)
{
    cout << "here";
}
}

int main ()
{
    foo (10,20);
    return 0;
}

One without extern "c" linkage (file2.cpp):

#include <iostream>
using namespace std;

void foo (int a, int b)
{
    cout << "here";
}

int main ()
{
    foo (10,20);
    return 0;
}

Now compile these two and check the objdump.

# g++ file1.cpp -o file1
# objdump -Dx file1

# g++ file2.cpp -o file2
# objdump -Dx file2

With extern "C" linkage, there is no name mangling for the function foo. So any program that is using it (assuming we make a shared lib out of it) can directly call foo (with helper functions like dlsym and dlopen) with out considering any name mangling effects.

0000000000400774 <foo>:
  400774:   55                      push   %rbp
  400775:   48 89 e5                mov    %rsp,%rbp
....
....
  400791:   c9                      leaveq 
  400792:   c3                      retq   

0000000000400793 <main>:
  400793:   55                      push   %rbp
  400794:   48 89 e5                mov    %rsp,%rbp
  400797:   be 14 00 00 00          mov    $0x14,%esi
  40079c:   bf 0a 00 00 00          mov    $0xa,%edi
  4007a1:   e8 ce ff ff ff          callq  400774 <foo>
  4007a6:   b8 00 00 00 00          mov    $0x0,%eax
  4007ab:   c9                      leaveq 

On the other hand, when no extern "C" is being used, func: foo is mangled with some predefined rules (known to compiler/linker being used) and so an application can not directly call it from it specifying the name as foo. You can however call it with the mangled name (_Z3fooii in this case) if you want, but nobody use it for the obvious reason.

0000000000400774 <_Z3fooii>:
  400774:   55                      push   %rbp
  400775:   48 89 e5                mov    %rsp,%rbp
 ...
...
  400791:   c9                      leaveq 
  400792:   c3                      retq   

0000000000400793 <main>:
  400793:   55                      push   %rbp
  400794:   48 89 e5                mov    %rsp,%rbp
  400797:   be 14 00 00 00          mov    $0x14,%esi
  40079c:   bf 0a 00 00 00          mov    $0xa,%edi
  4007a1:   e8 ce ff ff ff          callq  400774 <_Z3fooii>
  4007a6:   b8 00 00 00 00          mov    $0x0,%eax
  4007ab:   c9                      leaveq 
  4007ac:   c3                      retq   

This page is also a good read for this particular topic.

A nice and clearly explained article about calling convention: http://www.codeproject.com/KB/cpp/calling_conventions_demystified.aspx

I am working with an 8-bit AVR chip. There is no data type for a 64-bit double (double just maps to the 32-bit float). However, I will be receiving 64-bit doubles over Serial and need to output 64-bit doubles over Serial.

How can I convert the 64-bit double to a 32-bit float and back again without casting? The format for both the 32-bit and 64-bit will follow IEEE 754. Of course, I assume a loss of precision when converting to the 32-bit float.

For converting from 64-bit to 32-bit float, I am trying this out:

// Script originally from http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1281990303
float convert(uint8_t *in) {
  union {
    float real;
    uint8_t base[4];
  } u;
  uint16_t expd = ((in[7] & 127) << 4) + ((in[6] & 240) >> 4);
  uint16_t expf = expd ? (expd - 1024) + 128 : 0;
  u.base[3] = (in[7] & 128) + (expf >> 1);
  u.base[2] = ((expf & 1) << 7) + ((in[6] & 15) << 3) + ((in[5] & 0xe0) >> 5);
  u.base[1] = ((in[5] & 0x1f) << 3) + ((in[4] & 0xe0) >> 5);
  u.base[0] = ((in[4] & 0x1f) << 3) + ((in[3] & 0xe0) >> 5);
  return u.real;
}

For numbers like 1.0 and 2.0, the above works, but when I tested with passing in a 1.1 as a 64-bit double, the output was off by a bit (literally, not a pun!), though this could be an issue with my testing. See:

// Comparison of bits for a float in Java and the bits for a float in C after
// converted from a 64-bit double. Last bit is different.
// Java code can be found at https://gist.github.com/912636
JAVA FLOAT:        00111111 10001100 11001100 11001101
C CONVERTED FLOAT: 00111111 10001100 11001100 11001100

IEEE specifies five different rounding modes, but the one to use by default is Round half to even. So you have a mantissa of the form 10001100 11001100 11001100 11001100... and you have to round it to 24 bits. Numbering the bits from 0 (most significant), bit 24 is 1; but that is not enough to tell you whether to round bit 23 up or not. If all the remaining bits were 0, you would not round up, because bit 23 is 0 (even). But the remaining bits are not zero, so you round up in all cases.

Some examples:

10001100 11001100 11001100 10000000...(all zero) doesn't round up, because bit 23 is already even.

10001100 11001100 11001101 10000000...(all zero) does round up, because bit 23 is odd.

10001100 11001100 1100110x 10000000...0001 always rounds up, because the remaining bits are not all zero.

10001100 11001100 1100110x 0xxxxxxx... never rounds up, because bit 24 is zero.

This was at a community college. I failed it, but want to know the answer.

The problem is this: you have an 2D array of structs that represents an image. Each struct has a red, green, blue, and alpha value. There can be more info, but not required to solve the problem.

Say the image is 4000x4000 or 16 Million elements. Every element needs to be updated/checked on every turn.

For each element you need to:

• Set the red byte to 50 if < 50 or set to 205 > 205
• Set the green byte to a random value between 0 and 255 using rand()
• Modify blue in an "interesting" way.

"You can't brute force this, think in a smarter way; you need a better algorithm"

I basically did a loop. I was the fastest but he said it was "about finding a better algorithm, not using using cute compiler and pointer tricks".

Also needs to be in pure C. No OpenMP/Threads or OpenGL shading, OpenCL, etc... just ANSI C with standard libraries (even GNU/POSIX libraries were forbidden).

I asked about bitwise operations and he said that "those are very expensive in C [??] and it's about writing a fast and solid algorithm, not these cute tricks you keep coming up with".

So any hints?

Solution 1

The single most important point in updating a big array is exploiting the memory hierarchy by using locality. This hides memory latency and thus accelerates you algorithm.

First, you want to process the colors of each pixel together as they lie in the same struct. The processing of a pixel fits entirely in the register set of modern CPUs. Depending on the actual storage some bit/byte/word tweaking is possible here but it sounds like your instructor doesn't place emphasis on this point.

Second, you want to update the pixels in the order they are stored in memory. This means looping over the inner array dimension in the inner loop. This enables the compiler and the CPU to access the pixels efficiently in big chunks (keywords cache-lines and prefetching).

Solution 2

A completely different approach is adding a layer of indirection.

Instead of accessing the image array directly, route all accesses through accessor functions. Now you can write accessor functions that implement the required changes to the image without needing to access the array or even loop over all pixels at all!

This is like the Decorator pattern in an object-oriented language.

Note: I'm a experienced C++ programmer, so I don't need any pointer basics. It's just that I never worked with void** and have kind of a hard time getting my mental model adjusted to void* vs. void**. I am hoping someone can explain this in a good way, so that I can remember the semantics more easily.

Consider the following code: (compiles with e.g. VC++ 2005)

int main() {
  int obj = 42;
  void* ptr_to_obj = &obj;
  void* addr_of_ptr_to_obj = &ptr_to_obj;
  void** ptr_to_ptr_to_obj = &ptr_to_obj;
  void* another_addr = ptr_to_ptr_to_obj[0];
  // another_addr+1; // not allowed : 'void*' unknown size
  ptr_to_ptr_to_obj+1; // allowed
}

void* is a pointer to something, but you don't know what. Because you don't know what it is, you don't know how much room it takes up, so you can't increment the pointer.

void** is a pointer to void*, so it's a pointer to a pointer. We know how much room pointers take up, so we can increment the void** pointer to point to the next pointer.

In kernel.h min is defined as:

#define min(x, y) ({                \
    typeof(x) _min1 = (x);          \
    typeof(y) _min2 = (y);          \
    (void) (&_min1 == &_min2);      \
    _min1 < _min2 ? _min1 : _min2; })

I don't understand what the line (void) (&_min1 == &_min2); does. Is it some kind of type checking or something?

The statement

(void) (&_min1 == &_min2);

is a guaranteed "no-op". So the only reason it's there is for its side effects.

But the statement has no side effects!

However: it forces the compiler to issue a diagnostic when the types of x and y are not compatible.
Note that testing with _min1 == _min2 would implicitly convert one of the values to the other type.

So, I guess, that is what it does. It validates, at compile time, that the types of x and y are compatible.

I have this program

#include <stdio.h>
int main()
{
   char arr[100];
   printf("%d", (int)sizeof(0,arr));
}

This prints 4 when compiled as a C file and prints 100 as a C++ file. Why? I am using gcc.

In C the result of the right hand operand of the comma operator has a type and value. In C a comma operator does not yield an lvalue. So there is an lvalue to rvalue conversion resulting in decay of array type to pointer type. So in C what you get is the result of sizeof(char*).

In C++ the result of a comma expression is an lvalue. There is no such conversion[as in C] and what you get is the sizeof(arr) i.e 100

I think a little background can't hurt, so here it goes:

I work in a software company. Back in the day, in this very same company, a fellow programmer had an idea: let's indent our (module) code in such a way that the whole code represents or is similar to some unique feat of the given module - so, that you can just cat away to quickly see what an unknown file is for (I'll give an example in a bit). Well, the idea grew popular and we have a rather significant code base that follows this style.

An example: this source code is an excerpt from a module that's part of a test suite for remote ASCII-enabled terminals on systems which track date. (If what you see below looks bad, then you really don't want to see the more GUI-y stuff.)

char      *P="110"   "2No???"   "Fn" "_^w?"     
"??"     "Ff"  "_{" "{~"  "r^" "?F" ""  "_{"    
"{{"     "x~"  "fv" "_n"  "s{" "xx"    "ff"     
"_{{~p"  "wF"  "f_" "{{"  "{@" "wN"   "ro"  ""  
"??"      "{?????"   "~w{??}"  "??"    "~o??" "\
?]?B{B~"                       "F}"           "\
]Fz~ffnN"   "]N"              "K{F"             
            "fn"                                
"N]"  "F_"  "{F"       "fn"     "N]ro"  "{B"    
"~F"  "}N"  "^_",*p,   i,j,      k=0;  main     
# define I  pu##  t##  ch##  ar  /*20  11*/     
(){p  =3+P  ;for  (;*  ++p;++i%  8||I( 10))     
for(  k=6;  k--;)I(1  << k&*p-         63?P     
 [j=j?j-1                        :3]:  32);     
  return                         !/*c */1;}     

Now, of course for each benefit there's a downside, and for this convention it's pretty clear: maintainability and to some extent, readability.

The example above is not really a good example on maintainability, but we do have a sensible approach (of using padding space) to the problem, and it is, I think, well under control. However, some younger programmers continue to voice problems regarding code readability, and even I begin to have problems, understanding why. After all, we have always striven for standard conformance in any language we use, as you can see above.

So, what I can't quite grasp is that if code is standard-conforming, and the compiler has no problems with it – how can the programmer have? After all, the language rules are rather simple, so it's not that hard to (mentally) follow them; the situation is of course different if the code contains "hack-ish solutions", but we generally avoid them, for portability reasons amongst others. Would it be help if the code was written in C99?

How should I enlighten them? Am I missing something obvious?

They are young, and they must learn that code is not written for humans, but for machines.

Human readability, when achieved, is just a nice side-effect. But it is not needed.

Why does this Compile:

int main() 
{
    {}  
}

But this does not:

    {}

int main() 
{  
}

{} is a do-nothing statement (specifically in the C grammar it is an empty compound-statement). You can put statements in functions. You can't put statements elsewhere.

I suppose the reason the standard doesn't forbid an empty statement in your first example is that although it's pointless, it does no harm, and introducing rules for when braces are allowed to be empty would complicate the grammar for no benefit.

And, to be pedantic, I suppose I should point out that neither does the grammar define any other construct at file scope, of which {} is a valid instance, and that's why the second one is invalid.

I'm currently looking for a way to get backtrace information under Windows, from C code (no C++).

I'm building a cross-platform C library, with reference-counting memory management. It also have an integrated memory debugger that provides informations about memory mistakes (XEOS C Foundation Library).

When a fault occurs, the debugger is launched, providing information about the fault, and the memory record involved.

On Linux or Mac OS X, I can look for execinfo.h in order to use the backtrace function, so I can display additional infos about the memory fault.

I'm looking for the same thing on Windows.

I've seen How can one grab a stack trace in C? on Stack Overflow. I don't want to use a third-party library, so the CaptureStackBackTrace or StackWalk functions looks good.

The only problem is that I just don't get how to use them, even with the Microsoft documentation.

I'm not used to Windows programming, as I usually work on POSIX compliant systems.

What are some explanations for those functions, and maybe some examples?

EDIT

I'm now considering using the CaptureStackBackTrace function from DbgHelp.lib, as is seems there's a little less overhead...

Here's what I've tried so far:

unsigned int   i;
void         * stack[ 100 ];
unsigned short frames;
SYMBOL_INFO    symbol;
HANDLE         process;

process = GetCurrentProcess();

SymInitialize( process, NULL, TRUE );

frames = CaptureStackBackTrace( 0, 100, stack, NULL );

for( i = 0; i < frames; i++ )
{
    SymFromAddr( process, ( DWORD64 )( stack[ i ] ), 0, &symbol );

    printf( "%s\n", symbol.Name );
}

I'm just getting junk. I guess I should use something else than SymFromAddr.

Alright, now I got it. : )

The problem was in the SYMBOL_INFO structure. It needs to be allocated on the heap, reserving space for the symbol name, and initialized properly.

Here's the final code:

void printStack( void );
void printStack( void )
{
     unsigned int   i;
     void         * stack[ 100 ];
     unsigned short frames;
     SYMBOL_INFO  * symbol;
     HANDLE         process;

     process = GetCurrentProcess();

     SymInitialize( process, NULL, TRUE );

     frames               = CaptureStackBackTrace( 0, 100, stack, NULL );
     symbol               = ( SYMBOL_INFO * )calloc( sizeof( SYMBOL_INFO ) + 256 * sizeof( char ), 1 );
     symbol->MaxNameLen   = 255;
     symbol->SizeOfStruct = sizeof( SYMBOL_INFO );

     for( i = 0; i < frames; i++ )
     {
         SymFromAddr( process, ( DWORD64 )( stack[ i ] ), 0, symbol );

         printf( "%i: %s - 0x%0X\n", frames - i - 1, symbol->Name, symbol->Address );
     }

     free( symbol );
}

Output is:

6: printStack - 0xD2430
5: wmain - 0xD28F0
4: __tmainCRTStartup - 0xE5010
3: wmainCRTStartup - 0xE4FF0
2: BaseThreadInitThunk - 0x75BE3665
1: RtlInitializeExceptionChain - 0x770F9D0F
0: RtlInitializeExceptionChain - 0x770F9D0F

When I give sizeof(a), where a=13.33, a float variable, the size is 4 bytes. But if i give sizeof(13.33) directly, the size is 8 bytes.

I do not understand what is happening. Can someone help?

Thanks.

Those are the rules of the language.

13.33 is a numeric literal. It is treated as a double because it is a double. If you want 13.33 to be treated as a float literal, then you state 13.33f.

13.33 is a double literal. If sizeof(float) == 4, sizeof(13.33f) == 4 should also hold because 13.33f is a float literal.

Hi,

What are typical uses of null statement
;
in C ?

---

(I know that it is basically used to skip expression where it is expected by the compiler, but here I'm interested only in real-world examples of such use cases...)

Thanks

It's typically the side-effect of a code block that was stripped by the preprocessor, like

#if DEBUG
    #define ASSERT(_x) Assert(x)
#else
    #define ASSERT(_x)
#endif


ASSERT(test);    // Results in null statement in non-debug builds

That, or in loops where your condition already contains whatever needs to be done in each iteration.

Sample code snippet

const const const int x = 10;   
int main()
{}

gets compiled in C but not in C++. Why does it get compiled in C? I thought this would fail in C as well. Never mind.

Which part of the C++ Standard forbids the use of duplicate const and which part of the C standard allows this?

C99 §6.7.3/4:

If the same qualifier appears more than once in the same specifier-qualifier-list, either directly or via one or more typedef s, the behavior is the same as if it appeared only once.

Yes, that is valid C99, and your discovery is correct.

I'm looking for a GIS/Geometric algorithm:

I have 1000 points randomly distributed in a large area(such as a city), How can I find out all the small areas which have more than 15 points? Like this picture below:

Each point has its own latitude and longitude coordinates. The small area less than 200m x 200m.

You should take a look at RTREE structures. See http://en.wikipedia.org/wiki/R-tree

You've such algorithms implemented e.g. in the SQlite3 engine. See http://www.sqlite.org/rtree.html

Our Open Source version already includes the RTREE extension for Delphi 6 up to XE, compiled by default since rev. 1.8.

Hi,

I want to extend python and numpy by writing some modules in C or C++, using BLAS and LAPACK. I also want to be able to distribute the code as standalone C/C++ libraries. I would like this libraries to use both single and double precision float. Some examples of functions I will write are conjugate gradient for solving linear systems or accelerated first order methods. Some functions will need to call a Python function from the C/C++ code.

After playing a little with the Python/C API and the Numpy/C API, I discovered that many people advocate the use of Cython instead (see for example this question or this one). I am not an expert about Cython, but it seems that for some cases, you still need to use the Numpy/C API and know how it works. Given the fact that I already have (some little) knowledge about the Python/C API and none about Cython, I was wondering if it makes sense to keep on using the Python/C API, and if using this API has some advantages over Cython. In the future, I will certainly develop some stuff not involving numerical computing, so this question is not only about numpy. One of the thing I like about the Python/C API is the fact that I learn some stuff about how the Python interpreter is working.

Thanks.

First, there is one point in your question I don't get:

[...] also want to be able to distribute the code as standalone C/C++ libraries. [...] Some functions will need to call a Python function from the C/C++ code.

How is this supposed to work?

Next, as to your actual question, there are certainly advantages of using the Python/C API directly:

• Most likely, you are more familar with writing C code than writing Cython code.

• Writing your code in C gives you maximum control. To get the same performance from Cython code as from equivalent C code, you'll have to be very careful. You'll not only need to make sure to declare the types of all variables, you'll also have to set some flags adequately -- just one example is bounds checking. You will need intimate knowledge how Cython is working to get the best performance.

• Cython code depends on Python. It does not seem to be a good idea to write code that should also be distributed as standalone C library in Cython

I am programming strictly in C and WinAPI, no C++ or C#. I am a beginner and just learning to draw controls etc. The thing is that when I create Windows or other controls like Command Buttons, they have Windows Native look. Take a look at this:

But in Windows 7, the command buttons look like this:

Now, how do I get command buttons in my program to look like that. Is it even possible? I am following this tutorial, for reference: http://www.zetcode.com/tutorials/winapi/

Thanks.

You enable visual styles for your app by providing an XML manifest, either as a separate file or as an embedded resource. See Enabling Visual Styles for details.

I observe substantial speedups in data transfer when I use pinned memory for CUDA data transfers. On linux, the underlying system call for achieving this is mlock. From the man page of mlock, it states that locking the page prevents it from being swapped out:

mlock() locks pages in the address range starting at addr and continuing for len bytes. All pages that contain a part of the specified address range are guaranteed to be resident in RAM when the call returns successfully;

In my tests, I had a fews gigs of free memory on my system so there was never any risk that the memory pages could've been swapped out yet I still observed the speedup. Can anyone explain what's really going on here?, any insight or info is much appreciated.

CUDA Driver checks, is memory range is locked or not and then it will use different codepath. Locked memory is stored in the physical memory, so device can fetch it w/o help from CPU (DMA, aka Async copy; device only need list of physical pages). Not-locked memory can generate a page fault on access, and it is stored not only in memory, so driver need to access every page of non-locked memory, copy it into pinned buffer and pass it to DMA (Syncronious, page-by-page copy).

As described here http://forums.nvidia.com/index.php?showtopic=164661

host memory used by the asynchronous mem copy call needs to be page locked through cudaMallocHost or cudaHostAlloc.

I can also recommend to check cudaMemcpyAsync and cudaHostAlloc manuals at developer.download.nvidia.com. HostAlloc says that cuda driver can detect pinned memory:

The driver tracks the virtual memory ranges allocated with this(cudaHostAlloc) function and automatically accelerates calls to functions such as cudaMemcpy().