"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:fe6f68$1gm8$1@digitalmars.com...
<snip>
> 3. How about making it so that D dynamic array parameters become, on the C++ side, two parameters: length and pointer?

I've just been thinking a bit more about this.  I guess it's just a matter of name mangling - I haven't checked, but it would appear from the old printf-on-strings issue that pushing two arguments in succession is equivalent to pushing the concatenation of (the memory representations of) them in one go.  (Is this platform dependent?)

It's safer in C++ than in C, because if the writer of the C++ code misremembers which way round they go, the mangled names won't match.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies on the 'group where everybody may benefit. 

Stewart Gordon wrote:
> "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:fe6f68$1gm8$1@digitalmars.com...
> <snip>
>> 3. How about making it so that D dynamic array parameters become, on the C++ side, two parameters: length and pointer?
> 
> I've just been thinking a bit more about this.  I guess it's just a matter of name mangling - I haven't checked, but it would appear from the old printf-on-strings issue that pushing two arguments in succession is equivalent to pushing the concatenation of (the memory representations of) them in one go.  (Is this platform dependent?)

With printf() it probably just works because it uses C-style varargs and the two elements of a char[] happen to both be the "native" size of the processor (so there's no padding inserted).
It may not even work on all platforms.

Also, AFAIK the compiler would be well within its rights to use the opposite order of .length and .ptr in memory; meaning that even if the C calling convention allows this the order they're passed in isn't guaranteed.

"Frits van Bommel" <fvbommel@REMwOVExCAPSs.nl> wrote in message news:fe995o$3de$1@digitalmars.com...
<snip>
> Also, AFAIK the compiler would be well within its rights to use the opposite order of .length and .ptr in memory; meaning that even if the C calling convention allows this the order they're passed in isn't guaranteed.

Not according to
http://www.digitalmars.com/d/abi.html

But one thing that might affect whether it works is if, on a given system, the memory layout of the stack goes the other way or is even non-linear.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies on the 'group where everybody may benefit. 

> Bug fixes. New (and very modest) C++ interface. Library module overhauls by Andrei Alexandrescu. Brad Roberts is working behind the curtain to get phobos development much better organized.
This is all very good :)

With C++ interfaces, is D able to do anything similar to "all functions that are not overridden can be optimized to be non-virtual"? And is the lack of support for static and non-virtual members because it is infeasible or in-expressible?

 - Paul

Paul Findlay wrote:
>> Bug fixes. New (and very modest) C++ interface. Library module overhauls
>> by Andrei Alexandrescu. Brad Roberts is working behind the curtain to
>> get phobos development much better organized.
> This is all very good :)
> 
> With C++ interfaces, is D able to do anything similar to "all functions that
> are not overridden can be optimized to be non-virtual"?

The C++ interface only extends to the calling convention, name mangling, and vtbl[] layout. No other C++ rules are followed.

> And is the lack of
> support for static and non-virtual members because it is infeasible or
> in-expressible?

I thought we'd see how far we get with this first.

Walter Bright wrote:
> Sean Kelly wrote:
>> For what it's worth, Tango will never choose to run exclusively on the Phobos runtime.  One of the primary reasons many people choose Tango is for its threading package, and this is a runtime feature. Therefore, dropping this package to use the Phobos version would be foolish, and I suspect that it would leave a number of Tango users (some developing professional software) in a bit of a lurch.
> 
> The threading package in Phobos is not very good, as it is based on my very poor understanding of the problem. Drop kicking std.thread is certainly open for discussion for v2. I wouldn't shed a tear for it <g>.
> 

Maybe I'm missing something here; maybe it's because Phobos' threading
is all I ever used, but what's wrong with it?
I mean, it's threads .. you can start them, halt them, run stuff in them
.. what more is needed? It's a very basic implementation, very close to
the OS; but thanks to synchronized, I generally found it easy to add the
primitives I needed.
Somebody kindly explain. Thanks.

  --downs, confused critter

On Sun, Oct 07, 2007 at 05:36:08AM +0200, downs wrote:

>> The threading package in Phobos is not very good, as it is based on my
>> very poor understanding of the problem. Drop kicking std.thread is
>> certainly open for discussion for v2. I wouldn't shed a tear for it <g>.
>
>Maybe I'm missing something here; maybe it's because Phobos' threading
>is all I ever used, but what's wrong with it?
>I mean, it's threads .. you can start them, halt them, run stuff in them
>.. what more is needed? It's a very basic implementation, very close to
>the OS; but thanks to synchronized, I generally found it easy to add the
>primitives I needed.

I don't know much (if anything) about threading on Windows, but the Linux
threading code is not really all that useful.  Without either reaching
under the hood or bypassing D's synchronized entirely, there is no way to
even build the right primitives to get to condition variables, so
synchronization isn't even possible.  It is possible to create independent
threads that do separate things, but not to have them really interact with
each other.

