November 27, 2011
Whenever i see articles like http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/ i keep wondering why they are so silent in this newsgroup,
I am sure they keep an eye on D. I would expect some kind of contribution (as in suggestions, proposes...).
They are the top C++ developers, pushing language's capabilities. So, if someone is annoyed by the limits of C++, that would be them.
Forget everything, i was thinking that the generic capabilities of D alone is enough to attract all the boost crowd.

Phew, had to get it out.
November 27, 2011
Am 27.11.2011 17:32, schrieb so:
> Whenever i see articles like
> http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/ i keep
> wondering why they are so silent in this newsgroup,
> I am sure they keep an eye on D. I would expect some kind of
> contribution (as in suggestions, proposes...).
> They are the top C++ developers, pushing language's capabilities. So, if
> someone is annoyed by the limits of C++, that would be them.
> Forget everything, i was thinking that the generic capabilities of D
> alone is enough to attract all the boost crowd.
>
> Phew, had to get it out.

Why switch state of the art C++ compilers with years of optimizations built-in and tooling by D?

This is the type of questions I sometimes have to answer, and as much as
I would like to have a language like D replace C++, myself I end up using C++ when the need for native code on our applications arise.

--
Paulo
November 27, 2011
On Sun, 27 Nov 2011 19:13:46 +0200, Paulo Pinto <pjmlp@progtools.org> wrote:

> Why switch state of the art C++ compilers with years of optimizations built-in and tooling by D?

Tool and compilers come eventually, especially after big players attend in discussions.
I don't understand this reasoning really, what everyone expect from language evolution?
Are we expecting some big company do this? Without any feedback from programmer community, in their inner circles?
We know there are many like that and none of them fulfilling our needs.

> This is the type of questions I sometimes have to answer, and as much as
> I would like to have a language like D replace C++, myself I end up using C++ when the need for native code on our applications arise.

So do i, but that doesn't mean one should remain silent at the time of big developments to very problems C++ is facing.
Even Herb Sutter broke his silence and mentioned D here and there, considering his position on the development of another language/compiler, shouldn't others be more vocal?
This is not a fantasy anymore, we have working compilers and a grand community.
November 28, 2011
On 11/27/11 10:32 AM, so wrote:
> Whenever i see articles like
> http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/ i keep
> wondering why they are so silent in this newsgroup,
> I am sure they keep an eye on D. I would expect some kind of
> contribution (as in suggestions, proposes...).
> They are the top C++ developers, pushing language's capabilities. So, if
> someone is annoyed by the limits of C++, that would be them.
> Forget everything, i was thinking that the generic capabilities of D
> alone is enough to attract all the boost crowd.
>
> Phew, had to get it out.

The dynamics and psychology at play are, IMHO, a fair amount more complex. I'm saying this as one who has lived such.

Mastering a difficult language (and probably skill in general) is to some extent like acquiring some power or money - it puts the subject in a conservative position where she'd try to expand the use of the language for tasks not playing into the language's strength, as opposed to achieving the tasks by escaping the language. That explains e.g. why people are willing to use C++'s preprocessor for tasks that would be trivial for m4 or even bash, or that people try all sorts of systems-level coding in languages not adequate for that.

I've had a sort of awakening during my first year in grad school. A professor was teaching constraint logic programming (CLP) and I noted to him that many CLP constructs could be expressed in C++ templates quite nicely. (That prediction was correct, see http://www.mpprogramming.com/cpp.) He (knowing my past) suggested kindly that I'd do good to think more broadly instead of trying to emulate everything I come across in C++. And right he was.

Many C++ programmers have heard about D, but it would be naive to think they'd just stop looking solutions to problems in C++, just because those problems have a good solution in D.


Andrei
November 28, 2011
I'm trying to switch from C++ to D. But I can't find some things that I love in C++. For example in C++ I can separate module specification and implementation. Advertising article "The Case for D" says that it is real in D too:

"D has a true module system that supports separate compilation and generates and uses module summaries (highbrowspeak for "header files") automatically from source, so you don't need to worry about maintaining redundant files separately, unless you really wish to, in which case you can. Yep, that stops that nag right in mid-sentence."

