C: declaring multipe pointer variables in same declaration statement

First thing first, never declare multiple pointer variables in same declaration statement. Don’t mix declaration of pointer and non-pointer variables in same line. Following this will save you a lot of debugging time in the future.

But in case, you are forced do it or you are debugging code written by somebody else, this short post can help you.

What does this code really mean?

int* c, d;

It is clear that c is a pointer to integer. But what about d? Is it integer or pointer to integer? Ofcourse, it is integer not a pointer to integer. Using declaration as above is very ambigious. Avoid it any cost. Instead, declare them on their own statements.

int* c;
int d;

Much clear. Isn’t it?

It is also better to follow this rule when all variables are pointers. Also, I prefer to put the star next to varaible name instead of the variable type.

int *p, *q;

is more intuitive than

int* p, *q;

C++11: How to create cyclic dependencies with shared_ptr and how to avoid them

C++ smart pointers are god send to C++ programmers. It avoids dealing with raw pointers and takes care of resource deallocation when the pointed “whatever” goes out of scope. All great. But there does exist some pitfalls and we should be vary of them. One such pitfalls is cyclic dependency when using shared_ptr. Cyclic dependency occurs when there is self-reference either in its own member or through the member of a member or through the member of a member of a member…. ok. I will stop. You get it :P.

Cyclic dependency

Cyclic dependency

Creating cyclic dependency

First we will see how we can create a cyclic dependency. Then we will see how to avoid them by using weak pointers.

Here we show two ways to create cyclic dependency:

  1. Cyclic dependency due to a self-referencing member
  2. Cyclic dependency due to a member of a member referencing this

Case 1

When ptr is created, its count is initialised to 1. When it is assigned to ptr->a, its count is incremented by 1 to 2. What this means is that ptr will not be deleted until both ptr and ptr->a are reset. But there is no way for that to happen. When ptr goes out of scope, the count will be decremented by 1 to 1. Since the count is not 0, ptr will not be deleted. ptr->x will not be reset until ptr is deleted. ptr will not be deleted until ptr->x is reset.
So shortly: ptr cannot be released because ptr->x will not be reset until ptr is reset.

Case 2

When x is created, its count is initialised to 1. When it is assigned to x->b->a, its count is incremented by 1 to 2. What this means is that x will not be deleted until both x and x->b->a are reset. But there is no way for that to happen. When x goes out of scope, the count will be decremented by 1 to 1. Since the count is not 0, x will not be deleted. Since x is not deleted, x->b will be not be deleted. Since x->b will not be deleted, x->b->a will not be deleted. If x->b->a will not be deleted, x will not be deleted. Go back 3 lines and start reading again and again and again :P.
So shortly: x(and hence x->b) will not be released because x->b->a will not be reset until x is reset.

Solving cyclic dependency using weak_ptr

Changing the self-referencing member a of ClassA to weak_ptr fixes the cyclic dependency problem in case 1.
Changing the member a of ClassB to weak_ptr fixes the cyclic dependency problem in case 2.

Courtesy: Stackoverflow

Golang CGo: Passing and receiving strings with C

In this post, we will see how to pass strings to a C function and receive strings returned from a C function. CGo provides convenient functions C.CString and C.GoString to convert Golang string into C char * and vice versa.


It should be noted that C.CString returns a dynamically allocated char array and should be freed to avoid memory leaks.

If go compiler throws an error like this:

error: ‘free’ undeclared (first use in this function)

It is because you are missing stdlib.h include which provides the free function.
Note: stdlib.h should be included in Go file.

GoLang: Inheritance by embedding

Inheritance in Go

In Go, inheritance is emulated by embedding anonymous member of parent struct in the derived struct. Lets say, we have a Mammal and a Fish struct and we want to build a Amphibian struct from these two structs. In Go, you would do it like this:

By embedding anonymous members in a struct, you can access the members of the embedded struct using dot notation directly on the embedding struct.

Polymorphism

In OOP languages, inheritance also allows polymorphism, through which instance of a derived class can be assigned to the instance of a parent class. Unfortunately Go doesn’t allow this:

The above code produces following error:

invalid type assertion: salamander.(Mammal) (non-interface type Amphibian on left)

The embedded anonymous member can be accessed using the syntax EmbeddingInstance.EmbeddedStruct syntax. This can also be assigned to an instance of embedded struct type.

Ambiguity due to multiple inheritance

When multiple anonymous members are declared in a struct and they have same members, Go cannot uniquely identify which of the members you are referring to. This creates ambiguity:

ambiguous selector salamander.Lips

This ambiguity can be resolved by using full path to the ambiguous member.

Embedding anonymous pointer members

Anonymous pointer to struct can also be embedded into a struct. Anonymous pointer members enable the same kind of inheritance normal embedded non-pointer members provide. But you should make sure you initialize the anonymous pointer member before using it. Failing to do so will give an error like this:

Salamander panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x2370]

goroutine 1 [running]:
runtime.panic(0x9aa80, 0x1660b9)
/usr/local/go/src/pkg/runtime/panic.c:266 +0xb6
main.main()
pointer_embedding.go:34 +0x370
exit status 2

Here is a working example with proper initialization of anonymous pointer members:

Right now, I am not aware of any advantages of using anonymous pointer members. If you know any, please share them in the comments.