August 21, 2004
> # volatile {
> #    tmp = new Singleton();
> #    // do stuff
> # }
> 
> 
> Sean
> 
> 

What type is tmp? Wouldn't you get a compiler error if you don't put the  type or will the compiler automatically know like with um, well I can't think of an example.
August 21, 2004
In article <cg3n60$2oap$1@digitaldaemon.com>, Walter says...
>
>Lots more bug fixes. Added special 'length' inside array [ ]'s.
>
>http://www.digitalmars.com/d/changelog.html
>
>

Walter: Thxs a lot for adding in the ifind() and irfind() functions into the
std.string...I'll be putting them to good use! :))

Also, will you be adding in the ireplace() and icount() as well? I wrote them up
and put them in a link just below ifind() functions back in mid-june, I'm not
sure if you want me to resubmit them or not.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
August 21, 2004
In article <cg6bs8$1325$1@digitaldaemon.com>, Gold Dragon says...
>
>> # volatile {
>> #    tmp = new Singleton();
>> #    // do stuff
>> # }
>> 
>> 
>> Sean
>> 
>> 
>
>What type is tmp? Wouldn't you get a compiler error if you don't put the
>  type or will the compiler automatically know like with um, well I
>can't think of an example.

Its type is Singleton.  tmp was delcared in the first line of the function as:

volatile tmp = s;


Sean


August 21, 2004
"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg5tjc$sdr$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message
news:cg59uu$gfi$1@digitaldaemon.com...
> >
> > "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg4b8t$1pd$2@digitaldaemon.com...
> > > Question: what's the purpose of using "volatile" in various places.
Since,
> > AFAIK, D's volatile speaks to intra-thread
> > > memory coherence, and do not cross-thread contention, aren't these
> > superfluous? Or have you come across some secret
> > > wisdom? (If so, send it to me quickly, via the secret T1!)
> >
> > D's volatile has essentially nothing in common with C's, and everything
to
> > do with helping with writing multithreaded apps. I learned about it from Scott Meyer's talk on multithreading. As I recall, it was about
preventing
> > the compiler from moving loads and stores across locks. C++ has no such guarantee, although C++ optimizers in reality respect the locks. This is
the
> > modern understanding of volatile, and both Java and C# have altered
their
> > definitions of volatile to suit as well.
>
> Ok.
>
> But I'll need you to fine-grain some examples for me before that
coallesces into a genuine understanding.
>
> Maybe we can do this in written form somewhere soon? ;)

See the July and August DDJ's by Andrei and Scott. They understand the issues far better than I, and my brain hurts every time I try to figure it out again.


August 21, 2004
Sean Kelly wrote:
> In article <cg6bs8$1325$1@digitaldaemon.com>, Gold Dragon says...
> 
>>># volatile {
>>>#    tmp = new Singleton();
>>>#    // do stuff
>>># }
>>>
>>>
>>>Sean
>>>
>>>
>>
>>What type is tmp? Wouldn't you get a compiler error if you don't put the 
>> type or will the compiler automatically know like with um, well I 
>>can't think of an example.
> 
> 
> Its type is Singleton.  tmp was delcared in the first line of the function as:
> 
> volatile tmp = s;

err... I meant:

volatile Singleton tmp = s;


Sean
August 22, 2004
"antiAlias" <fu@bar.com> wrote in message news:cg61nf$u96$1@digitaldaemon.com...
> You'll forgive me Sean, but the double-locking 'style' was driven out of Java developers after it was shown to be mostly futile (I think it may
have
> been Doug Lea who demonstrated that). The recommended approach over there
is
> to construct singletons statically; which is where a 'static final' assignment would be really useful in D:
>
> static final Whatever singleton = new Whatever (...);
>
> I know you've run into this need before. For those who don't know, the D approach is thus:
>
> static Whatever singleton;
>
> static this()
> {
>     singleton = new Whatever (...);
> }
>
> Would be nice to have the former syntactic-sugar; but I imagine it would
add
> the same compiler complexity as static-constructors do, in terms of
figuring
> out the interdependencies across multiple related 'static final' assignments.
>
> Which leads to a question: how does the compiler deal with circular dependencies across static-constructors? Let's try it out ...
>
> class A
> {
>         static B b;
>
>         static this()
>         {
>                 printf ("A\n");
>                 b = new B;
>         }
> }
>
> class B
> {
>         static A a;
>
>         static this()
>         {
>                 printf ("B\n");
>                 a = new A;
>         }
> }
>
> Note that I wouldn't recommend this as a practice to anyone, but it may occur accidentally where multiple modules are involved (I've done that
with
> Mango). No compile errors ~ emits:
> A
> B
>
> In fact, the only obvious means to get the output in a different order is
to
> switch the class order within the file; that is, placing B above A yields:
> B
> A
>
> Is there no dependency checking done for static constructors? Is this a
bug?
> Am I being particularly dense today?

Static constructors are simply executed in the lexical order in which they appear.


August 22, 2004
"Sean Kelly" <sean@f4.ca> wrote in message news:cg62jg$umv$1@digitaldaemon.com...
> I was wondering about this.  What if A and B were in separate modules?

You'll get an error about circular dependencies.


August 27, 2004
In article <cg7361$1mmk$1@digitaldaemon.com>, Walter says...
>
>See the July and August DDJ's by Andrei and Scott. They understand the issues far better than I, and my brain hurts every time I try to figure it out again.

The discussions on threading in comp.std.c++ are getting pretty involved, so any of those would be a good resource.  And lurking on comp.lang.threads is always helpful, though it can take some searching to catch up on the lingo.  It seems there's a pretty big movement towards lockless thread synchronization, and D is already in a better position than most other languages to take advantage of this.  I know that Ben was working on some lockless containers... I'll have to find some time to check them out.


Sean


1 2 3 4 5 6
Next ›   Last »