But it is not true...
November 28, 2011
On 11/27/2011 4:44 PM, Alexey Veselovsky wrote:
> "D has a true module system that supports separate compilation and
> generates and uses module summaries (highbrowspeak for "header files")
> automatically from source, so you don't need to worry about
> maintaining redundant files separately, unless you really wish to, in
> which case you can. Yep, that stops that nag right in mid-sentence."
>
> But it is not true...

How is it not true?
November 28, 2011
On 11/27/2011 9:53 AM, so wrote:
> Even Herb Sutter broke his silence and mentioned D here and there,

Herb is a very nice (and very smart) guy, and when I've heard him talk about D he's been very complimentary about our efforts.
November 28, 2011
On 11/27/2011 06:44 PM, Alexey Veselovsky wrote:
> I'm trying to switch from C++ to D. But I can't find some things that I love in C++. For example in C++ I can separate module specification and implementation. Advertising article "The Case for D" says that it is real in D too:
> 
> "D has a true module system that supports separate compilation and generates and uses module summaries (highbrowspeak for "header files") automatically from source, so you don't need to worry about maintaining redundant files separately, unless you really wish to, in which case you can. Yep, that stops that nag right in mid-sentence."
> 
> But it is not true...

dmd -H [file] -c
generates the header file for you quite nicely.

no offense, I think you need a little help..
if you are on linux, man dmd is your friend. tells you all of the
options and what they do.
if you are not on linux, get on linux. (or use dmd --help... but
mainly get linux)
November 28, 2011
WB> How is it not true?
J> dmd -H [file] -c generates the header file for you quite nicely.

ok. Let's a see:

C++ code.

Specification:

// test.hpp file
#ifndef _test_hpp_
#define _test_hpp_

void foo();

struct Boo
{
public:
    void boo();
private:
    struct S {};
};

#endif

Implementation:

// file test.cpp
#include "test.hpp"

struct HelperStruct {}; // private struct for this module only

static void foo_helper() {HelperStruct s;}

void foo() { foo_helper(); }

void Boo::boo() { S ss; foo_helper(); } // method implementation in
implementation side, not in specification!

Module usage:

// file main.cpp
#include "test.hpp"

int main() {
    foo();          // ok
    Boo b;          // ok
    b.boo();        // ok
    Boo::S ss;      // error: struct Boo::S is private
    HelperStruct s; // error: HelperStruct was not declared in this scope
    return 0;
}

Now, let's try this on D:

// Implementation
module test;

public {
    void foo() {foo_helper();}

    struct Boo
    {
    public:
        void boo() {S ss; foo_helper();}
    private:
        struct S {};
    }
}

private {
    struct HelperStruct {};
    void foo_helper() {HelperStruct s;}
}

// Specification (generated by dmd -H test.d -c) -- test.di file
// D import file generated from 'test.d'
module test;
public
{
    void foo() {foo_helper();}

    struct Boo
    {
        public
        {
            void boo() {S ss; foo_helper();}
            private struct S{}
        }
    }
}

private
{
    struct HelperStruct{}
    void foo_helper(){HelperStruct s;}
}

Usage:
import test;

void main() {
    foo();          // ok
    Boo b;          // ok
    b.boo();        // ok
    Boo.S ss;       // ok (wtf?)
    HelperStruct s; // ok (wtf?!)
}


First of all I can't see difference between D's implementation and generated specification. It looks like copy&paste. At second private section not protect types from usage from other modules.  Also I can't write method implementation in different (implementation) file (without inheritance).

Also there are no compiler check for test.di & test.d conformance.

In D I expect real module system like in Modula or Ada. Or at least as in C++ (or way to emulate it). But...

PS. DMD32 D Compiler v2.056
November 28, 2011
On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright <newshound2@digitalmars.com> wrote:

> On 11/27/2011 4:44 PM, Alexey Veselovsky wrote:
>> "D has a true module system that supports separate compilation and
>> generates and uses module summaries (highbrowspeak for "header files")
>> automatically from source, so you don't need to worry about
>> maintaining redundant files separately, unless you really wish to, in
>> which case you can. Yep, that stops that nag right in mid-sentence."
>>
>> But it is not true...
>
> How is it not true?

I don't know if .di generation from .d or .h is any good or bad,
but the comparison of auto-generated .di files to hand crafted .h files doesn't make sense.
« First   ‹ Prev
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home