Bruno Medeiros Wrote:

> Bruce Adams wrote:
> > Bruno Medeiros Wrote:
> > 
> >> Bruce Adams wrote:
> >>> [OT]
> >>> Someone at work pointed out this java chestnut recently. If you've used java much you will know it but it may come as a shock to a mainly C++ coder.
> >>>
> >>> class foo {
> >>>     bar x;
> >>>     void foo () {
> >>>         x = new bar();
> >>>     }
> >>> }
> >>>
> >>> foo is NOT a constructor its actually a method named foo. The java compiler or interpreter generates a default constructor that sets all members to null so any use of x in any method of foo will result in a null pointer exception. This apparently compiles with no warnings.
> >>> [/OT]
> >> What's so surprising about that, even for a Java newcomer?
> >>
> >> -- 
> >> Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
> > 
> > Its the fact that a simple typo can cause such mayhem. Remove the void from foo() and it becomes a constructor and everthing works just fine.
> > 
> > 
> 
> No one in the Java world writes classes with lowercase first letter anyways. :P
> 
> -- 
> Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Oh no! My example is now completely undermined and devalued!

torhu escribió:
> Ary Borenszweig wrote:
>  > In D:
>>
>> class Foo {
>>
>> private {
>>     int x, y;
>> }
>>
>> static {
>>     float SomeGlobalVariable;
>>
>>     this() {
>>         // Do some global initializations
>>     }
>> }
>> }
>>
>> Nope, no compiler warning here either.
>>
>> At least Eclipse gives you a warning saying "That method's name is the same as the class' name". :-)
> 
> Static constructors are allowed, they don't replace the regular constructor.  Or wasn't that what you meant?

That was exactly what I meant, thanks for the response. :-)

Try compiling and running these:

1.
---
import std.stdio;

class X {
	static this() {
		writefln("static");
	}
}

void main() {
}
---

2.
---
import std.stdio;

class X {
	static {
            this() {
		writefln("static");
            }
	}
}

void main() {
}
---

Walter Bright Wrote:

> An interesting and sometimes amusing read:
> 
> http://yosefk.com/c++fqa/
The chapter about iostream tells me why I do not like Tango's IO :-)

But I wonder if the following is also true for D:
----snip---
[10.1] What's the deal with constructors?

FAQ: A constructor initializes an object given a chunk of memory having arbitrary (undefined) state, the way "init functions" do. It may acquire resource like memory, files, etc. "Ctor" is a common abbreviation.

FQA: That's right - constructors initialize objects. In particular, constructors don't allocate the chunk of memory used for storing the object. This is done by the code calling a constructor.

The compiler thus has to know the size of a memory chunk needed to store an object of a class (this is the value substituted for sizeof(MyClass)) at each point where the class is used. That means knowing all members (public & private). This is a key reason why changing the private parts of a C++ class definition requires recompilation of all calling code, effectively making the private members a part of the public interface.

---snap---

Given the compilation speed of DMD, it does not bother me, but still, he has a point here.

Ciao
Tom

TomD wrote:
> But I wonder if the following is also true for D:
*snip*

I believe it is.  If you take a look at .di files generated by DMD you will see they contain all of a class's instance variables (public and private).  They also contain implementations of certain methods and constructors (usually short ones), presumably for inlining.

While it does violate encapsulation to some extent (ideally, I shouldn't have to know how big a class is to create an instance of it, and I shouldn't need to recompile client code if I add an instance variable) the amount of harm done is small IMHO, and allowing inlining of small class methods (and constructors) is well worth it.

Also, in case someone wants to truly hide the implementation, it's always possible to make an interface of all the public functions, and a factory function for creating instances, and put the actual implementation class in another module.

Thanks,
Nathan Reed

Ary Borenszweig wrote:
> Try compiling and running these:
> 
> 1.
> ---
> import std.stdio;
> 
> class X {
>     static this() {
>         writefln("static");
>     }
> }
> 
> void main() {
> }
> ---
> 
> 2.
> ---
> import std.stdio;
> 
> class X {
>     static {
>             this() {
>         writefln("static");
>             }
>     }
> }
> 
> void main() {
> }
> ---

Has this been reported as a bug?

Regan

Regan Heath wrote:
> Ary Borenszweig wrote:
>> Try compiling and running these:
>>
[snip normal "static this" version]
>> 2.
>> ---
>> import std.stdio;
>>
>> class X {
>>     static {
>>             this() {
>>         writefln("static");
>>             }
>>     }
>> }
>>
>> void main() {
>> }
>> ---
> 
> Has this been reported as a bug?

IIRC Walter has said that "static this" needs to be two adjacent tokens for it to be parsed as such, and this is not a bug but working as designed.
I'm not sure whether this is a good thing or not, but it's the current state of affairs.

Frits van Bommel wrote:
> Regan Heath wrote:
>> Ary Borenszweig wrote:
> [snip normal "static this" version]
>>> 2.
>>> ---
>>> import std.stdio;
>>>
>>> class X {
>>>     static {
>>>             this() {
>>>         writefln("static");
>>>             }
>>>     }
>>> }
>>>
>>> void main() {
>>> }
>>> ---
>>
>> Has this been reported as a bug?
> 
> IIRC Walter has said that "static this" needs to be two adjacent tokens for it to be parsed as such, and this is not a bug but working as designed.

And it's not only "Walter said", it's been explicitly stated in the doc for as long as I can remember: http://digitalmars.com/d/1.0/class.html#StaticConstructor

"The static in the static constructor declaration is not an attribute, it must appear immediately before the this"

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi

Matti Niemenmaa escribió:
> Frits van Bommel wrote:
>> Regan Heath wrote:
>>> Ary Borenszweig wrote:
>> [snip normal "static this" version]
>>>> 2.
>>>> ---
>>>> import std.stdio;
>>>>
>>>> class X {
>>>>     static {
>>>>             this() {
>>>>         writefln("static");
>>>>             }
>>>>     }
>>>> }
>>>>
>>>> void main() {
>>>> }
>>>> ---
>>> Has this been reported as a bug?
>> IIRC Walter has said that "static this" needs to be two adjacent tokens
>> for it to be parsed as such, and this is not a bug but working as designed.
> 
> And it's not only "Walter said", it's been explicitly stated in the doc for as
> long as I can remember: http://digitalmars.com/d/1.0/class.html#StaticConstructor
> 
> "The static in the static constructor declaration is not an attribute, it must
> appear immediately before the this"
> 

Yeah, for me it's not a bug either. I just wanted to point out that also in D there are some things that may not be that obvious to a newcomer. But it's not a big deal (same as "void foo()" isn't a big deal in the previous example).