View mode: basic / threaded / horizontal-split · Log in · Help
April 29, 2005
SWIG for D (was Re: Is D taking hold in the C++ world?)
John Demme wrote:
> Looks like there's a copy from August 1st, 2004 on DSource.
> 

Also, John Fletcher wrote up some tips here:
http://www.prowiki.org/wiki4d/wiki.cgi?DwithSwig


> On Fri, 2005-04-29 at 09:17 +1200, Brad Beveridge wrote:
> 
>>John Demme wrote:
>>
>>>The link on the D links page yields a 404.  Where's Andy's site
>>>nowadays?
>>>
>>>Also, is there a tutorial for this?
>>>
>>>John Demme

-- 
jcc7
http://jcc_7.tripod.com/d/
April 29, 2005
Re: Is D taking hold in the C++ world?
"Vladimir" <kv11111@mail.ru> wrote in message 
news:d4tsjv$1ate$1@digitaldaemon.com...
> Walter wrote:
>
>>
>> "Vladimir" <kv11111@mail.ru> wrote in message
>> news:d4qvmu$114p$2@digitaldaemon.com...
>>> Matthias Becker wrote:
>>>
>>> > Bad library, not even the basic collections you find everywhere. So D
>>> > is unusable in any kind of project.
>>> >
>>> >
>>> > A few C++ programmers see things like built in hash-tables and ask why
>> the
>>> > languages is bloated with stuff like that, which could be done in the
>>> > library and then don't even give it a try.
>>> That was my first feeling after reading intro on digitalmars site.
>> Benefits
>>> described here seems not convincingly for me.
>>
>> The text can always be improved. What would be a convincing intro be for
>> you?
>
>
> First informative link from front page is a link to comparation table. 
> First
> look at this table shows that D has more features than others. But more
> detailed look shows that many of this features are not missing in other
> languages but raser implemented as libraries. Reasons for doing it in
> compiler are not described here.
>
> It's not obvious that moving a big part of library into compiler is good.
> Many people even convinced that this is evil, and have a reasons for it.
> So, if doing so, *very* *good* description of it's benefits must be 
> written
> and placed just beside saying thad D has built-in dynamic and assosiative
> arrays. Without it a lot of C/C++ programmers just stop reading here.
>
> The most confusing section is about arrays. Reading page "D Strings vs C++
> Strings" which is linked from here one can agree
> that C++ STL library is far from ideal, and some changes to compiler (such
> as adding overloadable ~ operator) are also helpful, but there is no 
> reason
> to built-in library into compiler.
> As for me, more convincing points is possible optimizations, more standard
> implementation (no more difference between STL string, QT QString, and 
> many
> others), reference semantics, but these all are at the bottom of the page.
>
> Absence of "How Garbage Collection Works" part is also bad. For many C/C++
> programmers GC is associated with java/C# and VMs which are slow. Section
> "How Garbage Collection Works" is the only chance to be convinces that 
> this
> really can be not-so-slow (especially for those who does not belive
> advertisements). May be adding this link:
> http://www.iecc.com/gclist/GC-faq.html
> and even this:
> ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps
> would be helpful.

I pretty much agree that the D web site could use more description for the 
pros and cons for certain design decisions. The sections comparing D with 
other languages could have a FAQ all its own that gives the rationale behind 
the decisions. We've had thread after thread about certain decisions and if 
Walter explained himself just once (or sometimes "at all") on the web site 
it would help stream-line the newsgroup discussion and it would help people 
coming from other languages understand the factors that led to the current 
design. Instead of this "rationale" page being aimed at pushing D it would 
take a balanced view of the issue and explain why the decision in D was what 
it was. It would help give a less "rah-rah" feel to the comparisons with 
other languages and make it more informative.
April 29, 2005
Re: Is D taking hold in the C++ world?
>> /// @brief Struct with reference.
>> ///
>> /// Dear user. Please use only reference types
>> /// (objects or pointers) for T. Thank you.
>> ///
>> struct RefTo(T)
>> {
>>    T reference;
>> }
>
> You can build that restriction into the template!
>
> struct RefTo(T:Object)
> {
>     T reference;
> }
>
> struct RefTo(T: T*)
> {
>     T* reference;
> }
>
>     RefTo!(int *) X;    // works
>     RefTo!(int) Y;    // fails

Yes, but it is annoying for larger templates to define it twice if most of  
the functions are the same. But one could use a "restricting sub-template":


template UseOnlyPointersForRefTo(T : Object)
{}