I think it is important to have thread synchronization primitives as part
of the basic threading library that work the same on all platforms.  This
greatly helps portability of threaded programs.

.NET uses something similar to 'synchronized', although they also provide
methods for providing visibility into the mutex itself.  They use condition
variables.  I wouldn't suspect these are that difficult to implement on
Windows.

David

David Brown wrote:
> On Sun, Oct 07, 2007 at 05:36:08AM +0200, downs wrote:
> 
>>> The threading package in Phobos is not very good, as it is based on my very poor understanding of the problem. Drop kicking std.thread is certainly open for discussion for v2. I wouldn't shed a tear for it <g>.
>>
>> Maybe I'm missing something here; maybe it's because Phobos' threading
>> is all I ever used, but what's wrong with it?
>> I mean, it's threads .. you can start them, halt them, run stuff in them
>> .. what more is needed? It's a very basic implementation, very close to
>> the OS; but thanks to synchronized, I generally found it easy to add the
>> primitives I needed.
> 
> I don't know much (if anything) about threading on Windows, but the Linux threading code is not really all that useful.  Without either reaching under the hood or bypassing D's synchronized entirely, there is no way to even build the right primitives to get to condition variables, so synchronization isn't even possible.  It is possible to create independent threads that do separate things, but not to have them really interact with each other.
> 

I think the problem is that people get so used to their favorite
threading primitives that they  believe synchronization and multiple
threads working together is entirely impossible without them.
As somebody who has written multithreaded programs using exclusively D's
and Phobos' threading primitives, let me assure you that it is very much
possible :)

With that in mind, I'd kindly ask you to describe some basic, common situation that you believe is outright impossible to do with Phobos' threading, because I honestly can't see any.

Thanks in advance :)
 --downs, Phobos fanboy

On Sun, Oct 07, 2007 at 07:07:09AM +0200, downs wrote:

>I think the problem is that people get so used to their favorite
>threading primitives that they  believe synchronization and multiple
>threads working together is entirely impossible without them.
>As somebody who has written multithreaded programs using exclusively D's
>and Phobos' threading primitives, let me assure you that it is very much
>possible :)

Not the case at all.  My original intent was to look into phobos and see
what primitives were available.  Phobos threads have 'synchronized' which
is part of the grammar of the language.  Apparently, windows has some
mechanisms that work well with this to provide the rest of the necessary
mechanisms.  The linux synchronization primitive does not work with the
D/Phobos 'synchronized' primitive, since the mutex used to make the lock is
not accessible.

In either case, there is no way to do a portable threading program, since
it requires access to other os-dependent features to do anything useful.

>With that in mind, I'd kindly ask you to describe some basic, common
>situation that you believe is outright impossible to do with Phobos'
>threading, because I honestly can't see any.

I'll give an inverse challenge (which I'm going to try and meet, see
below): Implement a standard threading problem, such as bounded buffers
using only the Phobos thread primitives.  The solution may not use anything
outside of std.thread for synchronization.

All completely threading interprocess coordination mechanisms are
functionally equivalent.  Ones that use shared memory (threads) boil down
to two things:

  1.  A way to provide exclusive access of a piece of memory.
  2.  A way for a thread to block and be awoken by another thread.

Phobos provides #1 through 'synchronized' and #2 possibly through
pause/resume on threads.  Windows provides other mechanisms for #2 that are
probably easier to use.  Linux provides condition variables that can't be
used with 'synchronized' blocks in D.

The rest becomes a matter of convenience, and how easy the mechanism is to
use correctly.

I'm going to take it as an exercise to implement the bounded buffer problem
in D using only std.thread and nothing else.  I will post the code here
when I am finished.

David

Sure, on it.
This should work .. at a glance, I wasn't able to find any cases where
it deadlocks.
I made an unbounded buffer, because it seemed easier ^_____^

module test4;

import std.thread;
class UnBoundedBuffer(T) {
  private {
    T[] buffer;
    bool[Thread] waiting;
    Object waiting_sync;
  }
  this() { waiting_sync=new Object; }
  void put(T t)
  {
    synchronized(this) buffer~=t;
    while (waiting.length && buffer.length)
      synchronized(waiting_sync)
        foreach (thr, bogus; waiting)
          thr.resume;
  }
  T get()
  {
    synchronized(waiting_sync) waiting[Thread.getThis]=true;
    scope(exit) synchronized(waiting_sync) waiting.remove(Thread.getThis);
    while (true)
    {
      synchronized(this)
        if (buffer.length)
        {
          auto res=buffer[0];
          buffer=buffer[1..$];
          return res;
        }
      Thread.getThis.pause;
    }
  }
}

void main() {
  auto bb=new UnBoundedBuffer!(int);
}