accre / lstore

LStore - A fault-tolerant, performant distributed data storage framework.
http://www.lstore.org
Apache License 2.0
4 stars 5 forks source link

"void *foo()" or "void * foo()" or "void* foo()" #80

Closed PerilousApricot closed 8 years ago

PerilousApricot commented 8 years ago

We coddle asterisks inconsistently. Choose one.

tacketar commented 8 years ago

I only use "void *foo()" and my guess is it's by far the most common flavor. -Alan

On 5/9/2016 3:09 PM, Andrew Melo wrote:

We coddle asterisks inconsistently. Choose one.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/accre/lstore/issues/80

PerilousApricot commented 8 years ago

It's quite common, but with a sed listing 200 lines long, just because it's common means it has to stay.

My gut is that the "" describes the type and not the function, so it makes more sense to do "void foo". The other way somehow implies that foo is a pointer

It's dark in this basement.

tacketar commented 8 years ago

I strongly prefer the other way. I'm flexible on a lot of things but not this. What you propose has never made sense to me. Maybe it's because that's the way I was taught. In any case having the * go with the variable looks better to me. None of the 3 variations makes sense looking at it from a non-programming standpoint. In fact Fortran's approach makes much more sense: "void, pointer :: foo". But we are our history. So make the * go with the variable. Another thing I can't stand is making a pointer typedef. That makes things like _sizeof () functions meaningless. (Am I returning the size of the typedef or what the typedef points to?)

Alan

On 5/9/2016 3:34 PM, Andrew Melo wrote:

It's quite common, but with a sed listing 200 lines long, just because it's common means it has to stay.

My gut is that the "" describes the type and not the function, so it makes more sense to do "void foo". The other way somehow implies that foo is a pointer

It's dark in this basement.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/accre/lstore/issues/80#issuecomment-217981058

hellermf commented 8 years ago

Like Andrew void* feels right to me on one level because in my head I connect the pointerness/non-pointerness with the type. However I would argue that the C language takes the opposite approach, when dealing with variable declarations you have the following behavior:

int* a, b; // does not give you two pointer, rather a is a pointer and b is not int a, b; // does of course give you two pointers

I think this demonstrates that the characteristic of being a pointer is more strongly connected to the variable than the type. Thus I try to force myself to put the * adjacent the variable name not the type, and to stay consistent I try to do the same with functions.

--Matt

----- Original Message ----- From: "tacketar" notifications@github.com To: "accre/lstore" lstore@noreply.github.com Sent: Monday, May 9, 2016 5:48:53 PM Subject: Re: [accre/lstore] "void foo()" or "void * foo()" or "void foo()" (#80)

I strongly prefer the other way. I'm flexible on a lot of things but not this. What you propose has never made sense to me. Maybe it's because that's the way I was taught. In any case having the * go with the variable looks better to me. None of the 3 variations makes sense looking at it from a non-programming standpoint. In fact Fortran's approach makes much more sense: "void, pointer :: foo". But we are our history. So make the * go with the variable. Another thing I can't stand is making a pointer typedef. That makes things like _sizeof () functions meaningless. (Am I returning the size of the typedef or what the typedef points to?)

Alan

On 5/9/2016 3:34 PM, Andrew Melo wrote:

It's quite common, but with a sed listing 200 lines long, just because it's common means it has to stay.

My gut is that the "" describes the type and not the function, so it makes more sense to do "void foo". The other way somehow implies that foo is a pointer

It's dark in this basement.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/accre/lstore/issues/80#issuecomment-217981058

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub

PerilousApricot commented 8 years ago

If you use the mail interface, please trim responses 👮

PerilousApricot commented 8 years ago

s/Alan/Matt/

tacketar commented 8 years ago

On 5/10/2016 10:00 AM, Andrew Melo wrote:

The only pointer typedef I was going to make was for function pointers (though they're not the same kinda "pointers").

Correct. In this case the pointer typedef makes sense and it's the only case I ever have with a pointer typedef.

*

I was talking about the return types of functions, not for
variable declarations. (though I void the |int *x, *y;| pattern
completely for the reason Matt pointed out)

I don't have a strong an opinion on this but it would probably make sense to make everything the same. Just my 2 cents.

PerilousApricot commented 8 years ago

Fixed in master.