template UseOnlyPointersForRefTo(T : T*)
{}

struct RefTo(T)
{
private:
  T m_data;

  // Dear user: If this fails, then you did not use an Object or
  // a pointer as type T.
  mixin UseOnlyPointersForRefTo!(T);

public:
  // Lots of lengthy functions...
}


By the way, mixins are great!

Ciao
uwe
April 29, 2005
Re: Is D taking hold in the C++ world?
Ben Hinkle wrote:
> "Vladimir" <kv11111@mail.ru> wrote in message 
> news:d4tsjv$1ate$1@digitaldaemon.com...
...
>>>The text can always be improved. What would be a convincing intro be for
>>>you?
>>
>>
>>First informative link from front page is a link to comparation table. 
>>First
>>look at this table shows that D has more features than others. But more
>>detailed look shows that many of this features are not missing in other
>>languages but raser implemented as libraries. Reasons for doing it in
>>compiler are not described here.

...

>>Absence of "How Garbage Collection Works" part is also bad. For many C/C++
>>programmers GC is associated with java/C# and VMs which are slow. Section
>>"How Garbage Collection Works" is the only chance to be convinces that 
>>this
>>really can be not-so-slow (especially for those who does not belive
>>advertisements). May be adding this link:
>>http://www.iecc.com/gclist/GC-faq.html
>>and even this:
>>ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps
>>would be helpful.
> 
> 
> I pretty much agree that the D web site could use more description for the 
> pros and cons for certain design decisions. The sections comparing D with 
> other languages could have a FAQ all its own that gives the rationale behind 
> the decisions. We've had thread after thread about certain decisions and if 
> Walter explained himself just once (or sometimes "at all") on the web site 
> it would help stream-line the newsgroup discussion and it would help people 
> coming from other languages understand the factors that led to the current 
> design. Instead of this "rationale" page being aimed at pushing D it would 
> take a balanced view of the issue and explain why the decision in D was what 
> it was. It would help give a less "rah-rah" feel to the comparisons with 
> other languages and make it more informative. 

I think "if Walter explained himself just once (or sometimes 'at all') 
on the web site" vs. having the same argument on the newsgroup 
over-and-over again is an excellent point. Certainly some of the 
perpetual hot topics could be more thoroughly described in the web pages.

On the other hand, some people seem to start posting complaints after 
reading only a couple paragraphs (perhaps my perspective is screwed up 
since I spent so much time as a lurker before I started posting). I 
think we'll alway have some people who would rather start arguing about 
how everything about D is wrong before they read the whole spec, but it 
would be good if the specification could highlight more of the deep 
thinking that went into the design of D.

-- 
jcc7
http://jcc_7.tripod.com/d/
April 29, 2005
Re: Is D taking hold in the C++ world?
Ben Hinkle wrote:
>>I half agree and half disagree.  I think that Walter made a very good 
>>point when he said that copy constructors are trouble; you are making a 
>>similar point by saying that we don't want to pass objects by value.
>>
>>So why not just ban passing classes by value?  That is, the following code 
>>would be illegal:
>>class Foo {};
>>int myFunc(Foo pass_by_value) {...}
>>it would give an error:
>>ERROR: Class objects cannot be passed by value.
>>They must be passed by pointer instead.
>>
>>Likewise, any code that required copying a class by value would be 
>>illegal.  Offhand, I can think of:
>>* Class values as function parameters
>>* Class values as function return values
>>* Direct object assignments
> 
> That is an option but I think it would be one of last resort. A type should 
> be usable by itself - if taking pointers to something is required in order 
> to make it useful then that should be built into the type. Also by building 
> reference semantics into object you avoid silly typedefs like
> typedef Window_t* Window;
> I dislike C/C++ code that hides pointers behind typedefs. The typedef only 
> becomes usable when it has some obvious naming convention like WindowRef and 
> at that point WindowRef is pretty much the same as Window_t* so why bother.

I agree, I hate those types of typedefs.  But aren't you advocating 
exactly that by advocating reference semantics?  What is the difference, 
from a practical point of view, between
	(In a value-semantics language)
	class Window_t {};
	typedef Window_t* Window;
and
	(In a reference-semantics language)
	class Window {};

