# void as a function parameter

116 replies to this topic

### #21bramz

Valued Member

• Members
• 189 posts

Posted 27 May 2006 - 07:56 PM

monjardin said:

@bramz: Neither of those work in the case described.

Are we talking about the same thing? I've checked it with gcc and _both_ compile just fine ...
hi, i'm a signature viruz, plz set me as your signature and help me spread :)
Bramz' warehouse | LiAR isn't a raytracer

### #22monjardin

Senior Member

• Members
• 1033 posts

Posted 27 May 2006 - 08:02 PM

They compile with the function defined in a seperate file and without including that file or declaring the function in file scope?? I am asserting that a project consisting of only the two files described and with no additional code does not compile in VC++ 2005. It should work with no problem if you place all the code in one file, but that's not the point. ;)
Anyway, I'll try it out in GCC. It will take me a few minutes to reboot into Linux... :geek:
monjardin's JwN Meter (1,2,3,4,5,6):
|----|----|----|----|----|----|----|----|----|----|
*

### #23bramz

Valued Member

• Members
• 189 posts

Posted 27 May 2006 - 08:02 PM

bramz said:

Are we talking about the same thing? I've checked it with gcc and _both_ compile just fine ...

This is what I've tried:

#include <iostream>

namespace someNamespace

{

void someIdentifier(int a)

{

std::cout << a << std::endl;

}

}

namespace

{

int someIdentifier = 1;

}

void a() // prints 1

{

someNamespace::someIdentifier(someIdentifier);

}

void b() // prints 2

{

using someNamespace::someIdentifier;

someIdentifier(2);

}

int main()

{

a();

b();

return 0;

}

hi, i'm a signature viruz, plz set me as your signature and help me spread :)
Bramz' warehouse | LiAR isn't a raytracer

### #24bramz

Valued Member

• Members
• 189 posts

Posted 27 May 2006 - 08:04 PM

monjardin said:

They compile with the function defined in a seperate file and without including that file or declaring the function in file scope?? I am asserting that a project consisting of only the two files described and with no additional code does not compile in VC++ 2005. It should work with no problem if you place all the code in one file, but that's not the point. ;)
Anyway, I'll try it out in GCC. It will take me a few minutes to reboot into Linux... :geek:

Duh! =) I was assuming the reader was smart enough to fill in those insignificant details by himself :whistle:
hi, i'm a signature viruz, plz set me as your signature and help me spread :)
Bramz' warehouse | LiAR isn't a raytracer

### #25.oisyn

DevMaster Staff

• Moderators
• 1842 posts

Posted 27 May 2006 - 08:06 PM

bramz: the call is fine, it's the declaration that is the problem. You're not able to declare someNamespace::someIdentifier within a function (well, unless your currently in the someNamespace scope of course).

Nick: I don't see why void has to be removed for functions that don't return anything. It'll break ALL current code and C++-like languages such as C# and Java are using it as well. There is not an obvious problem with it, so why bother? BTW, it's also handy for templates

template<class T> T func()
{
return someOtherFunc<T>();
}

Compiles fine for T=void
-
Currently working on: the 3D engine for Tomb Raider.

### #26bramz

Valued Member

• Members
• 189 posts

Posted 27 May 2006 - 08:12 PM

.oisyn said:

bramz: the call is fine, it's the declaration that is the problem. You're not able to declare someNamespace::someIdentifier within a function (well, unless your currently in the someNamespace scope of course).

Well, exactly, but that doesn't matter, does it? The reason why we'd like to declare it inside the function is because the compiler wouldn't confuse it with the variable. But since the function is now inside someNamespace, we have other means to tell the compiler what someIdentifier to use. In fact, even without the variable, we'd still need to tell the compiler in what namespace to look (apart from ADL of course). So in short: we can't, but we don't need to anyway.
hi, i'm a signature viruz, plz set me as your signature and help me spread :)
Bramz' warehouse | LiAR isn't a raytracer

### #27monjardin

Senior Member

• Members
• 1033 posts

Posted 27 May 2006 - 08:21 PM

And that's why it only comes up in esoteric discussions like this one. ;)
monjardin's JwN Meter (1,2,3,4,5,6):
|----|----|----|----|----|----|----|----|----|----|
*

### #28bramz

Valued Member

• Members
• 189 posts

Posted 27 May 2006 - 08:30 PM

BTW, what do you do in case it's the other way around?

#include <iostream>

void someIdentifier(int a)

{

std::cout << a << std::endl;

}

namespace

{

int someIdentifier = 1;

}

int main()

{

someIdentifier = 2; // oh bugger

}



hi, i'm a signature viruz, plz set me as your signature and help me spread :)
Bramz' warehouse | LiAR isn't a raytracer

### #29monjardin

Senior Member

• Members
• 1033 posts

Posted 27 May 2006 - 08:34 PM

Well... :blink: Don't do that! :D

I think ::someIdentifier will disambiguate the function, but I have know idea how to get the variable.
monjardin's JwN Meter (1,2,3,4,5,6):
|----|----|----|----|----|----|----|----|----|----|
*

### #30Reedbeta

DevMaster Staff

