116 replies to this topic

[bramz]

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 ...

[monjardin]

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:

[bramz]

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;

}

[bramz]

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:

[.oisyn]

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

[bramz]

.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.

[monjardin]

And that's why it only comes up in esoteric discussions like this one. ;)

[bramz]

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

}

[monjardin]

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

I think ::someIdentifier will disambiguate the function, but I have know idea how to get the variable.

[Reedbeta]

Well, you can't get to it if it's in an anonymous namespace

[pater]

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

[Borogove]

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

[Axel]

bramz said:

Because it looks complicated ...

And because its more consistent.

[Nick]

.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?

[juhnu]

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.

[Nick]

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.

[Axel]

"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.

[juhnu]

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.

[bramz]

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?

[Nick]

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...