Aren't we doing the same thing in both cases?
April 29, 2005
Re: Is D taking hold in the C++ world?
Uwe Salomon wrote:
>> Say that you want to store a pointer to a type in a template struct.  
>> Do  you do this?
>>     struct RefTo(T) {
>>       T reference;
>>     }
>> which works for classes, or this
>>     struct RefTo(T) {
>>       T *pointer;
>>     }
>> which works for structs?  Sure, you can do specialized templates, but  
>> that's a kludge to work around the problem, IMHO.
> 
> 
> You declare this:
> 
> /// @brief Struct with reference.
> ///
> /// Dear user. Please use only reference types
> /// (objects or pointers) for T. Thank you.
> ///
> struct RefTo(T)
> {
>   T reference;
> }
> 
> And then this:
> 
> class Klasse { ... }
> struct Struktur { ... }
> 
> RefTo!(Klasse) klasseRef;
> RefTo!(Struktur*) strukturRef;
> 
> Does even have the same semantics:
> 
> klasseRef.store(new Klasse);
> strukturRef.store(new Struktur);

Sure.  I didn't mean to imply that you could not.  But your solution 
then forces this complexity throughout all other types which use the 
template.  Say that you had some other templates:
	struct Foo(T) { RefTo!(T) ref; }
	struct Bar(T) { Foo!(T)   foo; }
	struct Baz(T) { Bar!(T)   bar; }
Now, you have to percolate the restriction all the way up to the Baz 
template.
April 29, 2005
D++ (was Re: Is D taking hold in the C++ world?)
Russ Lewis wrote:
> Don't get me wrong - I still use D all the time.  Except for work, I 
> don't even touch C and C++ anymore.  But if I ever write D++, this will 
> be one thing that I will change. :)

Sorry to break it to you, but someone has already written D++. In fact, 
it's already at version 4.1. ;)

Perhaps D# is still available as a name.


D++: http://www.pagemac.com/dpp/index.php


What is D++?

D++ is a scripting language programmed in Microsoft Visual Basic 6... 
you know what? I think I've already written this. Perhaps you should all 
the info on the about page, as it's far more detailed than this is going 
to get. (From the D++ FAQ)


(By the way, I just found out about D++ today due to its link at 
http://www.kochandreas.com/home/language/matrix.htm. I wonder how many 
more people might stumble upon D if it were listed.)

-- 
jcc7
http://jcc_7.tripod.com/d/
April 29, 2005
Re: Is D taking hold in the C++ world?
"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message 
news:d4u49n$1ioj$1@digitaldaemon.com...
> Ben Hinkle wrote:
>>>I half agree and half disagree.  I think that Walter made a very good 
>>>point when he said that copy constructors are trouble; you are making a 
>>>similar point by saying that we don't want to pass objects by value.
>>>
>>>So why not just ban passing classes by value?  That is, the following 
>>>code would be illegal:
>>>class Foo {};
>>>int myFunc(Foo pass_by_value) {...}
>>>it would give an error:
>>>ERROR: Class objects cannot be passed by value.
>>>They must be passed by pointer instead.
>>>
>>>Likewise, any code that required copying a class by value would be 
>>>illegal.  Offhand, I can think of:
>>>* Class values as function parameters
>>>* Class values as function return values
>>>* Direct object assignments
>>
>> That is an option but I think it would be one of last resort. A type 
>> should be usable by itself - if taking pointers to something is required 
>> in order to make it useful then that should be built into the type. Also 
>> by building reference semantics into object you avoid silly typedefs like
>> typedef Window_t* Window;
>> I dislike C/C++ code that hides pointers behind typedefs. The typedef 
>> only becomes usable when it has some obvious naming convention like 
>> WindowRef and at that point WindowRef is pretty much the same as 
>> Window_t* so why bother.
>
> I agree, I hate those types of typedefs.  But aren't you advocating 
> exactly that by advocating reference semantics?  What is the difference, 
> from a practical point of view, between
> (In a value-semantics language)
> class Window_t {};
> typedef Window_t* Window;
> and
> (In a reference-semantics language)
> class Window {};
>
> Aren't we doing the same thing in both cases?

