New answers tagged

1

The correct answer is: C. None of the above. Option A: void fill_array(Array<Type>* array_to_fill); This is more idiomatic for pre-C++11 code where smart pointers were troublesome due to a lack of move semantics, and still continues to be the safer of the two options. The key here is the function does not "own" the memory: it performs one ...


2

You have already an accepted answer, but I am adding a new one (because I disagree with what @ixrec said). I imagine there is a subtle difference, but I don't know what it is. Could someone explain when I might prefer one form over the other? Ideally (in a perfect world), you should use the second form, for three reasons: it composes it naturally ...


-1

I have one simple objection against null: It breaks the semantics of your code completely by introducing ambiguity. Oftentimes you expect the result to be of a certain type. This is semantically sound. Say, you asked the database for a user with a certain id, you expect the resut to be of a certain type (=user). But, what if there is no user of that id? ...


0

The central problem of NULL is that it makes system unreliable. In 1980 Tony Hoare in the paper dedicated to his Turing Award wrote: And so, the best of my advice to the originators and designers of ADA has been ignored. …. Do not allow this language in its present state to be used in applications where reliability is critical, i.e., nuclear power ...


8

The first kind of signature is usually preferable. The difference is that the second signature requires the array to be created inside the function. In particular, the second signature effectively requires the array to outlive the scope in which it was created. So what we're really comparing are these two snippets: function foo1() { Array<Type>* ...


2

It seems most likely that the second one returns Array<Type> and not Array<Type>*. In the first case, there is an Array<Type> somewhere and you pass a pointer to it, so the function can fill it. In the second case, the function creates an object and returns it (unless the type is Array<Type>* and I don't know what's going on). If you ...


1

Don't use Pthread mutexes to synchronize between processes, at least on Linux. (I am not sure that Linux is implementing pthread_mutexattr_setpshared correctly and efficiently, at least not in GNU glibc 2.21). Use POSIX semaphores, see sem_overview(7). Or consider the Linux specific eventfd(2) probably with poll(2) & read(2) & write(2). Both ...


1

If I were you, I'd forget about using either pthreads (which only works on threads and not processes, and you're clearly using multiple processes) or shared memory of the kind you're talking about, as transferring the handles between processes is going to be a bit of a pain point when working in C#. A simpler technique, which is becoming increasing frequent ...


2

pthread_mutex_t is not designed to work cross process like that. It was built with the assumption that all threads using it will have the same address space. There are however other options to share a mutex between processes. As discussed in the comments there is futex(7) (which will work over shared memory) and sem_overview(7) (an explicit named semaphore ...



Top 50 recent answers are included