• 5308 posts
• LocationSanta Clara, CA

Posted 27 May 2006 - 09:03 PM

Well, you can't get to it if it's in an anonymous namespace
reedbeta.com - developer blog, OpenGL demos, and other projects

### #31pater

Valued Member

• Members
• 117 posts

Posted 27 May 2006 - 09:30 PM

You shouldn't be declaring global variables that way, anyhow... :P

### #32Borogove

New Member

• Members
• 16 posts

Posted 27 May 2006 - 10:30 PM

poita said:

Is there any practical reason you'd want to do that? {cast the result of an expression to void}

If at high warning levels, your compiler warns on, e.g., the result of a function call being ignored, you can use the void cast to suppress that warning:

printf("blah"); // warning: function result is int, ignored
(void)printf("blah"); // no warning

### #33Axel

Valued Member

• Members
• 119 posts

Posted 27 May 2006 - 11:24 PM

bramz said:

Because it looks complicated ...
And because its more consistent.

### #34Nick

Senior Member

• Members
• 1227 posts

Posted 28 May 2006 - 08:18 AM

.oisyn said:

I don't see why void has to be removed for functions that don't return anything.
For the same reason we stopped writing (void) for empty parameter lists. If function declarations within functions were not allowed then writing void in front of a function that doesn't return a value is just as obsolete. If your function does't take arguments, don't write it, if it doesn't return a value, don't write it. At least don't be forced to write it...

Quote

It'll break ALL current code and C++-like languages such as C# and Java are using it as well. There is not an obvious problem with it, so why bother?
I know it could break current code (but hardly ALL code). But I'm thinking progressively here. Improving the signal/noise ratio. There was no "obvious problem" with K&R style declarations but I'm glad it's gone (for the most part). I don't like writing extra words that have no purpose.

Would you add function declarations inside functions as a feature for a new imperative programming language?

### #35juhnu

Valued Member

• Members
• 292 posts

Posted 28 May 2006 - 10:41 AM

This is probably off-topic, but as far as the improvements for the C++ are concerned.. one thing I would like see:

1. 'this' should be a reference.
2. accessing member variables only thru this-reference.

This way people wouldn't need to use some prefixes such as m_ to mark member-variables and there wouldn't be the problem local variables masking member ones.

### #36Nick

Senior Member

• Members
• 1227 posts

Posted 28 May 2006 - 11:23 AM

juhnu said:

1. 'this' should be a reference.
Agreed.

Quote

2. accessing member variables only thru this-reference.
Please no. That's five extra characters for every member variable you access. Imagine what a simple Matrix class would look like. For places where it matters, I use 'this->' and I would prefer a 'this.' syntax but there are plenty situations where it creates a bad signal/noise ratio. The use of 'm_' should die completely though.

Edit: Just to clarify, I think accessing member variables though 'this.' is a good thing, but it shouldn't be forced.

### #37Axel

Valued Member

• Members
• 119 posts

Posted 28 May 2006 - 11:43 AM

"this" will not become a reference, because it would naturally break compatibility for no good reason but syntactic sugar.

And I agree with Nick that its no good idea to force member variables to be accessed through "this". Besides it would break existing code too.

### #38juhnu

Valued Member

• Members
• 292 posts

Posted 28 May 2006 - 01:02 PM

Axel said:

"this" will not become a reference, because it would naturally break compatibility for no good reason but syntactic sugar.

Yeah you are right. Both of these would break existing code, so there's no way things would change. However the reference would 'the right thing to do' though. I just googled about this and found this:

Quote

Why is "this" not a reference?
Because "this" was introduced into C++ (really into C with Classes) before references were added. Also, I chose "this" to follow Simula usage, rather than the (later) Smalltalk use of "self".
http://www.research...._faq2.html#this

Axel said:

And I agree with Nick that its no good idea to force member variables to be accessed through "this".

Lots of people are using different naming conventions for local and member variables because of this problem and I think writing "this." wouldn't be that bad, at least better than 'm_' or some other non-standard prefix. If you see some C# coding guidelines they recommend you to access member variables always thru this reference.

### #39bramz

Valued Member

• Members
• 189 posts

Posted 28 May 2006 - 01:26 PM

juhnu said:

1. 'this' should be a reference.
2. accessing member variables only thru this-reference.

This way people wouldn't need to use some prefixes such as m_ to mark member-variables and there wouldn't be the problem local variables masking member ones.

These are the sort of "improvements" of which you have to wonder: "what happens to existing code?". So, though (1) might have been a better idea, it won't happen. About (2), today you already have the choice to access all your member variables through this anyway, so why break all that existing code?
hi, i'm a signature viruz, plz set me as your signature and help me spread :)
Bramz' warehouse | LiAR isn't a raytracer

### #40Nick

Senior Member

• Members
• 1227 posts

Posted 28 May 2006 - 01:32 PM

Axel said:

"this" will not become a reference, because it would naturally break compatibility for no good reason but syntactic sugar.
I wonder if, hypothetically, 'this' could automatically evaluate to a reference type or a pointer type (sort of like an implicit cast operator), it could possibly break any existing code...

#### 1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users