To me the expectations are different. Since C/C++ doesn't have any 
reference-semantics classes hiding the reference behind a typedef is not 
expected. But in languages where references are implicit it becomes expected 
and so it is less of a problem (unless someone avoids classes and uses a 
struct where they should use a class or vice-versa). But I agree that it is 
true an identifier without any context doesn't give any more information 
about value/reference semantics in D than a typedef does in C++. So in C 
when I see a type without a ptr I assume it is value based and get annoyed 
when the typedef hides it but in D one can't assume the type is value based 
so I have to rely on a guess based on the name or look up the definition. 
Usually that's enough.
April 29, 2005
Re: Is D taking hold in the C++ world?
"Derek Parnell" <derek@psych.ward> wrote in message 
news:2ddk2n5oayb6$.1lycbdczpdp9w$.dlg@40tude.net...
> On Wed, 27 Apr 2005 09:26:18 +1000, Matthew wrote:
>
>> I've read a couple of things recently that've indicated that D's 
>> not
>> taken seriously by the C++ world.
>
> I'm not in the C++ plus world, nor are my professional colleagues, 
> but I'm
> wondering if D's target audience is not the current C/C++/C#/Java 
> crowd.
> Instead, might it be found in the Perl, Python, Ruby, Euphoria, 
> and
> total-newbie groups that have not been exposed to the foibles of 
> the 'C'
> legacy, and are looking for speed, power, and simplicity?
>
> Would attempting to "sell" to this set of people be a useful 
> exercise?
> --
> Derek
> Melbourne, Australia
> 28/04/2005 5:40:45 PM
April 29, 2005
Re: Is D taking hold in the C++ world?
"Derek Parnell" <derek@psych.ward> wrote in message 
news:2ddk2n5oayb6$.1lycbdczpdp9w$.dlg@40tude.net...
> On Wed, 27 Apr 2005 09:26:18 +1000, Matthew wrote:
>
>> I've read a couple of things recently that've indicated that D's 
>> not
>> taken seriously by the C++ world.
>
> I'm not in the C++ plus world, nor are my professional colleagues, 
> but I'm
> wondering if D's target audience is not the current C/C++/C#/Java 
> crowd.
> Instead, might it be found in the Perl, Python, Ruby, Euphoria, 
> and
> total-newbie groups that have not been exposed to the foibles of 
> the 'C'
> legacy, and are looking for speed, power, and simplicity?
>
> Would attempting to "sell" to this set of people be a useful 
> exercise?

Without built-in regex, it's not going to sell as an alternative to 
Perl or Ruby.

And I can't see how it's ever going to be a credible alternative to 
Python, which takes simplicity and usability to the extreme and, 
perhaps more importantly, a wealth of libraries.

I just don't see D as an alternative to scripting languages. 
DMDScript might, but I've not (yet) used it, and don't really know 
anything about it.

I've always felt that D will be a credible alternative to
   1. C - more OO and built-in GC
   2. C++ - better templates, address some of its imperfections 
(http://imperfectcplusplus.com <g>)
   3. Java - more expressive, better syntax, templates, doesn't 
need a VM
   4. .NET - not vendor locked (or won't be), templates, doesn't 
need a VM

I would think that at the moment it could credibly be said to have 
achieved 1, but is woefully failing on 2 because of significant 
fundamental defects in the language, and failing on 3 and 4 because 
of lack of libraries and IDEs/tools.

Since there's much resistance from Walter to acknowledge/fix the 
defects, and much apathy/nonchalence from most of the community 
about them, I think the likelihood of 2 ever being achieved is 
negligable. It's going to take a real shift in attitude which just 
isn't going to happen. I think Walter's ambitions would be better 
served

But I think that the only impediments to 3 and 4 are time, and 
getting to grips with the gripes - some of which are significant - 
with Phobos. As long as Phobos gets a proper redesign / 
reimplementation, such that it neatly, and orthogonally supports 1 
programming (procedural, non-OO) and 3/4 programming (class-based, 
OO), then I see no reason why D cannot compete strongly on 3 / 4.

So, in summary:

   Will D beat (i.e. be a credible, practicable alternative to):

       Perl - no, because that's not its intent
       Python - no, because that's not its intent
       Ruby - no, because that's not its intent
       C - yes, apart from things that have to be minimally coupled 
and maximally portable to any/all platforms. Big potential here
       C++ - no, because there's no effective desire/purpose to 
address the many reasons why C++ programmers are better off sticking 
where they are. Huge potential here, but would require huge effort. 
Not going to happen this lifetime
       Java - yes, once comprehensive tools and libraries are 
implemented. Big potential. Just a matter of time
       .NET - yes, once comprehensive tools and libraries are 
implemented. Big potential. Just a matter of time. And if D.NET is a 
commercial reality, it can be a takeover, and not a fight

For me, I can certainly live with the prospect of needing to know 
two compiled languages - C++ and D - and two scripting languages - 
Python and Ruby. (Speaking from a programming-as-fun perspective, 
that's almost ideal!) :-)

Thoughts?
3 4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home