void parameter argument

  • Thread starter Thread starter Dan
  • Start date Start date
D

Dan

Is it just me, or is the removal of support for the word "void" in a
parameter list extremely annoying? Some of us have been programming for
years putting "void function_name (void)" - and it really doesn't feel nice
having to miss it out. Is there any reason for them removing this? I don't
suppose there's a pragma or something to stop the compiler barking about it
is there?
 
AFAIK, the syntax

void function_name(void)

was introduced in ANSI C (or perhaps earlier) because the old, original
K&R C allowed function prototypes with "unspecified" arguments. So, in
C you could also say,

void function_name()

which did _not_ mean "this function does not take any arguments," but
rather "I'm not telling you what arguments this function takes, if
any." So, the "(void)" syntax was a necessary addition to distinguish
between this non-disclosure and a declaration that a function took no
arguments. It was a backward compatibility thing.

I suppose that it was left out in C# because it's superfluous. In a
language that requires you to declare all arguments, there's no need to
distinguish between the two cases with a keyword "void".
 
Dan said:
Is it just me, or is the removal of support for the word "void" in a
parameter list extremely annoying? Some of us have been programming for
years putting "void function_name (void)" - and it really doesn't feel nice
having to miss it out. Is there any reason for them removing this? I don't
suppose there's a pragma or something to stop the compiler barking about it
is there?
Click to expand...

But you have to type less, so what's the big deal? ;). Just get used to
() means (nothing) or (void) or (nada) and you're done :)

FB

--
 
Is it just me, or is the removal of support for the word "void" in a
But you have to type less, so what's the big deal? ;). Just get used to
() means (nothing) or (void) or (nada) and you're done :)
Click to expand...


Unfortunately, at work it's part of our coding standard that you have to put
"void" in a function without parameters (we use C at work). So I can't get
used to not using it.
 
Is it just me, or is the removal of support for the word "void" in a
But you have to type less, so what's the big deal? ;). Just get used to
() means (nothing) or (void) or (nada) and you're done :)
Click to expand...


Unfortunately, at work it's part of our coding standard that you have to put
"void" in a function without parameters (we use C at work). So I can't get
used to not using it.
 
But now you're using C#. You have to accept that C# is not C and adapt to
new paradigms. void for empty argument lists always has been rubbish because
void foo() and void foo(void) are one and the same.
 
I'm only using C# at home - so I can't get un-used to using void. I don't
see why your example makes it rubbish.

Never mind though - I was hoping someone you reply saying - "yeah, just use
this pragma, and the compiler won't bark".
 
When using C# instead of C you have to get used to a lot of things.
for example:

byte a=1
byte b=2;
byte c = a+b; // error cannot convert int to byte

float f = 1.0; // cannot convert double to float
 
byte a=1
byte b=2;
byte c = a+b; // error cannot convert int to byte
Click to expand...

I didn't know that one. That's a bit crap really - where's the int come
from?

float f = 1.0; // cannot convert double to float
Click to expand...

I don't mind that one - I always put 1.0f in my code.
 
Dan said:
I didn't know that one. That's a bit crap really - where's the int come
from?
Click to expand...


Every signed integral calculation is automatically propagated to an int in
C# (except expressions with type long), don't ask me why as I've never
understood this one.
In C it was a bit different, the result of the expression was always the
biggest type of the operands so byte+short yields to short. But if you
assigned it back to an byte there was no error since all types were
automatically converted without warning so it could happen that you lose a
value.
I don't mind that one - I always put 1.0f in my code.
Click to expand...


Yes but the problem is that every method or constant of the math class
returns double so you always have to cast almost every line of code
especially when using APIs like direct3d which only operates with float.
 
byte a=1
Every signed integral calculation is automatically propagated to an int in
C# (except expressions with type long), don't ask me why as I've never
understood this one.
In C it was a bit different, the result of the expression was always the
biggest type of the operands so byte+short yields to short. But if you
assigned it back to an byte there was no error since all types were
automatically converted without warning so it could happen that you lose a
value.



Yes but the problem is that every method or constant of the math class
returns double so you always have to cast almost every line of code
especially when using APIs like direct3d which only operates with float.
Click to expand...


I see what you mean - that could be a major pain in the arse. I'm soon to
find out though, as I'm now starting work on a big project at home in C#.
It seems very good so far - but it's mostly just UI stuff that I've been
setting up so far, so I've not been doing much with floats or doubles yet.

As for using DirectX in C# - wouldn't that be very slow? I use DirectX at
work (I'm a games engine programmer). From what I've read so far about C# -
it's not very good for performance intensive applications. Is this right?
 
cody said:
void for empty argument lists always has been rubbish because
void foo() and void foo(void) are one and the same.
Click to expand...

foo() & foo(void) have never meant the same thing:

In C & C++
foo() takes an unknown number of parameters (of unknown type)
foo(void) takes no parameters

In C#
foo() takes no parameters
foo(void) is a syntax error.
 
As for using DirectX in C# - wouldn't that be very slow? I use DirectX at
work (I'm a games engine programmer). From what I've read so far about C# -
it's not very good for performance intensive applications. Is this right?
Click to expand...

In my experience Managed DirectX's performance is not bad, officially they
say it is 80% of the performance of native DirectX. If you don't create to
many new objects during the gameloop (which normally isn't necessary) you
won't notice GC.
There is a Quake 2 implementation with .NET in the Internet which runs faily
good.
Also JIT & GC algorithms getting better and better I'll expect that in some
time more games will be developed using .NET or Java.
 
void for empty arguments lists is a necessity in C for the reasons I
outlined last night: an empty argument list in C does _not_ mean that
there are no arguments. It means that the argument list is unspecified.
It could be empty, or it could take 15 arguments. Empty parentheses in
C mean that you're "not saying." So, the (void) notation is necessary
in order to say that you _are_ specifying what arguments the function
takes, and there _aren't any_.

Dan, you have to look at it from a semantic point of view, not a
syntactic one. Semantically, your workplace standard is correct: you
have to say (void) in order to tell the C compiler that the function
takes no arguments. However, it's a syntactic hack that was introduced
into C because some nitwit in the early days of C thought that
"unspecified parameters" function declarations were the way to go.

There's no need to introduce such a hack into C#. C# is starting with a
clean slate, so it uses the logical notation for methods that take no
parameters: empty parentheses. The problem is not that C# has
introduced a strange notation to the language. The problem is that C
introduced an ugly hack decades ago to get around a bad language design
decision.
 
Dan said:
Unfortunately, at work it's part of our coding standard that you have to put
"void" in a function without parameters (we use C at work). So I can't get
used to not using it.
Click to expand...

You'll *have* to get used to C not being the same as C# in many ways.
At the same time, you should get used to following the normal C# naming
conventions - PascalCasedMethodNames etc.

Trying to write C# while pretending it's C is a bad way to learn C#.
Treat it as if it were a completely different language as far as you
can.
 
Back
Top