the D programming language
Matthew Leverton

(Warning, this is somewhat of a blog post. You can safely skip down to the question at the end if it bores you.)

I've been playing around with the D language for the past couple of days, and I have to say I'm very impressed. My interest is twofold: I'm looking for a language to write my web framework in and I'm interested in using it with Allegro.

For web programming, I've come from a heavy background in scripting with classic ASP (ugh) and PHP. While I like PHP a lot, it (and haphazard scripting in general) breaks down for large scale, framework style of applications. That's not to say it's out of PHP's league, but one can only take so much of the $this->foo syntax before officially going insane. And I've never cared much for Java, so I haven't even given C# a chance.

Unlike Java, D compiles to native code and can (almost) directly interface with C libraries (hence, DAllegro). The first thing I did was create my own wrapper class around libmysqlclient to mimic the style of database access I've come to enjoy with PHP. A side by side comparison:

PHP                                   D
$db = new DB();                       DB db = new DB();
$db->execute("UPDATE foo");           db.execute("UPDATE foo");
$foo = $db->getOne("SELECT foo");     char[] foo = db.getOne("SELECT foo");

$row = $db->getRow("SELECT *");       DBRow row = db.getRow("SELECT *");
echo $row['foo'];                     writef("%s", row["foo"]);

foreach ($db->getAll($sql)) as $row)  foreach(row; db.getAll(sql))
  echo $row['foo']."\n";                writef("%s", row["foo"]);

Obviously C++ can do the same thing, but D is so concise. While I sometimes use C++ for the STL, it is so ugly...

The nice thing about writing in D, as opposed to PHP, is you can bind results directly to variables (without having to go through some invisible conversion):

DBStatement st = db.prepare("SELECT id,name FROM foo");
st.execute();

int id;
char[] name;

st.bindResult(1, id);
st.bindResult(2, name);

while(st.fetch())
{
  writefln("Person #%d's name is %s.", id, name);
}

D can pretty much do everything PHP can do right out of the box, which is impressive considering that it's a compiled language. (Obviously, I'm talking about core language features, not the plethora of PHP C Modules.)

// associative arrays
int[char[]] foo;
foo["pizza"] = 1;

// dynamic arrays
int[] foo;
foo ~= 1;  // foo[0] = 1

While D has no "string" object, it doesn't really need one because of how flexible the arrays are.

char[] foo;
foo = "Hello";
foo ~= ", World";

For a test, I translated the a.cc database indexer line by line from PHP to D. On my Linux VM, it ran almost twice as fast. On the live server, it actually runs the same speed, but it's possible that the database is the bottleneck. Of course, I'm also doing some PHP-like things, so that doesn't help D out.

All-in-all, it really seems nice. In fact, I'd say that D is what C++ should have been. Everything it does is so simple compared to C++...

The Question at the End: Does anyone here use D? Have any favorite features or gripes to share? Why, except for legacy and maturity purposes, would anyone use C++ over D? (I realize it doesn't have many tools, IDEs, etc... I'm asking about the language itself.)

Thomas Fjellstrom

From this and other reviews, I will be trying D out in the near future. And I can't wait till they manage to get some form of C++ support so I can use it with Qt. QtD would rock SO HARD its unimaginable.

Onewing

First off, and I know this is a bad argument, but why do they call it D? That's a horrible name. I'd much rather it be called B or something cute like BFlat or BMinus.

:-X

Jonatan Hedborg

Haven't tried it, seems very nice. How does it handle function pointers? (i use PHP's "string with function name as function-pointer"-thingy in a CMS I'm working with/on)

EDIT: onewing; there is already a A and B. Hence C. And now D :)

nonnus29

I agree with Thomas, I haven't tried it out formally but from all reports D seems very sweet indeed. When I did install a long time ago all the little differences between it and Java gave me the willies.

Your examples are very 'svelte'. The langauge seems awesome. But (and I mean B.U.T.) the lack of library support (or the lack of extensive libraries) is a real hindrance in my opinion. I know you said not to mention this, but in Java there's a library for damn near everything, and often more than one. To me this is to important to ignore.

Edit: I don't mean to campaign for one language over another, I simply mean to say that library support is VERY important in this day and age.

From the regard of cool languages with great library support I currently favor Scala because it mixes SML style constructs and mixins (?) into a language that compiles to Java or .NET bytecode giving access to each platforms extensive libraries.

Thomas Fjellstrom
Quote:

How does it handle function pointers?

Quite well, it has (anonymous) Delegates, Dynamic Closures, Function Literals and plain Function Pointers. The first few are much more usefull than pure function pointers imo.

Goalie Ca

I remember evaluating D a while back.. and all i can remember is the conclusion. D is better but i still think it took the wrong direction.

Right now python is my miracle language. The only thing i haven't checked out yet is boo or ironPython.net. Supposedly those are nice and fast.

C++ is my main workhorse language. It takes a really good coder to make c++ fun and easy to write. The biggest problem with c++ is the lack of true documentation... you know all those little things that programmers have in their head... such as why they chose to do it this way and what consequences this has. I've created a framework for my thesis where it pretty much boiled down to simple clean constructs but the important part is that it is fast and can run on clusters. Extensive use of stl algorithms but not containers. Ironic eh? but it came out really really clean and fast.

Haskell is becoming my "i have a really clever math idea.. lemme test it out" language. Haskell is beautiful to work with graphs or parsing. It is pretty simple and elegant but requires a real appreciation for the underlying math. It's one of those languages only a mathematician/computer scientist can love. I'm an engineer but i love it for its elegance. I just haven't found how to incorporate it into my daily workhorse language.

Matthew Leverton

I dislike the name because its hard to Google for D specific articles. Other than that, I think it's fine and sensible.

Quote:

Haven't tried it, seems very nice. How does it handle function pointers? (i use PHP's "string with function name as function-pointer"-thingy in a CMS I'm working with/on)

Function pointers are called delegates. It also has references and lazy parameters (not evaluated until used). So you almost get the Javascript style of dynamic closures, although it's not quite as powerful. (The scope ultimately gets lost, although this is something that may change in later versions.) However, even as it is now, it has better support than PHP.

D also has real pointers, but you rarely need to use them. For instance:

void foo(inout int a)
{
  a = 1;
}

int x = 0;
foo(x);
// x = 1

Quote:

But (and I mean B.U.T.) the lack of library support (or the lack of extensive libraries) is a real hindrance in my opinion.

But it can interface with C libraries very easily:

extern (C) {
  void library_func(int a); 
}

int main()
{
  int a;
  library_func(a);
}

You can link directly with the .lib file made in C. (If under Windows, the library must be dynamic or built with the Digital Mars C compiler.)

Onewing
Quote:

Other than that, I think it's fine and sensible.

In the scheme of things following the A, B, C, etc. method, D has negative connotation for me. I mean, what's next, F? A language that auto-fails? Now, if they put a colon at the beginning of D, it might be a little better (: + D = :D). There's no negativity in that.

Anywho, I've seen a thread or two around here on D, one about porting allegro to D. It seems to be getting a lot of compliments and I suppose I should check it out before I end up behind.

How OOP can you go with D?

Thomas Fjellstrom
Quote:

How OOP can you go with D?

Basically, D is C++++. Has better support for everything C++ can do, and more (3rd party library support nonwithstanding).

Matthew Leverton

D uses single inheritance with multiple interfaces, mixins, templates, and operator overloading.

I never used templates much in C++ because they are so ridiculously ugly... Does C++ have an equivalent for this?

void templateFunc(T) (T value)
{
  static if (value.typeof.stringof == "int") // sorry if there's a better way to express this
  {
    writefln("Hello!");
  }
}

templateFunc(1000); // prints Hello

templateFunc("Hi"); // nothing

Basically, the static if happens at compile time and the check goes away. (Obviously, you could overload the function in C++, but my example is trivial on purpose.)

Can you do that with the preprocessor and templates in C++? (That's another thing. D has no preprocessor, because it provides elegant solutions for when you normally would have used one.)

Oh, and in addition to all this high level goodness, you can drop into inline assembler too. ;D

bamccaig
Matthew Leverton said:

And I've never cared much for Java, so I haven't even given C# a chance.

I haven't had the chance to learn D, but I have done about 10 C# tutorials and I must say I'm very pleased with it. Looking at your D examples I've gotta say I prefer C# syntax (though the differences in your simple examples look minimal).

The only catch about C# is that it requires a .NET CLR to run, but Mono provides that for *nix environments so it's not a big deal.

I suggest don't avoid C# because of Java; you'll be missing out. I hate Java, but C# is a beautiful language.

Onewing said:

In the scheme of things following the A, B, C, etc. method, D has negative connotation for me.

Seconded... :-/

Matthew Leverton

Regarding C#, I almost commented that I also never tried it because it's essentially controlled by Microsoft and I don't want to be locked in to Windows or have to use a sub-standard open-source implementation. But, I didn't want the thread to turn into an argument over whether or not Microsoft controls C# and if C# on other platforms is sub-standard.

The point is to discuss the good and bad of D. And other than the stuff that would hinder any new language (no IDE, no libraries, etc), I've not come across anything that I've not liked. And personally, I enjoy writing wrapper classes over top existing C libraries, so the lack of official libraries for D doesn't really bother me.

bamccaig
Matthew Leverton said:

void foo(inout a)

What's with inout? :-/ Is that a datatype or a keyword...? :-/ I don't like it, whatever it is...

Matthew Leverton

I should have had a type. (example fixed) The new name is actually "ref" (for reference) but the dmd compiler doesn't support it yet.

bamccaig
Matthew Leverton said:

I should have had a type. (example fixed) The new name is actually "ref" (for reference) but the dmd compiler doesn't support it yet.

ref is a lot better than inout. ;D Sounds like D is going to be an awesome language, but I think I'll wait a while to try it out. :-/ I'll be busy with C# and networking/multi-threading/game programming in C++ for a while... That doesn't include 71/2 hours of Web technologies every weekday... :-/

nonnus29
Quote:

What's with inout? :-/ Is that a datatype or a keyword...? :-/ I don't like it, whatever it is...

Inout is a valid parameter passing style; the value is copied to the function when the function is called and copied back when the function returns. It should be exactly like passing by reference but in some cases it can yield different results. I think it came from Fortran originally, or maybe Algol?

All I know is, when I finish this compiler I'm writing in C I'll never write another line of C as long as I live.... :'( Is there a lex/flex implementation for D?

Thomas Fjellstrom
Quote:

All I know is, when I finish this compiler I'm writing in C

I forget (if I ever knew), what language is the compiler for?

BAF

Are you porting your web framework to D and doing all your web stuff in D?

Jonny Cook

A while ago I looked at D, but I wasn't feeling very adventurous so I didn't get past the FAQ/Documentation/D-C++ comparison. But it seemed like a very good language to me. If an Allegro port is ever made for it I'll definitely try it out, but until then I don't find myself having any use for it (at class we use Java exclusively, and other than that I just do game programming).

The main reason I'm reluctant to use D (if this could be called a reason) is that I'm scared of becoming, well... lazy. It might just be because I started with C/C++ 4 years ago and have pretty much used it exclusively since then, but I feel like I'm somehow cheating by using a language which makes it easier to program than it is in C++. I really like how C++ forces you to have good programming practices, because if you don't you will suffer the consequences, and programming with good practices is very important to me. And of course this is just my opinion as a hobbyist programmer who never has to deal with a deadline (or even finish anything I start for that matter).

Or it could be that I'm too lazy to choose to have good programming practices, and thus place it in the hands of my programming language to force me.

Regarding C# (just a quick comment), I had to learn it recently for a project I'm helping out with and so far I'm very impressed. It's just an all around better language than Java. While Java is a nice language in some aspects (for one thing it's easy to use), it just feels too cumbersome and restrictive to program with comfortably. C# on the other hand feels a lot more like C++ to me, but with ease of use of Java and all of the flexibility of both combined. It also has really cool reflection support.

nonnus29
Quote:

I forget (if I ever knew), what language is the compiler for?

NASIC == Not bASIC

I write about it in my blog. I've got the parser pretty much finished, it builds a syntax tree from a program and I can pretty print a program back out. I'm working on improving error reporting and inserting type coercions. It'll run thru an interpreter. That's the next part I have to implement.

Thomas Fjellstrom
Quote:

If an Allegro port is ever made for it I'll definitely try it out

You wouldn't happen to be talking about this would you?

Matthew Leverton
Quote:

The main reason I'm reluctant to use D (if this could be called a reason) is that I'm scared of becoming, well... lazy.

To me, C++ has always just felt like it was tacked on to C with barely any consideration. I think you'd find that D is like an organized, concise version of C++ with memory management. The very basics of the STL (like list, vector, map) are rolled into native types. To me, any language that can be compiled to machine code is far from "cheating."

Quote:

If an Allegro port is ever made for it I'll definitely try it out

As Thomas has linked, it already exists. Again, D can use any C library with only a little bit of work. (I don't mean to trivialize the work done on DAllegro, because writing import files for all the Allegro functions would be tedious.)

Quote:

Is there a lex/flex implementation for D?

Not that I know of. What are you using now?

Quote:

Are you porting your web framework to D and doing all your web stuff in D?

I'm just in the experimental stages right now. I do some pretty funky stuff in my PHP template system, but I think I can imitate it in D. I've created the DB wrapper for MySQL, which was easy enough. Redoing the template parser and "compiler" would take the most work. Of course, then there's the whole web interface. dsource has a FastCGI project that I'd probably start with. Also, DMDScript (a D implementation of the ECMA 262 scripting language) is intriguing.

Thomas Fjellstrom
Quote:

Redoing the template parser and "compiler" would take the most work.

How would you actually handle this bit? call the compiler dynamically? or some wacky vm setup?

Matthew Leverton

Preferably, I'd convert the template into a Javascript file (on first run after modification) and execute it through DMDScript. Or I could create my own mini byte-code. There's really not much going on in a template file other than: print, loop, if, include, and get var.

I really don't think I would want to compile the templates to machine code. That's a lot of messing around for only a little gain.

Thomas Fjellstrom

Hmm, I think DMDScript would work nicely :o

bamccaig
Jonny Cook said:

It might just be because I started with C/C++ 4 years ago and have pretty much used it exclusively since then, but I feel like I'm somehow cheating by using a language which makes it easier to program than it is in C++.

Yeah, I partially feel the same way... I'm proud of C/C++, whereas most people I know are afraid of it. I learned to program using C++ and have yet to find a language that I prefer to it, though I consider C# an equivalent...

Jonny Cook said:

And of course this is just my opinion as a hobbyist programmer who never has to deal with a deadline (or even finish anything I start for that matter).

One thing I especially like about C/C++ is that a lot of people are afraid of it. I know that of my college class there is probably only a couple of people that enjoy C/C++ (most are literally afraid of it). Perhaps of our computer studies class it's only Samuel Henderson and I that embrace it. :) Another [possibly virtual] benefit of C/C++ is that it takes a more competent programmer to write. A lot of other languages are more forgiving and allow less competent people to work on the project which can only result in poorer code.

One thing that I saw in college is that a lot of people are in IT for money and don't actually give a fuck about the software quality (or system integrity). C/C++ scares them and that [hopefully] means that they'll stay away from "real" projects. ;D I know it's a flawed assumption, but it helps me sleep at night... :-/

Matthew Leverton said:

To me, any language that can be compiled to machine code is far from "cheating."

One could argue that any language COULD be compiled into machine code. ;)

Matthew Leverton
Quote:

Hmm, I think DMDScript would work nicely

The biggest limitation to using D for my framework is dealing with just-in-time method calls. Since PHP is entirely run in a VM, it's simple:

<mef:loop collection="news.recent(count: 10)" item="n">
  <li>{n.headline}</li>
</mef:loop>

That gets translated to something like:

<?php
foreach ($this->var['news']->recent(array('count'=>10)) as $tmp): $this->var['n'] = $tmp;
echo '  <li>'.$this->var['n']['headline'].'</li>';
endforeach;
?>

The $this is a reference to the Template object. $this->var is an object full of virtual variables that can get evaluated just-in-time. If the requested variable doesn't exist yet, it checks to see if it's been registered in a config file as being just-in-time. If it exists in that file, it returns a new instance of the class, passing the parameters along.

(The $tmp is necessary because $this->var['n'] is a virtual property and they aren't allowed as the recipient of foreach. Limitation or bug, take your pick.)

If I were using D/DMDScript, the machine generated code would be something like:

var tmp = App.getVar('news').recent({count: 10});
for (var i in tmp)
{
  App.setVar('n', tmp<i>);
  document.writeln("  <li>" + App.getVar('n') + "</li>");
}

Obviously some optimizations could be made, like forcing the recipient of the foreach to be a local temporary variable, but that's beside the point.

App.getVar('news') is where it gets complicated. In PHP, it's no big deal:

// after determining the type that "news" should be:
$className = 'DBI_'.$classType;
return new $className;

It's a little more complex than that because I have to pass parameters, but it works pretty good.

But D, being compiled, has no way to do that. I'm assuming that DMDScript works by binding D functions as DMDScript variables. So I'd have this in my DMDScript:

1// var FrameWork is bound to some D object
2 
3var App = {
4 varList: {},
5 
6 getVar: function( varName )
7 {
8 if (!varList[varName])
9 {
10 varList[varName] = FrameWork.newClass(varName);
11 }
12 
13 return varList[varName];
14 }
15};

I don't even know if I could return an instance from D to DMDScript like that (via the FrameWork.newClass(varName)). But besides that, how is D going to be able to dynamically create a class?

In D:

class FrameWork
{
  public void* newClass(char[] varName)
  {
    // reading through the config file to find the type of varName is simple...

    var className = fromConfigFile();

    // this is really lame:
    if (className == "News")
      return new DBINews();
    else if ( ... )
  }
}

Most of that is probably not how DMDScript even works, so I really don't think that style is even going to come close to being feasible.

It would be more reasonable to move those run-time classes to DMDScript. For instance:

In DMDScript:

1// This would be a system file that the template guy wouldn't need access to
2var DBI = {
3 News: {
4 recent: function(options)
5 {
6 var news = new Framework.News(); // reference to D object.
7 var count = options.count || 5;
8 
9 return news.recent(count);
10 }
11 }
12};
13 
14var App = {
15 varList: {},
16 
17 getVar: function( varName )
18 {
19 if (!varList[varName])
20 {
21 classType = readFromIniFile(varName);
22 varList[varName] = new DBI[classType];
23 }
24 
25 return varList[varName];
26 }
27};

I think it would have to be something more like that. However, there still are issues on linking dynamically between DMDScript and D. It's just that one layer is rolled back.

Finally, you could say, well put the actual DB code in DMDScript too. But then, we are back to where we've started with the entire system being in a VM. ;D And at that point, I might as well use Python or Ruby.

Or maybe just hack PHP and remove the $, convert -> to . and make $this implicit. 8-)

Thomas Fjellstrom

Yeah, I'm still going to finish my clone of your setup ;)

Sevalecan
Quote:

Why, except for legacy and maturity purposes, would anyone use C++ over D?

Because I'm paranoid?

I haven't tried D yet, though I have read feature comparisons with C++ on its website.

The thing about D that bothers me? The features are different from C++. You can call it C++++ or whatever, but to me it's an entirely different language. D appears to have different concepts all together, in opposition to C++, with which I'm more familiar. It also seems to be a bit higher level.

Again, I haven't really tried it or anything, or looked into it much more than I've noted. It just scares me, so I never really try. I don't like higher level languages, and I'm afraid of losing features that C++ has and I like.

Maybe it wouldn't bother me so much if it didn't feel like people were threatening to take away my beloved C++. :P

Thomas Fjellstrom

You can keep your precious C++. :P

I was never impressed by C++. I never saw the benefits over C to be inticing enough to use it until I found Qt. For what it was lauded for, it just wasn't enough. Not high level enough. Its supposed to be easier than C for pete's sake, and it didn't even do that right ;)

Sevalecan

My beloved C++.

In any case, I'm not arguing C++ over C, though I would definitely prefer C++.

If you ask me, the language itself is not bad. It has what I need. I'll admit the standard library and STL may be a bit lacking, but as you've pointed out, there are things to fill those gaps.

BAF

What does C++ offer that higher level languages don't? C++ is somewhat high level itself.

nonnus29

There's only one thing I measure a language by: how little I have to code to use it. I look for languages and libraries that multiply my productiveness. For example, I created a graph visualization application for a class last year (screen shots on my blog). I used java and about 5 open source libs. I never could've created the application I did with c, c++, or any other language.

I want tools that let me be as productive as 10 or 100 normal programmers. C, C++, and probably D aren't the tools, but they can be used to build the tools.

Sevalecan
Quote:

I never could've created the application I did with c, c++, or any other language.

Why does that seem 99.9% likely to be a gross exaggeration. Sure, you may not have been able to do it in the same amount of time... But not at all?

Quote:

I want tools that let me be as productive as 10 or 100 normal programmers. C, C++, and probably D aren't the tools, but they can be used to build the tools.

Well, I'll agree that some tools are better suited to certain jobs, the only way you're going to get much higher than 10 times as productive per amount of time probably depends on you not reimplementing lots and lots of features under another language.

I'm sure there's something out there to make it quicker.

Quote:

What does C++ offer that higher level languages don't? C++ is somewhat high level itself.

I find it incredibly difficult to manipulate and handle binary data.

In any case, there have been times I've wanted to write something in a higher level language and been unable to because it lacks basic functions. Which seems to be caused by certain things being completely covered up for "ease of use" (and under the assumption that you'd never need them directly).

I might just be talking out of my ass(blame the paranoia ;) ), but I'm writing this not actually knowing the reason I said D looked higher level. Maybe it's because it's supposed to be so damn "easy".

D probably isn't that bad, in actuality though. If it's supposed to replace C++, it should allow a route to the bottom of it's functions and allow a person to do whatever they please.

bamccaig

IIUC, C# has a pretty nice design. For regular use of the language things like references and such are taken care of automatically. However, there is also what they call unsafe code (which actually requires the unsafe keyword) to provide lower level access if you know what you're doing. It's also nice because it highlights the dangerous parts of code so you know to be extra careful with them.

D and C# sound pretty similar so far... I'd like to see an unbiased comparison between them.

Matthew Leverton
Quote:

Why does that seem 99.9% likely to be a gross exaggeration. Sure, you may not have been able to do it in the same amount of time... But not at all?

I'm sure the time limit was implied.

Quote:

but I'm writing this not actually knowing the reason I said D looked higher level. Maybe it's because it's supposed to be so damn "easy".

Considering D lets you drop into assembler and call any C library function (including malloc() and free()), I don't really think it's lacking any power. If you take a look at D and try it out, I think you'll quickly find yourself wondering why C++ isn't more like it.

Edit: Regarding D vs C#, see this chart. It's since been taken down, which means maybe it was out of date. Also, of course, it's not meant to show the other language's advantages.

I think the biggest differences would stem from D being a compiled language. As such, it gives you lower level access ... but cannot do quite as much run-time magic.

bamccaig

Apparently D can't use C++ libraries, however (at least "not easily"). I find it odd that a language designed to replace C++, capable of implementing C libraries, doesn't support C++ libraries... :-/ Or am I misinformed?

CGamesPlay

Well, C++ libraries have always been a bitch to deal with: name mangling isn't standardized, so a C++ library from one compiler won't work in another. And I don't mean "may not work"--it really won't work.

bamccaig
CGamesPlay said:

Well, C++ libraries have always been a bitch to deal with: name mangling isn't standardized, so a C++ library from one compiler won't work in another. And I don't mean "may not work"--it really won't work.

What do you mean by name mangling? :-/???

CGamesPlay

Run objdump on a C++ DLL and you will see things like _ZNSi3getEv. That's called name mangling and it translates to std::istream::get(). Each compiler does this differently. Name mangling is what allows the compiler to tell the difference between void foo(int) and void foo().

bamccaig
CGamesPlay said:

Run objdump on a C++ DLL and you will see things like _ZNSi3getEv. That's called name mangling and it translates to std::istream::get(). Each compiler does this differently. Name mangling is what allows the compiler to tell the difference between void foo(int) and void foo().

There was never a standard for this in C++ compilers? :-/

23yrold3yrold

That is the standard. :)

nonnus29
Quote:

Why does that seem 99.9% likely to be a gross exaggeration. Sure, you may not have been able to do it in the same amount of time... But not at all?

Yes, the implication was 'with in the time limit of one semester', my bad.

I've since seen two commercial products that provide a legacy system visualization diagrams somewhat like what I produced (although with additional features and a higher level of refinement) that have site licenses of over $100k per year.

Kitty Cat
Quote:

There was never a standard for this in C++ compilers? :-/

Name mangling itself is standard, but the style of the mangling is not. Early C++ compilers just translated code to C and were compiled normally (meaning it had to mangle to valid C symbols), while others didn't bother with that step.

Wikipedia explains it quite well:

http://en.wikipedia.org/wiki/Name_mangling said:

While it is a relatively common belief that standardised name mangling in the C++ language would lead to greater interoperability between implementations, this is not really the case. Name mangling is only one of several application binary interface issues in a C++ implementation. Other ABI issues like exception handling, virtual table layout, structure padding, etc. cause differing C++ implementations to be incompatible. Further, requiring a particular form of mangling would cause issues for systems where implementation limits (e.g. length of symbols) dictate a particular mangling scheme. A standardised requirement for name mangling would also prevent an implementation where mangling was not required at all — for example, a linker which understood the C++ language.
The C++ standard therefore does not attempt to standardise name mangling. On the contrary, the Annotated C++ Reference Manual (also known as ARM, ISBN 0-201-51459-1, section 7.2.1c) actively encourages the use of different mangling schemes to prevent linking when other aspects of the ABI, such as exception handling and virtual table layout, are incompatible.

Simon Parzer

D for a web framework seems a bit risky. What about Perl or Python?

CGamesPlay

Interpreted languages, loose typing... bad idea.

Indeterminatus

The thing that lured me into trying D was mostly its nice support for the Design by Contract paradigm. So far, it's the only language I know that truly supports preconditions, postconditions and invariants as part of the language.

Having said that, the lack for a proper IDE is the thing that keeps me from using D in a production environment (I tried a few, none of which was usable enough yet).

I'm a fan of the language, and given a proper IDE and more libraries, I'd be using it "for real" as well -- what I'm doing now with it is basically playing around.

Matthew Leverton
Quote:

D for a web framework seems a bit risky. What about Perl or Python?

Right now I'm using PHP for it, and it works well. For a typical web site, I'd use it over Perl, Python, or Ruby simply because PHP has native support for running in a web server. (That's its primary purpose.)

Writing a framework with it is still possible, but it's less than ideal. The reason is that it's already an interpreted language. Adding another layer on top of it can really hurt performance. This is why my templates are actually translated to raw PHP code and cached at run time. I don't want to introduce another virtual layer.

While that works well, the rest of the framework still has to be written in PHP. But there's a lot of higher level things I'd like to add that are just impractical to do. (I'd like to add things to the core language.) So what I've considered is writing my own custom language that just gets translated to PHP, similarly to what I do with the templates.

And yes, languages like Python and Ruby are more flexible than PHP, but I'd still have to do the same thing. MVC frameworks already exist that use an existing language as-is (e.g. Rails [Ruby], Django [Python]). They are all good and well, but they require you to learn so much about the framework, to me, you might as well be learning a language/script that was designed from the top down to do what it's doing.

So ideally, I'd write the framework in a language like D and just skip all this translating to another scripting language. Of course that's a large task, and for a long time will probably only be a personal, hobby project of mine.

Quote:

having said that, the lack for a proper IDE is the thing that keeps me from using D in a production environment

I don't mind the lack of IDE support. I just use UltraEdit (with a D syntax highlighting file) on Windows, save to my mapped virtual Linux drive, and run make in a Putty terminal. But, like you, I'm just playing around with it at the moment. However, I've seen enough to never use C++ again.

CGamesPlay

If you were to write the framework in .NET 1.1, you could actually (easily) compile the code to .NET 1.1 executables. Since you used 1.1 and not 2.0, Mono could then actually compile them to native images.

Of course, D will yield enough performance by itself, so blah :P

Matthew Leverton
Quote:

But seriously, is there anything in D that you cannot do in C++?

It depends on your perspective.

Some people say you can do anything in Assembler that you can do in C. Others say you can do anything in C that you can do in C++. And long those lines, you could say that C++ can do anything that you can do in D.

So I think the question should really be, "what things are D better at?" And so far, my answer would be "everything." I'm not an expert C++ user, so I'm not extremely qualified to answer, but here are a few things that D makes easy. (Sorry for the silly examples.)

Dynamic arrays:

int[] array;
array ~= 42; // array[0] = 42

Associative arrays:

int[char[]] map;
map["foo"] = 1;

Foreach:

foreach(val; array)
{
  writefln("%s", val);
}

Delegates:

int foo(bool delegate(int) func)
{
  if(func(42))
  {
    writefln("Hello, World!");
  }
}

foo((i) { return i < 100 ? true : false;  });

Templates:

void my_template(U) (U bar)
{
 static if (U.typeof == int) { /* or something like that */
    // code specific to an integer type
 } 

 // generic code
}

my_template("Hello"); // works with strings
my_template(42);

And it has memory management, no need for pointers (unless you are using a C library), no need (or support) for #include files or the preprocessor, etc.

I think it's safe to say that most of the stuff can be implemented in C++ with more verbose syntax or the use of ugly macros. It's not meant to be radically different. To me, the biggest advantage over C++ is that everything feels so much more clean and natural.

It's well documented. Read up on it yourself.

Simon Parzer
Quote:

If you were to write the framework in .NET 1.1, you could actually (easily) compile the code to .NET 1.1 executables. Since you used 1.1 and not 2.0, Mono could then actually compile them to native images.

Isn't .NET a framework of it's own? Does it make sense to use a framework to write a framework?

Goalie Ca

The main point for me to use a c++ like-language is because

1) C++ is transparent. Users must know every implementation detail. There's never any doubt how a list is implemented or passed into a function. This sounds like a bad thing, but its really a good thing. C++ is a systems engineering language.
2) Performance! Even then there are cases where i still fall back to c.
3) Low-level control. C++ is used for engineering. I somehow doubt that "next greatest language" D would make a nice systems engineering language.

There are so many languages out there. In the big scheme of things if one were to give up c++ and more do D, what is the real gain? The languages aren't all that different from each other. While i'm assuming D has some advantages with syntactic sugar, it probably also has some disadvantages in other areas. I don't see D stomping on c++'s niche any time soon.

Python is a language that is sufficiently different but interfaces with C++ extremely well. In python you care about writting code to do a task and you are not too worried about details. Because of that, the syntax is much cleaner, the typing system works differently, it is interpreted, etc. It covers a completely different area. If borrows some ideas from functional programming and a lot of ideas from all kinds of other languages. I consider python a glue language because it provides a brilliantly simple way to make a program or script or whatever out of libraries and functions. I have even started using it is a matlab replacement to some extent.

Haskell is a language that is on a completely different plane. It has this amazing static type checking and code verification tools. If it compiles it probably works. Implementation details are not reflected in the language at all. It is entirely up to the compiler to translate your statements into working instructions. You write pure mathematical stateless functions and they always return the same result. This is an excellent language for thinking about math and computer science problems. It can optimize very easily and parallelizes for free (no locking code since no variables).

In summary, C++ is very strongly imperative. D also seems very much that way. Of course there are differences but how much can really be gained by switching to D.
the big question everyone is asking lately is how can you deal with concurrency?
Well google wrote a famous paper on map-reduce algorithms for C++ borrowed from functional programming. And if i remember tim sweeney from epic (unreal 3!) proposes to use functional programming techniques. C++ can work with all of these big paradigms with the right library. It is not pure by any means but it can be pure enough for the problems faced in many cases.

Matthew Leverton
Quote:

1) C++ is transparent. Users must know every implementation detail. There's never any doubt how a list is implemented or passed into a function. This sounds like a bad
thing, but its really a good thing. C++ is a systems engineering language.
2) Performance! Even then there are cases where i still fall back to c.
3) Low-level control. C++ is used for engineering. I somehow doubt that "next greatest language" D would make a nice systems engineering language.

I don't see how D fails any of those points.

CGamesPlay
Quote:

Isn't .NET a framework of it's own? Does it make sense to use a framework to write a framework?

PHP is a framework, too. So is C++. It makes sense to use the C++ standard library when building another framework.

And speaking of that, for me language selection is all about the standard library. (Well, for compiled languages. I hate interpreted languages.) Really, between C++, C#, and what I've seen of D, I prefer C#, because it has a huge standard library. If D had a comparative standard library, I might consider developing in it.

What it boils down to is that syntax is syntax. No amount of syntax is going to serious slow down development. Hunting down rarely-used and unsupported libraries on the net and wading through Makefiles/project files/whatever to get them installed for every development machine is where my time gets wasted.

Goalie Ca
Quote:

I don't see how D fails any of those points.

But is it any better? Is there a compelling reason to switch to D or is it just "a little bit cleaner".

Matthew Leverton

I don't think anyone would argue that a person should switch from C++ to D in the sense of rewriting all of his projects.

But if you're starting something from scratch and are the type of person (like me) who's always been frustrated with how ridiculous C++ is, then I think D is worth using.

Thomas Fjellstrom
Quote:

But is it any better? Is there a compelling reason to switch to D or is it just "a little bit cleaner".

It's a LOT cleaner. IMO thats more than enough reason ;)

Michael Faerber

Anybody else here waiting for C++0x?

Thomas Fjellstrom
Quote:

Anybody else here waiting for C++0x?

Latest GCC is supposed to already support it. :D

Jonatan Hedborg

How does it compare to Java?

(let's not make this a Java vs. X thread btw, I'm just asking)

Sevalecan
Quote:

Anybody else here waiting for C++0x?

Yes.

Quote:

Latest GCC is supposed to already support it.

Yay.

Now I need to go and find out what's new.

[edit]

Isn't it supposed to be done around 2009? If they haven't decided on everything yet...

Edit2:

Yeah, I guess there is experimental support.

nonnus29
Quote:

Matthew said:
But there's a lot of higher level things I'd like to add that are just impractical to do. (I'd like to add things to the core language.) So what I've considered is writing my own custom language that just gets translated to PHP, similarly to what I do with the templates.

Then Domain Specific Languages are for you! This is EXACTLY why I'm interested in writing compilers and languages. Take for example this problem: suppose you're confronted with rewriting a legacy appication consisting of about 250 screens/pages. Some are simple CRUD but many have complex business logic behind them. The only way I can think of for it to even be possible is to create a DSL specific for the problem.

Quote:

CGames said:
If you were to write the framework in .NET 1.1, you could actually (easily) compile the code to .NET 1.1 executables. Since you used 1.1 and not 2.0, Mono could then actually compile them to native images.

This is entirely feasible and even desirable. And for a Java example you can use frameworks like Terracotta to get automatic parallelization across many servers. Not sure if .NET has this capability. "Simply" compile your langauge to C# or Java and take advantage of 1) the much better opimizing compilers and 2) the frameworks that exist for those platforms.

Quote:

Matthew said:
But if you're starting something from scratch and are the type of person (like me) who's always been frustrated with how ridiculous C++ is, then I think D is worth using.

Amen, But to use D for your template base langauge, wouldn't you need a mod_D apache module or something?

Thomas Fjellstrom
Quote:

wouldn't you need a mod_D apache module or something?

Nope. any executable can be called from the server as a CGI app. Tis what cgi is for. and mod_php doesn't actually have any real advantages over cgi php since it doesn't seem to do any fancy caching. unlike mod_perl.

Matthew Leverton
Quote:

Then Domain Specific Languages [en.wikipedia.org] are for you! This is EXACTLY why I'm interested in writing compilers and languages.

Yes, I have a strong interest in that. Even if it is just as a hobby.

I'm actually in the process of writing a PHP VM in D. I'm writing a lexer that turns it into tokens. Then I'm taking the tokens and turning them into byte code. From there, it will run in my VM. It (the PHP aspect) is just for educational purposes, unless it ends up having decent performance. It would be cool if my framework had the ability to run PHP natively, but that's not really what I'm trying to do. (I'd have to "port" the popular PHP extensions into D libs as well.)

Quote:

Amen, But to use D for your template base langauge, wouldn't you need a mod_D apache module or something?

Writing a proper Apache module would be beneficial, but using FastCGI is probably sufficient. In fact, lighttpd's FastCGI is supposedly faster than Apache's mod_php. (If you trust biased benchmarks.)

FastCGI for D already exists, and that's what I would begin with. As you are implying, there is more ground work that would need to be done to use D for this, but as someone who is very particular about code, that doesn't really bother me at all.

ThePredator

I tried it but Ada still kicks it's ass up and down (so does Eiffel).

But I will seriously cry if D gets more library support (Ada keeps getting passed by as far as libraries go).

Kitty Cat
Quote:

Dynamic arrays:

int[] array;
array ~= 42; // array[0] = 42

I'm not even sure I see how that works. ~ is the invert operator (in C(++)), and placed like that looks like 'array sorta-kinda-equals 42' which makes no sense with what you say it's doing, so it's quite weird for someone coming from C(++).

Quote:

Associative arrays:

int[char[]] map;
map["foo"] = 1;

map<string, int> blah;
blah["foo"] = 1;

C++ also allows it to use user-specified comparitors by adding an extra value to the map template args.

Quote:

Foreach:

foreach(val; array)
{
  writefln("%s", val);
}

Finally, a useful feature, even if it's only a syntax cleanup..

Quote:

Delegates:

int foo(bool delegate(int) func)
{
  if(func(42))
  {
    writefln("Hello, World!");
  }
}

foo((i) { return i < 100 ? true : false;  });

Unnamed functions? Interesting. Can't see much use though, especially given how ugly that looks (could just break it out into a real function and use a function pointer to the same effect..).

Quote:

Templates:

void my_template(U) (U bar)
{
 static if (U.typeof == int) { /* or something like that */
    // code specific to an integer type
 } 

 // generic code
}

my_template("Hello"); // works with strings
my_template(42);

Compile-time template type checks are something I've wanted. Isn't C++0x supposed to have that?

bamccaig
Kitty Cat said:

I'm not even sure I see how that works. ~ is the invert operator (in C(++)), and placed like that looks like 'array sorta-kinda-equals 42' which makes no sense with what you say it's doing, so it's quite weird for someone coming from C(++).

IIRC, somebody said that in D the tilde (~) is a concatenation operator which suggests that it adds another element to the array with the value 42.

    int[] array;
    array ~= 42; // array[pre_length] = 42;

Matthew Leverton
Quote:

I'm not even sure I see how that works. ~ is the invert operator (in C(++)),

~= is the D concat operator for arrays. So:

char[] foo = "Hello";
foo ~= ", World";

writefln("%s", foo); // outputs "Hello, World";

writefln("%s", foo[7 .. length]); // outputs "World" via array slicing

Quote:

C++ also allows it to use user-specified comparitors by adding an extra value to the map template args.

You can also do this:

class Foo
{
}

int[Foo] map;

Foo key = new Foo();
map[key] = 1;

You do have to define a couple of methods in Foo so that it knows how to create hashes, etc.

Quote:

Unnamed functions? Interesting. Can't see much use though, especially given how ugly that looks

Lambda expressions are huge in languages like Ruby and JavaScript. You can do a lot with them, but it takes a different style of programming to maximize their benefits.

bamccaig
Matthew Leverton said:

writefln("%s", foo[7 .. length]); // outputs "World" via array slicing

:o

Matthew Leverton

Another nice little thing:

  RegExp reg = new RegExp(r"([a-z0-9]+)(@(\d+))?", "i");

If you prefix a string with r, you get exactly what you see.

Billybob

Curious question: Does D have any built-in support for multi-threading?

Joel Pettersson

Though I've only looked thus far, D certainly seems a better higher-level language. A "better C++", so to say. (and one which doesn't go as rigidly in the "wrong direction" as Java, tying my hands behind my back and causing endless frustration) On the other hand, it's a much "worse C".

Should it be widely adopted at the cost of C++, maybe pure C - remaining interfaceable with D - will see a re-increase in popularity for lower-level coding, along with a separation of language-use depending on what is to be done rather than using the half-arsed compromise of C++. Wouldn't be bad at all.

relpatseht
Billybob said:

Curious question: Does D have any built-in support for multi-threading?

From what I have seen, the extent of its multithreading capabilities are the synchronized parameter. To quote the D overview:

Multithreaded programming is becoming more and more mainstream, and D provides primitives to build multithreaded programs with. Synchronization can be done at either the method or the object level.
synchronized int func() { ... }
Synchronized functions allow only one thread at a time to be executing that function.

The synchronize statement puts a mutex around a block of statements, controlling access either by object or globally.

Matthew Leverton

There is the std.thread module, but I've not used it yet.

Dustin Dettmer

I'm a bit late (so this might have been answered) but I'll push my luck anyway.

Quote:

Does C++ have an equivalent for this?

void templateFunc(T) (T value)
{
  static if (value.typeof.stringof == "int") // sorry if there's a better way to express this
  {
    writefln("Hello!");
  }
}

templateFunc(1000); // prints Hello

templateFunc("Hi"); // nothing

Yes but its quite ugly and only works for classes. Theoretically you really don't need it for functions because of function overloading.

Quote:

(Obviously, you could overload the function in C++, but my example is trivial on purpose.)

Can you do that with the preprocessor and templates in C++?

I'll make some example code (not tested and probably doesn't compile). Obviously just doing overloaded functions is preferred here, but we're trying to show what templates can do.

1template<typename T>
2class TemplateClass
3{
4 inline void templateFunc(T value)
5 {
6 // Do nothing
7 }
8}
9template< >
10class TemplateClass <int>
11{
12 inline void templateFunc(int value)
13 {
14 printf("Hello!\n");
15 }
16}
17 
18TemplateClass::templateFunc(1000); // prints Hello
19 
20TemplateClass::templateFunc("Hi"); // nothing

Billybob

ML and relpatseht, thanks for looking that up. Nice to know it has multi-threaded capability as well. Maybe I'll try to build a game with it some time in the future.

Thomas Fjellstrom

If it wasn't for wanting to use Qt in a few apps, I would so jump to D asap. :(

MiquelFire

I'm with Thomas. Matter of fact, I just made a first release of a QT app I was working on. Has some features to go before a 1.0 release however.

nonnus29

Yeah, I'm thinking of switching my compiler to D now... Thanks alot ML >:(

Walter Bright presentation:

http://video.google.com/videoplay?docid=-7073020265668105471

Myrdos

The two show stoppers for me are speed and library support. My understanding is that C++ tries to go as high level as possible without sacrificing speed. That is to say, a well-written C++ program should be 99% as fast as a C program.

Can D get the speed without the ugly syntax? It takes quite a bit of skill to use C++ well, and a mediocre programmer is going to pooch it. The hideous things my eyes have seen, modifying other people's programs. To me, a simpler language equals more robust code, because it takes less thinking to make good design decisions.

In fact, Bjarne Stroustrup seems to agree with ML.

Quote:

"Within C++, there is a much smaller and cleaner language struggling to get out". Yes, that quote can be found on page 207 of The Design and Evolution of C++. And no, that smaller and cleaner language is not Java or C#. The quote occurs in a section entitled "Beyond Files and Syntax". I was pointing out that the C++ semantics is much cleaner than its syntax.

If D can give me the semantics and speed of C++ with cleaner style, I'd consider switching.

[EDIT] Erm, the Digital Mars compiler is proprietary, that will slow adoption in the Linux realm. Plus, it only supports 32-bit systems. The GDC compiler is version 0.23 alpha, and only has one developer. I guess I'll give D a few years to mature.

HoHo
Quote:

If it wasn't for wanting to use Qt in a few apps, I would so jump to D asap. :(

Exactly the same here. I've been playing with QT for a few months now and I must say there is no other GUI toolkit as good that I've seen so far. I've also been reading a bit about D and it looks rather nice. Too bad those two things can't work together. Of cource the compiler being a bit too new doesn't help too much either.

Matthew Leverton

Walter Bright's official D compiler is post version 1.0 and quite stable. I think it's about 10 years in the making. He has even a longer history with developing compilers, as the author of Zortech/Symantec C++. In fact, most languages have been the works of a single individual. The Java and .NET stuff are pretty much exceptions to that.

His compiler already performs basically as good as C++ (sometimes better, sometimes worse - depends on the benchmark), so I really don't think it's a good reason to avoid the language altogether.

I really suggest that curious people read the D overview, as it's quite informative and honest.

Oh, and Python fans might want to look at pyd. It lets you run compiled D modules from within Python.

Kitty Cat

I'll wait 'til it can interface C++ code. My current work has been around COM stuff (*shudders*), and C++ makes implementing interfaces very slick. Without C++, I'd have to do it the C way, which is just ugly.

And am I the only one that doesn't like languages trying to hide pointers? I don't even like using non-const references because it gets confusing to know which variable changes would persist out of the function and which won't..

Thomas Fjellstrom
Quote:

And am I the only one that doesn't like languages trying to hide pointers?

I hate half ass-ed languages. Either its hidden all the time, or never. Either its completely high level, or as low level a high level language can get (ie: C). I find C++ tries to be too much, and fails miserably.

Heh, along with the C++ operation, C++ evaluates to C, making it a no-op as far as the useable return result is concerned. It tries to be more, but didn't quite make it ;)

CGamesPlay

My new language, ++C, won't have that problem.

Sevalecan
Quote:

And am I the only one that doesn't like languages trying to hide pointers? I don't even like using non-const references because it gets confusing to know which variable changes would persist out of the function and which won't..

No, I'm with you.

bamccaig
KittyCat said:

And am I the only one that doesn't like languages trying to hide pointers? I don't even like using non-const references because it gets confusing to know which variable changes would persist out of the function and which won't..

Sevalecan Dragon said:

No, I'm with you.

Me too...

Samuel Henderson
KittyCat said:

And am I the only one that doesn't like languages trying to hide pointers? I don't even like using non-const references because it gets confusing to know which variable changes would persist out of the function and which won't..

Sevalecan Dragon said:

No, I'm with you.

bamccaig said:

Me too...

Me as well.

Myrdos
Quote:

His compiler already performs basically as good as C++ (sometimes better, sometimes worse - depends on the benchmark), so I really don't think it's a good reason to avoid the language altogether.

Minor problem: I develop Linux software. Using a proprietary compiler will reduce the popularity of my programs.

Major problem: My computers are 64 bit.

Matthew Leverton

64-bit support is obviously a valid issue, but it being "proprietary" is just an excuse.

Quote:

The front end for D is open source, and the source comes with the compiler. The runtime library is completely open source. David Friedman has integrated the D frontend with GCC to create gdc, a completely open source implementation of D.

Honestly, I don't care if someone is too stuck up to download a free, open-source compiler because it's not part of their precious GPL commune. Those aren't the type of people likely to buy software anyway, so it's not like your commercial success will be hampered.

Quote:

And am I the only one that doesn't like languages trying to hide pointers? I don't even like using non-const references because it gets confusing to know which variable changes would persist out of the function and which won't..

I think that is spoken like a true C/C++ fan. I don't mean that in a bad way, but using a certain method for a while makes you start thinking it's the best way. If C++ and D both came out yesterday, I think basically everybody would choose D. However, now that you've used C/C++ for a while, you become partial to it and anything D does differently seems wrong.

Personally, I think that D's system is far less confusing than C++'s. It works the way I expect it to, without all the ugly pointer syntax. (In fact, even C++ tries to hide away pointers ... that's what references do.) But D's system wasn't as big of a shock to me, coming from language (like PHP) that automatically handle pointers as well. Obviously if the language does a poor, inconsistent job with replacing pointers, then it's something to be concerned about.

Edit: An example to show how D handles it:

1import std.stdio;
2 
3void setNullString(char[] s)
4{
5 s = null;
6}
7 
8void setNullInt(int i)
9{
10 i = 0;
11}
12 
13void setNullObj(Foo f)
14{
15 f = null;
16}
17 
18class Foo
19{
20 public char[] value;
21 
22 this(char[] value)
23 {
24 this.value = value;
25 }
26 
27 char[] toString()
28 {
29 return value;
30 }
31}
32 
33 
34int main()
35{
36 int x = 1;
37 char[] y = "Hello, World";
38 Foo z = new Foo("Foo");
39 
40 setNullInt(x);
41 setNullString(y);
42 setNullObj(z);
43 
44 writefln("%s %s %s", x, y, z);
45 
46 return 0;
47}

That would print "1 Hello, World Foo".

If I wanted the code to "work," I'd have to explicitly use the ref keyword, similar to C++'s & symbol.

However, dynamic arrays and objects are always pointers. That behavior is constant, so you never "don't know." For instance:

1import std.stdio;
2 
3// using Foo class from before
4 
5void changeFoo(Foo f, char[] newValue)
6{
7 // f is a pointer, so this will change the value
8 f.value = newValue;
9}
10 
11int main()
12{
13 Foo z = new Foo("Foo");
14 
15 changeFoo(z, "Test");
16 
17 writefln("%s", z);
18 
19 return 0;
20}

The above would output "Test", because all objects are pointers. If you really wanted to pass a copy of an object you have to explicitly do so on either end using the 'dup' property.

changeFoo(z.dup, "Test"); // wouldn't change z

Billybob
Quote:

Quote:

And am I the only one that doesn't like languages trying to hide pointers? I don't even like using non-const references because it gets confusing to know which variable changes would persist out of the function and which won't..

Yes, I'm against you.

Fixed.

bamccaig
Matthew Leverton said:

  char[] y = "Hello, World";
  Foo z = new Foo("Foo");

Matthew Leverton said:

  setNullInt(x);
  setNullString(y);
  setNullObj(z);

Matthew Leverton said:

That would print "1 Hello, World Foo".

Matthew Leverton said:

However, dynamic arrays and objects are always pointers. That behavior is constant, so you never "don't know."

:-/ I think I'm confused... ???

To be honest, the only thing I really have against D is the name... :-/ If I'm gonna start using it the language needs to be renamed... :-/:'(

Thomas Fjellstrom

Pointers work the same in D as in C, its passed in by value, so any setting of the pointer in the function sets a local one, but if you dereference the pointer (foo[1] = bar), you then set the contents.

Myrdos
ML said:

Honestly, I don't care if someone is too stuck up to download a free, open-source compiler because it's not part of their precious GPL commune.

Digital Mars license said:

The Software is copyrighted and comes with a single user license, and may not be redistributed.

What I meant was that Linux distributions won't be able to package the D compiler and include it in their repository. Therefore, they won't package any software written with D.

Compiling software from source in binary-package distributions can be hit or miss because of missing dependencies. For example, if Allegro were written in D, the average user wouldn't be able to install it in Ubuntu*. You'd have to make a list of all the dependencies and tweaks for every Linux distribution separately.

However, this issue only affects Linux users. Windows and Mac folk can get the executable.

bamccaig
Thomas Fjellstrom said:

Pointers work the same in D as in C, its passed in by value, so any setting of the pointer in the function sets a local one, but if you dereference the pointer (foo[1] = bar), you then set the contents.

I see... :-/ For a language with no actual pointer syntax I would think it would be pass by reference and not address. :-/ That sounds less than clean for strings (char[]) then... :-/

Thomas Fjellstrom
Quote:

I see... :-/ That sounds less than clean for strings (char[]) then... :-/

Reading the docs would help you from looking like a fool, but because I know you won't, here you go:

string[] = someotherstring;

bamccaig

As I said earlier, I don't have time to learn about D right now. That's what a thread like this is for. For those that are reading up on it to update the rest of us who are busy with other things.

Kitty Cat
Quote:

If I wanted the code to "work," I'd have to explicitly use the ref keyword, similar to C++'s & symbol.

And as I mention, using non-const &/references makes it confusing too, since there's no indication in the function that you're doing "more permanent" changes. With a proper pointer you'd have to do
*foo = blah;
which makes it clear that you're modifying memory from somehwhere else and not that specific variable (assuming no operator overloads). If you do
foo = blah;
are you modifying a variable specific to the function, or are you also modifying the variable that the calling function passed? In C++ you'd have & at the declaration to tell you (which is still a bit too transparent for my tastes), where as in D, you have the ref keyword, but also the implicitness of objects (are typedef'd enums and basic types also implicitly references? if not, then that's more room for confusion).

Quote:

However, dynamic arrays and objects are always pointers. That behavior is constant, so you never "don't know." For instance:

If you have a large-ish function where you can't easilly check the variable's declaration, it's easy to miss or not know. Having to be explicit about dereferencing makes it easier to see that you're modifying memory from elsewhere.

Matthew Leverton
Quote:

For a language with no actual pointer syntax

It does have pointers, it's just that you don't really ever need to use it. For instance:

1import std.stdio;
2 
3int main()
4{
5 int x = 1;
6 int* px = &x;
7 int[] y;
8 int[]* py = &y;
9
10 *px = 2;
11
12 (*py).length = 1; // resize the dynamic array
13 *py[0] = 42;
14
15 writefln("%d, %d", x, y[0]);
16
17 return 0;
18}

That prints "2, 42" as you would expect.

Remember that it can interface directly with C, so it has to let you do stuff like that.

Quote:

Having to be explicit about dereferencing makes it easier...

I disagree, but at some level, it's just personal taste. I'd rather know I always have to do object.bar; I can very easily look at the function "prototype" to determine what's going to happen.

bamccaig
Matthew Leverton said:

It does have pointers, it's just that you don't really ever need to use it.

Damn! :o Now I think it's only the name... :-/

Thomas Fjellstrom
Quote:

Now I think it's only the name... :-/

Which is a really stupid reason.

CGamesPlay
Quote:

but it being "proprietary" is just an excuse.

Quote:

Regarding C#, I almost commented that I also never tried it because it's essentially controlled by Microsoft

Make up your mind ::)

Matthew Leverton

Microsoft owns an OS, so they have reason to tie their languages to the OS. (Do you see them releasing a .NET framework for Linux?) Digital Mars, however, has no incentive to lock out other operating systems and provides compilers for various operating systems.

That's all I meant by the Microsoft comment.

bamccaig
Matthew Leverton said:

Do you see them releasing a .NET framework for Linux?

I thought they were assisting the Mono project... :-/???

Matthew Leverton

(In reference to the deleted part of your post...) It doesn't benefit Microsoft to release .NET for OS X and Linux (in fact, it hurts them), but that's not my point. As a developer, using .NET forces you and your clients to use Windows. Perhaps as mono matures, it won't be an issue. However, I have a feeling that Microsoft's implementation will always stay a step ahead.

Like .NET, Java is proprietary and controlled by Sun (or at least was), but yet it's cross platform. And I wouldn't have a problem using Java, if I actually liked the language. If Java only ran on Solaris (haha), then I'd have the same issue with Java.

But of course, if you have good reason to only target Windows, then using a Windows-only language is fine by me.

CGamesPlay

So, D produces Linux executables as well?

Matthew Leverton

There are Linux and Windows versions of the official dmd compiler. There is also gdc, which lets you use it with the gcc system on Linux. And there is gdcmac for OS X.

bamccaig
CGamesPlay said:

So, D produces Linux executables as well?

:-/ Haha, I didn't expect that question from you. I highly doubt that the D programming language is being developed as a Windows-only language. However, the compiler will produce the [platform specific] binary executable (which one could produce a Linux executable from C# code if a compiler was written).

Matthew Leverton said:

If Java only ran on Solaris (haha), then I'd have the same issue with Java.

Except that .NET applications don't just run on Windows (anymore). IIUC, and according to the Mono project, it is possible to develop applications now that execute both in Windows and Linux. I don't know how complete their support is, but it's definitely complete enough to say that .NET is officially multi-platform.

With that in mind, I think C# is all the more appealing. :)

Matthew Leverton

One aspect of .NET: WinForms. Just a single feature that's not implemented would cause the program to fail under mono.

Quote:

With that in mind, I think C# is all the more appealing.

From the little that I've used C#, it does seem like a nice language (unlike C++). I really don't have any complaints about the language itself (especially since I haven't used it very much).

Once mono reaches full compatibility without having to put hacks for it in your code, then C# becomes more appealing. (And yes, there is a distinction between the C# language and the entire .NET world, but to be fair, if you are going to use C# for an application, then you probably are going to be using the whole thing.)

But really, considering D compiles to native code, I see it as a direct replacement for C++, not as a competitor to Java or C#.

Thomas Fjellstrom

I had heard MS replaced WinForms already with something not quite so MS specific. Probably just a rumour.

Sevalecan
BillyBob said:

Quote:

Quote:

And am I the only one that doesn't like languages trying to hide pointers? I don't even like using non-const references because it gets confusing to know which variable changes would persist out of the function and which won't..

Yes, I'm against you.

I'm Dumb.

Fixed.

Though, somehow I detect this could go on... But I just couldn't let it slip.

In any case, I'm not ready to try and learn another language. I still have to get a firm grip on perl. And maybe some day I'll learn ruby. But I don't really see a need to switch to D. I like C++, I'm happy.

Matthew Leverton
Quote:

I had heard MS replaced WinForms already with something not quite so MS specific. Probably just a rumour.

They do have to keep the mono guys on their toes. ;)

Quote:

I still have to get a firm grip on perl.

Oh no you don't, Perl is the devil's language! Unfortunately, I have to take a Perl class this summer as an elective. I'll probably rant about that a few times. 8-)

CGamesPlay
Quote:

Once mono reaches full compatibility without having to put hacks for it in your code, then C# becomes more appealing.

Really, you should try it before you write it off as sub-standard. I've written a proprietary server for streaming XML in C# and run it under Mono, it handles just fine. I've also written my IRC bot completely in C# using Mono (it would require a moderately-sized code change to run in Windows, as I use functions like execve in one file).

It's not as bad as you think. But since you didn't want to talk about C# here, I won't say anything else on the topic.

How is D's standard library?

Thomas Fjellstrom
Quote:

Oh no you don't, Perl is the devil's language!

::)

Matthew Leverton

I'm sure D's standard library (Phobos) is quite bare compared to Java and C#. There's also Tango, which I believe most people use as a drop-in replacement of Phobos.

BAF

Of all the stuff I've tried on Mono, including Microsoft Code Provider compiler stuff and all kinds of black magic, the ONLY thing that didn't work was calling Disconnect() on a socket. It had been overlooked, according to #mono. Turns out I was supposed to be calling Close() anyway. ::)

bamccaig
Matthew Leverton said:

But really, considering D compiles to native code, I see it as a direct replacement for C++, not as a competitor to Java or C#.

Now you've got me liking the idea of D, but I still love C/C++... Now what...?! :o:'(

Thomas Fjellstrom said:

I had heard MS replaced WinForms already with something not quite so MS specific. Probably just a rumour.

Preparation for one of my previous posts had me on the Mono project Web site where I remember reading something about GNOME that sounded side-by-side with WinForms, as in you could use either-or or something... :-/ The section said that as is the GNOME (and/or Gtk#) stuff works in Windows as well, but again I don't know how complete, applicable, or accurate that is.

BAF said:

Of all the stuff I've tried on Mono, including Microsoft Code Provider compiler stuff and all kinds of black magic, the ONLY thing that didn't work was calling Disconnect() on a socket. It had been overlooked, according to #mono. Turns out I was supposed to be calling Close() anyway. ::)

;D

Goalie Ca

I've been using mono apps daily for a good two years at least. Its quite a nice setup. Gtk#, gecko#, etc. all working very nicely. I do not like beagle though because its performance is attrocious (booting up and having my disk stall for a few minutes is unacceptable). When i think of .NET i hardly think of windows.forms etc.

I did write a commercial application in c# once. I found it a very appealing language. I haven't tried it since though for any coding because it does not fit into my working flow. 3.0 also supposedly has some nice things like lambda functions!

torhu

Nice to see some interest in D. Feel free to try DAllegro, btw.

I recommend the D news groups at news.digitalmars.com for any questions about D, or #D on freenode.org.

Like people have mentioned, D is not for the faint of heart at this stage. Be prepared to have a long-standing compiler bug, a language change, or a buggy library make you give up your project at any time. And forget about working tools besides a compiler and your favorite generic editor. There's a Windows debugger, but it doesn't support multiple threads yet. Maybe it never will. Great, isn't it? But the language itself is still great.

About the name: D was named 'Mars' by its creator. Then someome talked him into calling it D instead. Yes, it sucks. And no, the jokes about it are not funny anymore. To google for D related pages, use 'D language' or 'D programming', or 'D programming language'.

I'll try to answer some of the questions that were raised in this thread.

A basic compile time type check looks like this:

static if(is(T == int)) {
    writefln("it's an int");
}

To create objects without knowing the class name at compile-time:

Object obj = Object.factory("mymodule.MyClass");
writefln(obj);  // prints "mymodule.MyClass"

There were probably others, but I've forgotten.

Performance for D apps is theoretically like C++. It's a quality of implementation issue, but so far it seems to be acceptable. Public and protected methods are virtual by default, but the compiler should be able to make them direct calls if they are not overriden. You can always declare them 'final' to be sure. Local objects can be stack allocated by just adding the 'scope' keyword in front of the variable declaration.

There are lots of little niceties I could mention, like the automatic array bounds checking of the built-in arrays. But I suggest those not afraid of living on the bleeding edge should try it out themselves. :)

Matthew Leverton
Quote:

Object obj = Object.factory("mymodule.MyClass");

That's very useful to me... Do you think there's any simple way to call arbitrary functions at run time?

For instance, the following works:

1module test;
2 
3import std.stdio;
4 
5class DBI
6{
7 char[] arbitraryFunction(char[] name)
8 {
9 return null;
10 }
11}
12 
13class Foo : DBI
14{
15 final char[] arbitraryFunction(char[] name)
16 {
17 switch (name)
18 {
19 case "getName": return "Matthew";
20 case "getAge" : return "25";
21 }
22
23 return null;
24 }
25}
26 
27int main(char[][] args)
28{
29 assert(args.length >= 2);
30
31 DBI dbiFoo = cast(DBI) Object.factory(args[1]);
32 writefln("%s", dbiFoo.arbitraryFunction(args[2]));
33
34 return 0;
35}

./test test.Foo getAge returns 25.

I could work with the above. It's not quite as clean as PHP, but that's really all I need to get my web framework running on D...

axilmar
Quote:

All-in-all, it really seems nice. In fact, I'd say that D is what C++ should have been. Everything it does is so simple compared to C++...

The Question at the End: Does anyone here use D? Have any favorite features or gripes to share? Why, except for legacy and maturity purposes, would anyone use C++ over D? (I realize it doesn't have many tools, IDEs, etc... I'm asking about the language itself.)

It's a nice language for what it does, but in the end almost as inelegant as C++: it does not really cut down the amount of work you have to do, both in the language or in the libraries.

Considering that there are no tools for D, Java is a better option. And I think Java is a little bit faster when it comes to garbage collection, because Java's collector is precise, whereas D's collector is Boehm's collector (very good collector, but not precise).

torhu
Matthew Leverton said:

Do you think there's any simple way to call arbitrary functions at run time?

For instance, the following works:

1module test;
2 
3import std.stdio;
4 
5class DBI
6{
7 char[] arbitraryFunction(char[] name)
8 {
9 return null;
10 }
11}
12 
13class Foo : DBI
14{
15 final char[] arbitraryFunction(char[] name)
16 {
17 switch (name)
18 {
19 case "getName": return "Matthew";
20 case "getAge" : return "25";
21 }
22
23 return null;
24 }
25}
26 
27int main(char[][] args)
28{
29 assert(args.length >= 2);
30
31 DBI dbiFoo = cast(DBI) Object.factory(args[1]);
32 writefln("%s", dbiFoo.arbitraryFunction(args[2]));
33
34 return 0;
35}

./test test.Foo getAge returns 25.

I could work with the above. It's not quite as clean as PHP, but that's really all I need to get my web framework running on D...

I'm not sure exactly what you want to do. If all the methods are defined in DBI, you could just put the switch statement there (actually calling the methods instead of returning a string constant), and let the subclasses override the methods. The empty superclass methods could throw a NotImplementedException or something. But I guess that's not what you want.

You could also use an associative array instead of a switch:
char[] delegate()[char[]] methods;

But I don't know if that would buy you anything. To actually list the methods at runtime, you could use Flectioned. I don't know if Flectioned supports calling methods given their name as a string yet.

axilmar said:

It's a nice language for what it does, but in the end almost as inelegant as C++: it does not really cut down the amount of work you have to do, both in the language or in the libraries.

What are you basing this on? Porting C++ code to D tends to make it shorter, which would suggest that it would have been faster do develop in D. D is just easier. :) If only there were some proper tools...

axilmar said:

Considering that there are no tools for D, Java is a better option. And I think Java is a little bit faster when it comes to garbage collection, because Java's collector is precise, whereas D's collector is Boehm's collector (very good collector, but not precise).

Not sure how precise 'precise' means, but as of DMD 1.001, D's GC is type-aware. It won't scan a char array looking for pointers, but given an object that contains a lot of ints, but only a single pointer, it will scan the whole thing. At least that's how I recall it.

Matthew Leverton
Quote:

I'm not sure exactly what you want to do. If all the methods are defined in DBI...

It would be to implement my web framework, which is based on letting the user run arbitrary methods on demand. For instance: <mef:loop collection="news.recent()" />

That would call the News class, which is guaranteed to be an extension of DBI. The recent() method only would exist in the News class. So casting the Object.factory to a DBI gets me half-way there.

Quote:

You could also use an associative array instead of a switch

Yeah, that's what I would end up doing. That is, I'd make the sub classes register the template-aware functions. Technically it amounts to the same thing, but it seems more clean.

I did briefly look at Flectioned before, although as you said I'm not sure if I could actually call functions by their names. But I'll see what it can do.

Quote:

in the end almost as inelegant as C++

No single feature is probably enough to wow you, but I think, when you put it all together, it is a lot more elegant than C++. But you're right in that it doesn't deviate far from C++ in terms of the overall methodology.

Regarding the garbage collection, I really don't know enough to comment. I've read quite a few informative threads in the D archives, but of course opinions vary widely on which method is the best.

axilmar
Quote:

Not sure how precise 'precise' means, but as of DMD 1.001, D's GC is type-aware. It won't scan a char array looking for pointers, but given an object that contains a lot of ints, but only a single pointer, it will scan the whole thing. At least that's how I recall it.

What about stack frames? Boehm's collector does not support precise stack frame scanning.

Edit:

3 years back I have posted a D source file for using Allegro:

Allegro for the D programming language

It's funny that 3 years ago some allegro members' attitude towards D was a little bit negative...

Now that I have studied programming languages extensively, I find C-like languages unattractive. If only we had something more lispy-haskelly...

Matthew Leverton

Lisp you say?

Quote:

It's funny that 3 years ago some allegro members' attitude towards D was a little bit negative...

I don't really see much negativity there. (Korval doesn't count. He hated everything)

Thomas Fjellstrom

From what I remember, 3 years ago, D (the compiler) wasn't in very good shape. Not as complete as it is now.

Goalie Ca

If i wanted to learn lisp i'd be using emacs. Ewwwwwwwwww :D

Seriously though, what are all those ()'s about. One of the nice things about python is that there are no curly braces or anything.

Matthew Leverton

python is only a step above whitespace.

axilmar
Quote:

From what I remember, 3 years ago, D (the compiler) wasn't in very good shape. Not as complete as it is now.

The basics were already in place. Let's not forget D is 10 years old already (from the moment Walter Bright started to implement the compiler).

Quote:

I don't really see much negativity there. (Korval doesn't count. He hated everything)

A, OK then! what happened to al-mighty Korval who was going to change the face of Allegro?

Quote:

Lisp [cl-alleg.sourceforge.net] you say?

See how elegant lisp is? unlike D...

Thomas Fjellstrom
Quote:

python is only a step above whitespace [compsoc.dur.ac.uk].

My thoughts exactly.

bamccaig
Matthew Leverton said:

python is only a step above whitespace.

I've never used python so I wasn't sure what you meant... So I looked up python syntax on Wikipedia... :-/ Now I know... :( OMGWTF.

spellcaster
Quote:

I've never used python so I wasn't sure what you meant... So I looked up python syntax on Wikipedia... :-/ Now I know... :( OMGWTF.

Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.

But do not program in COBOL if you can avoid it.

-The Tao of Programming, Book I

nonnus29

There's actually one interesting thing about cobol: it has continuations, and since continuations are a special case of a coroutine, cobol has coroutines. It has to do with the way 'procedures' are executed and either return or fall thru to the next 'procedure'. There's a paper on the denotational semantics of cobol 74 in the ACM database that talks about it.

Lars Ivar Igesund

Sorry to break in (and making the post somewhat long), I found this thread while searching for D and Tango (being a Tango dev).

For those waiting in excitement for C++0X (or whatever the next spec is called), note that D is well known in the circuits making the proposals for it, and that many of the new features are going in because they have been shown to be successful in D. IMO, C++ has to much legacy syntax, such that the new features also needs to be ugly, and in some cases crippled.

On the future of D, 2.0 which has an alpha compiler prepared these days will at first add constness features that should be a whole lot more powerful than those of C++, adding not only the possibility of logical const, but truly enforced invariant variables.

Next on the line, seems to be AST manipulation, for even more elegant and powerful compile time macros (note that D already can execute functions pertaining to certain restrictions compile time).

Execution of named functions, like exec("myinstance.foo") is possible via add-on libraries, DDL or Flectioned mainly. You may be able to do it using more low level mechanisms, since most of the necessary information exists in the executables, but it may not be particularly elegant.

Since D is a language that have extremely short compile times, especially using the DMD compiler (GDC is still fast, but the backend is slower than DMD's), it is feasible to use D is a web language, even where modules are lazily compiled, and have these modules dynamically loaded. This was the idea that was the original background for DDL. The syntax is also much more palatable than C/C++, and it is possible to plugin scripting languages if that is what you want. DMDScript (or Walnut which is a refactoring) has been mentioned, there is MiniD which has a syntax based on D's, Lua has been integrated, there is PyD, dio and I know someone made an effort with Ruby at some point.

Note that D seems to be a popular language among web developers, and there are several upstart libraries providing at least part of the functionality, most of them tied to Tango, as it's dev team have experience with such technologies and it's IO functionality is easily extensible in those directions. </end shameless plugging>

D seems also very popular among game developers, and have a healthy community. The most impressive project this far, is Deadlock http://www.team0xf.com/eng/ .

As for libraries, that seems to improve steadily,, also having all C libraries available rectifies quite a bit, and many C++ libraries are available, especially if they are compiled with GCC (the mangling situation mentioned earlier) and don't have to insane headers and use too much STL. There are tools to do at least quite a bit of the necessary header generation automatically. OGRE and Qt are examples of libraries that most likely can't ever be done automatically, whereas manual wrapping may still be possible. The same goes for tools/IDE's, the situation is improving. The Descent Eclipse plugin is well on it's way, and rumours even have it that there will be a commercial VS plugin for D in the not-so-distant future.
-------
Lars Ivar Igesund
larsivi - http://larsivi.net

Sevalecan
Quote:

For those waiting in excitement for C++0X (or whatever the next spec is called), note that D is well known in the circuits making the proposals for it, and that many of the new features are going in because they have been shown to be successful in D. IMO, C++ has to much legacy syntax, such that the new features also needs to be ugly, and in some cases crippled.

Ugly? Sure, that's practically all this thread is about.

Anyway, I won't give you any grief about the name. But if you're curious, I've read that it's going to be called C++09. Though, I personally just call it C++0x.

And what features exactly are going to be crippled?

Thomas Fjellstrom
Quote:

And what features exactly are going to be crippled?

Anything new that they try and add will have to use symbols and identifiers that don't clash with anything else. And for new stuff thats just a fix for stupid C++ "bugs", those will also have to use different syntax, to keep C++0x compatible with C++.

So no matter what, when you try and update a language like C++, you're screwed. Anything you try and do will have to be compatible with the last version.

BAF

They should just drop backward compatibility in C++0x. You want C++0x? Conform to new standards, damnit.

nonnus29
Quote:

They should just drop backward compatibility in C++0x. You want C++0x? Conform to new standards, damnit.

They did, but named it 'D'.

:P

Sevalecan
Quote:

Anything new that they try and add will have to use symbols and identifiers that don't clash with anything else. And for new stuff thats just a fix for stupid C++ "bugs", those will also have to use different syntax, to keep C++0x compatible with C++.

So no matter what, when you try and update a language like C++, you're screwed. Anything you try and do will have to be compatible with the last version.

Specifically, what? Name one.

Again, I'm not asking whats ugly. I'm asking whats crippled.

Lars Ivar Igesund
Sevalecan Dragon said:

Again, I'm not asking whats ugly. I'm asking whats crippled.

I did say in my opinion, because I am quite sure that not everyone would call it crippled, maybe it won't even be looked at only in the context of C++, but can still be in the context of D. Maybe C++ uses would just call it a syntactic problem.

To give you something to fire at, I did try to find a reference to such a feature, but failed. I do see that several notable features (that would have been good for C++!) like Modules have been dropped. Maybe the proposals I once thought was crippled, has been dropped too, or been fixed to some extent to make them more palatable.

I do not see a good reason for me to follow all discussions on the development of C++, given what I think about the state it's in today, nor make note of references I could make in discussions like this. So since I can't "prove" it, I will withdraw the word "crippled" from the above post ;) It does in no way diminish my feelings of C++ being sucky though, and that it will still be sucky (but with an even longer spec) when C++09 comes out :)

Jonny Cook
Quote:

I've never used python so I wasn't sure what you meant... So I looked up python syntax on Wikipedia... :-/ Now I know... :( OMGWTF.

It's really not that bad.

bamccaig
Jonny Cook said:

It's really not that bad.

I've seen worse. Still, using whitespace to mark code-blocks is foolish. Perhaps using whitespace to trigger formatting warnings instead would be a good function.

    for(int i=0; i<10; i++)
        a();
        b();   // "Warning! Indented function call not included in for-loop code-block."
        c();   // "Warning! Indented function call not included in for-loop code-block."

Although useful for text-editing, etc., I prefer IDEs that automatically format when you save the file.

    for(int i=0; i<10; i++)
        a();

    b();
    c();

Though the formatting functionality must be bored with me. 8-)

Application: "OK, format his code."
Formatting-Function: ";D...:D...:)...:-/...:(...???...:'("

Dustin Dettmer
Thomas said:

And for new stuff thats just a fix for stupid C++ "bugs", those will also have to use different syntax, to keep C++0x compatible with C++.

Have you found a bug in C++? I didn't think any existed.

Billybob
Quote:

Have you found a bug in C++? I didn't think any existed.

I think things like the less-than and greater-than signs are considered bugs. i.e.

std::vector<std::vector<int>> something;

That code won't compile, because >> is a binary shift operator. D fixes this "bug" by using something other than angled brackets for things like that.

23yrold3yrold
Quote:

That code won't compile, because >> is a binary shift operator.

How is your deliberate syntax error a bug? :) Seems more like just an element of C++'s previously mentioned lack of elegance ...

Billybob

It's a vague area, sure, but I think we can both agree it isn't something desirable and should be "fixed".

Thomas Fjellstrom

I did remember one thing I didn't like. typedefs are as usefull as macros. You might as well #define a type, instead of using typedef, because it doesn't give you anything more. Especially with templates.

For some odd reason, with all its type strictness, C++ forgot to make typedefs strict types. So you can't do the following:

typedef int MyInt;
template <int> class Bar { ... };
template <MyInt> class Bar { ... };

And why can't you do that? Because to C++, MyInt and int are the exact same type, and thus clash. So what if they really are the same type under the hood, that shouldn't matter. A typedef is supposed to be a separate type from the base type. C++ however doesn't think so.

Theres at least one more "gotcha" in C++ that "bug"s me, though I can't recall what it is ::)

Kitty Cat
Quote:

So what if they really are the same type under the hood, that shouldn't matter. A typedef is supposed to be a separate type from the base type. C++ however doesn't think so.

They are fundamentally the same, though. They behave exactly the same, the only difference is the name. Could always wrap an int in a class called MyInt though, then you can do that.

Thomas Fjellstrom

A typedef is supposed to define a new type. It doesn't though. Funny how that works.

Quote:

Could always wrap an int in a class called MyInt though, then you can do that.

And thats a good thing? Sounds like overhead for no reason.

Quote:

They behave exactly the same

Sure, at the moment. Might want to change the type later, and keep the name.

Kitty Cat

I wouldn't doubt typedefs in C++ to be mainly discouraged. You really don't need it except when you want to duplicate an existing type. Structs and classes automatically get a type name, as do enums. A typedef doesn't do anything except make one typename out of another typename (using it to define implicit pointer or array types is just evil, so don't go there :P).

Thomas Fjellstrom

For one, it would be nice to have just to be able to change the type, without changing the name.

Quote:

I wouldn't doubt typedefs in C++ to be mainly discouraged

Probably cause it wasn't through through far enough. C++ has strict typing, and typedef misses that. Thats a bug imo.

Do it all the way, or not at all. Anything else will just cause needless confusion.

Kitty Cat
Quote:

Probably cause it wasn't through through far enough. C++ has strict typing, and typedef misses that. Thats a bug imo.

If it was left in for compatibility with C, it would make sense. C++ itself seems to have no use for typedef, however code coming from C (eg. static inline methods in headers) that uses typedefs may rely on the compiler accepting such "implicit conversions".

Thomas Fjellstrom
Quote:

code coming from C (eg. static inline methods in headers) that uses typedefs may rely on the compiler accepting such "implicit conversions".

Maybe in static "C" {} sections. C++ is already incompatible enough with C that changing typedefs strictness wouldn't have made anything any more difficult. You already know C++ is going to make type casting safer, and you should have been able to expect all of the language to conform.

BAF

C++ feels crippled to me. I can't really explain why, but when I can whip out a program in 10 minutes in C#, then spend hours getting the same thing going in C++, it's crippled.

For one thing, there are no good string processing functions. At least not compared to C#'s string. Same thing goes for sockets.

Thomas Fjellstrom

Thats pretty much my sentament. I'll use C++ for Qt, since Qt supliments a lot of things C++ doesn't have (like a decent String and regex setup). C++ tries to be more than C, but really doesn't do a good enough job for me most times.

axilmar
Quote:

C++ feels crippled to me. I can't really explain why, but when I can whip out a program in 10 minutes in C#, then spend hours getting the same thing going in C++, it's crippled.

For one thing, there are no good string processing functions. At least not compared to C#'s string. Same thing goes for sockets.

I don't wish to sound pedantic, but language != language with libraries. You can't compare C++ without any libraries to C# and its libraries.

Why don't you compare C# with Qt and tell us what you think? I've done so with the Java J2SE, and I find Qt equal or better.

Thomas Fjellstrom

Technically, the standard library IS part of the language. libc is part of C, stdlibc++ is part of C++.

Sevalecan
Quote:

C++ feels crippled to me. I can't really explain why, but when I can whip out a program in 10 minutes in C#, then spend hours getting the same thing going in C++, it's crippled.

Your definition of "crippled" is wrong.

Anyway, I'd have to say... Going by Tins of '05... Something that takes you 10 hours to code in C++ probably takes me 10 minutes.

And even then, do you even write C++? All of your code I ever remember seeing was C.

Also, do you remember bafirc? .. The C version. http://svn.bafserv.com/svn/bafirc/

;D

For a certain reason, this line really makes me laugh:
#define BAF_WOULD_BLOCK WSAEWOULDBLOCK

BAF
Quote:

I don't wish to sound pedantic, but language != language with libraries. You can't compare C++ without any libraries to C# and its libraries.

I was comparing std::string (C++'s standard library's string) to System.String (C#'s standard library's string).

bamccaig
axilmar said:

I don't wish to sound pedantic, but language != language with libraries. You can't compare C++ without any libraries to C# and its libraries.

BAF said:

I was comparing std::string (C++'s standard library's string) to System.String (C#'s standard library's string).

That's valid. C and C++ really weren't designed with strings as a priority. In fact, they were designed before strings became as common as they are today (string operations are expensive, especially on older hardware).

Still, I think the syntax of C++ is mostly awesome (I acknowledge the template vs. bit-wise operator problem - since I don't understand templates I'm oblivious to that :P) and could use some more up-to-date standard libraries.

I'm pretty satisfied with C♯ and C♭ (AKA D 8-)) as potential replacements.

HoHo
Quote:

Why don't you compare C# with Qt and tell us what you think?

It is kind of difficult since C# bindings are not ready yet. Though there are official Java bindings for QT and they are called QT Jambi

Goalie Ca

C++ is quite a wonderful language. It's flexible enough to do most things.

My two main gripes:

1) Library Support. std::libs sucks. C++0x is making a major push for more libraries to be made standard and some cleanup of the old libs. Most of the new stuff is from boost. Boost is a good way of doing things but it is only 1 way. C++ was designed to be flexible.. which is partly why there are so many different 3rd party libraries that each solve a problem in their own way with their own tradeoffs.
2) Syntactic Sugar (majorly needed!). How about a nice foreach, real lambda expressions, declare a function in a function, etc.

bamccaig

I was under the impression that C++0x was a new language, not a new standard for C++. ;D Excellent.

axilmar
Quote:

It is kind of difficult since C# bindings are not ready yet. Though there are official Java bindings for QT and they are called QT Jambi

But C# has libraries that offer functionality similar to Qt.

HoHo
Quote:

But C# has libraries that offer functionality similar to Qt.

There is nothing that could even remotely compete with QT ;)

spellcaster

I totally agree here. Qt is awesome. The new Qt Jambi (Qt for Java, basically) is awesome as well. And not only because I got a macbook from them ;)

Thomas Fjellstrom
Quote:

And not only because I got a macbook from them ;)

TT gave you a macbook? Where can I sign up?

spellcaster

Well, I won the Qt Jambi developer contest. 1st price was the macbook ;)

nonnus29
spellcaster

Mentioning tight lips in the same sentence as mo'fo made me pass out.

nonnus29

Sorry, I should've said 'non-self-promoting Mo'Fo'.

:-/

:-[

Rampage

Johnny Tightlips:

http://upload.wikimedia.org/wikipedia/en/5/5a/JohnnyTightlips.jpg

Thomas Fjellstrom
Quote:

Well, I won the Qt Jambi developer contest. 1st price was the macbook ;)

Wholy crap! Congrats!

23yrold3yrold
Quote:

Wow, that owns. 8-) Nice program, too.

spellcaster

Thanks ;)
Only problem is: I got my macBook and it included a program that basically did what I wanted my program to do. So, by winning the contest I basically ensured that I won't develop PowerComics any further.

MiquelFire

Now that sucks. That means us non-Mac users are SOL.

Archon

I don't know if this has been mentioned, but what I find that D beats C++ in, is:

  • Having the 'header' and code in the same file (like Java/C#)[/*]

  • No need to worry about circular #include s[/*]

  • Should be easier to parse since preprocessors can cause confusion when doing versions[/*]

  • You don't need to put preprocessor 'braces' to avoid multiple definitions[/*]
  • Though I think that D followed C++'s private/public/protected conventions:

    public:
       int mypublicvar1;
       int mypublicvar2;
    

    I prefer

    public int mypublicvar1;
    public int mypublicvar2;
    

    Arvidsson

    You can do both in D.

    Come to think of it, it's funny how important stylistic choices considering the syntax of a lanuage in fact are to us. I really hate the :: operator in C++, merely on the grounds that it's damn ugly. I like how D replaced the ::, -> and . operators with just a . operator. Nice and neat IMO.

    torhu
    Quote:

    1. No need to worry about circular #includes

    In theory, yes, but the implementation is lacking. At least it works in a consistent way in C. In the current D implementation (the two compilers use the same frontend), you never know when it's going to bite you. And how to get around it is just trial and error, really. But that'll hopefully improve.

    Quote:

    You can do both in D.

    Yup, you can even do this:

    public {
    int mypublicvar1;
    int mypublicvar2;
    }

    spellcaster

    Wow great!

    public:
      int foo;
    private int bar;
    private int baz;
    int foobar; // <-- should still be "public", right?
    private: int bop:
    public{ int gazonk };
    int barbaz; // <-- private, I guess?
    

    Neat.

    bamccaig
    spellcaster said:

    Wow great!

    public:
      int foo;
    private int bar;
    private int baz;
    int foobar; // <-- should still be "public", right?
    private: int bop:
    public{ int gazonk };
    int barbaz; // <-- private, I guess?
    

    Neat.

    Agreed. :-/ Though I think you wanted a semi-colon after int bop, not a colon.

    Matthew Leverton
    Quote:

    Come to think of it, it's funny how important stylistic choices considering the syntax of a lanuage in fact are to us. I really hate the :: operator in C++, merely on the grounds that it's damn ugly. I like how D replaced the ::, -> and . operators with just a . operator. Nice and neat IMO.

    This is the main reason why I hate using PHP. A class looks like:

    class Foo
    {
      private $bar; // ugly $
    
      public function boo($x)
      {
        $this->bar = $x; // always have to use $this and ->
      }
    }
    
    $foo = new Foo();
    $foo->boo(10);   // again, the $ and ->
    

    Likewise with C++:

    std::map<const char *, int> foo;
    for (std::map<const char *, int>::const_iterator i = foo.begin(); i != foo.end(); ++i)
    {
      const char *key = (*i).first;
      const int v = (*i).second;
    }
    

    Compare that to D:

    int[char[]] foo;
    foreach (key, v; foo)
    {
    }
    

    Of course you can typedef C++ to get less verbose, but still D is much more elegant. Ultimately (with just about every example) they both do the same conceptual things, but yet I find D more enjoyable.

    So yeah, I think you're right that the language's style or amount of "sugar" really has a lot to do with how we enjoy working with it. (Of course that sounds obvious, but I'm speaking more about the subtle differences of typing fewer keys.)

    Dustin Dettmer
    Quote:

    I like how D replaced the ::, -> and . operators with just a . operator. Nice and neat IMO.

    Wow, my_like_for_D--. I really don't like that many languages that use dot for everything.

    Quote:

    Having the 'header' and code in the same file (like Java/C#)

    Are there any more details on this? Personally I hate how Java and C# require all your functions to be inline... Are all methods inline in D? If thats the case...

    Arvidsson
    Quote:

    I really don't like that many languages that use dot for everything.

    Not for everything. Just for accessing class members.

    Quote:

    Are there any more details on this?

    According to this the compiler decides whether a function is inlined or not. But if you speak of inline in the sense that the function is defined within the class, then yes that is the case. Which is awesome.

    Thomas Fjellstrom
    Quote:

    Neat.

    Horrible coders produce horrible code. Always has been, allways will be.

    Kitty Cat
    Quote:

    Quote:

    I really don't like that many languages that use dot for everything.

    Not for everything. Just for accessing class members.

    Call me odd, by I actually like using '->' compared to '.' (forgoing the fact that I also like -> telling me it's dereferencing and getting a member, next to . saying it's getting the member right from the var). The :: "operator" isn't too bad, but I sometimes find myself wishing the compiler was smart enough so that I can use the var itself.. to take matthew's example:

    std::map<const char *, int> foo;
    for(foo.const_iterator i = foo.begin();i != foo.end();++i)
    {
      const char *key = i->first;
      const int v = i->second;
    }
    

    Though I probably could do typeof(foo)::const_iterator if I really wanted.

    Matthew Leverton

    I think that when people use a language so verbose as C++, over time they tend to believe that all of that complexity is needed in order to be efficient (in terms of runtime speed) and non-ambiguous. So when a language like D comes along and challenges the very notion that such complexity offers nothing, it's a bit of a culture shock.

    I don't think it's intentional, but it's almost like a superiority complex. C++ has more syntax, so it must be better. I know if it's dereferencing or not. But when it comes down to it, does it really matter? It's kind of like how we naturally get the feeling that the more a pair of shoes costs, the better made it is.

    For instance, when dealing with a class (Note that in D, the class is technically different from a struct in many ways):

    // C++
    MyFoo foo;
    foo.bar = 1;
    
    MyFoo *foo = new MyFoo();
    foo->bar = 1;
    

    Why does that distinction even matter when dealing with a class? I understand the technical difference, but as a programmer I don't care. (If I did care, I'd be working with assembly!) D only gives you one way:

    // D
    MyFoo foo; // just a reference to null
    foo = new MyFoo();
    foo.bar = 1;
    

    To me, in this case ... less is more.

    Obviously you can disagree with me because this is ultimately a personal choice. But I have a feeling that if D came along before C++, everybody would be laughing at C++.

    spellcaster
    Quote:

    Horrible coders produce horrible code. Always has been, allways will be.

    True. But by giving someone several ways of declaring visibility the language does help a bit.
    I mean, what if they'd allow to use ".", "->" and "::" as a dereference operator? Wouldn't that be great?

    D is a nice language. I just have trouble to understand the rationale behind some decisions.

    Matthew Leverton
    Quote:

    True. But by giving someone several ways of declaring visibility the language does help a bit.

    Yes, I dislike the "more than one way approach." (This is partly why I don't think offering . and -> for classes is very beneficial.) I would rather there only be one way to declare public or private. Personally, I like to explicitly declare it on each function, but I'd be fine with any single method that was consistent.

    In the end, it's the coder's fault for writing bad code. But I agree that the language can make it worse. Just take a look at the crap written in languages like PHP. (I don't mean to imply it's a horrible language; I just use it as an example because I know it the best.) PHP lets you do a lot of things in many ways, using a lot of shortcuts, and it ends up causing nearly every open-source PHP package to be riddled with ridiculous bugs.

    spellcaster

    Well, if you're working on larger pieces of code you'll have to work with code other people have written. Let's say Joe Coder prefers one way, Jane Coda prefers another way. Both work on the same project, but different parts of it. Sooner or later code from one part of the project will migrate into another part. Normally this happens if Jane is on vacation and a critical bug has been found in one of her modules. Since Joe is under pressure and he isn't familiar with her code, he starts doing things his way. He might add a comment like // TODO: Need to clean up this code which normally means this code won't be touched because everybody is too afraid breaking it. Or maybe it's because the code "works" and working 4h on a piece of code that already works, risking that it won't work exactly the same way as it did before is not in the interest of the company (= not paid for).

    Developing a language is like developing an API. You should try to get a slim but complete API.

    I'm used to code in C and Java. I know my way around C++ but I never considered it a language that works for me. If I want to code something fun and simple I use C. If I want to code something high level I use Java. Does the trick for me.

    D might allow me to use one language for both high level and low level stuff. Only problem for me is that I like to code games using "low level" stuff. I also like Java. Esp. the number of utility APIs I can use.
    As soon as it gets "high level" the amount of code that you don't need to code yourself becomes more important. So, right now, for me, Java wins the high level race against D and C wins the low level race.
    But both C and Java have to admit that it was a pretty close thing ;)

    bamccaig
    Dustin Dettmer said:

    Wow, my_like_for_D--. I really don't like that many languages that use dot for everything.

    Initially I thought I agreed with Dustin, but thinking about it for a second I think using the dot (.) operator alone is a better syntax rule. That said, I don't mind the -> or :: operators when used in C++ with their individual meanings. However, languages that use -> or :: in place of the dot (.) operator (I get the impression that PHP is one, but I haven't touched PHP in a while and can't remember doing object-oriented programming with it) are silly because the dot (.) operator is much more clean.

    Matthew Leverton

    PHP cannot use '.' because it already uses it for string concatenation. (The first versions had no OOP support, so it wasn't a problem.)

    Thomas Fjellstrom

    <Tomasu> C/C++ ROCKS: memset(&_data[Count * item_count + i], 0xDECAFBAD, sizeof(Type));

    8-)

    Dustin Dettmer
    Quote:

    But if you speak of inline in the sense that the function is defined within the class, then yes that is the case. Which is awesome.

    So they removed the linking feature. Interesting idea... This seems to be the 'modern language' way.

    File clutter prevention ranks high on my list, this takes a big chunk out of my favorability for D.

    Matt said:

    I think that when people use a language so verbose as C++, over time they tend to believe that all of that complexity is needed in order to be efficient (in terms of runtime speed) and non-ambiguous.

    A valid point. However, my primary like of having all dereference operators is for reading code. I can read ::blah and know exactly what is meant very quickly.

    I am overly harsh on the feature because of subconscious association with the recent trend to 'hide anything similar to a pointer'. I find myself staring at code for long periods of time trying to figure out what they hell kind of crazy reference solution this language decided to come up with.

    On another note (which doesn't really effect my personal selection of languages) things like hiding :: and -> increase the number of idiots who can get hired to write horrible code.

    Thomas Fjellstrom
    Quote:

    things like hiding :: and -> increase the number of idiots who can get hired to write horrible code.

    Three words: Python and PHP.

    torhu
    Quote:

    Quote:

    But if you speak of inline in the sense that the function is defined within the class, then yes that is the case. Which is awesome.

    So they removed the linking feature. Interesting idea... This seems to be the 'modern language' way.

    File clutter prevention ranks high on my list, this takes a big chunk out of my favorability for D.

    Not sure what you mean by 'removed the linking feature', but D is no different from C when it comes to compiling and linking. The source files act as headers when they are imported by other files. If you need it, you can have the compiler generate pure header files (*.di) from your source code.

    And a javadoc-like documentation system is built into the compiler, which means that you'll often get html documentation of the public API by just compiling with the -D argument. It's built in to make it more likely that at least basic docs are available. And it's really easy to use. No excuse for not keeping the source code clean and well organized, of course.

    Thomas Fjellstrom

    Can you tell D to output in some normalized XML format instead of HTML? I'd love to be able to whip docs through XSL to get me better looking docs in multiple formats.

    Dustin Dettmer
    Quote:

    Not sure what you mean by 'removed the linking feature'

    // blah.h
    class Blah {
      void someFunc();
    };
    

    // blah.cpp
    #include "blah.h"
    
    void Blah::someFunc()
    {
      cout << "Hello World";
    }
    

    blah.h provides a nice template and is late-linked with blah.cpp. Java/Ds linking methodology links everything at once.

    What a lot of people don't realize is C++ can do D's linking methodology and more. D has removed features. I don't really like that.

    Thomas Fjellstrom
    Quote:

    Java/Ds linking methodology links everything at once.

    Actually it doesn't. Individual class's in Java are stored in .class files and linked at load/run time. The .java files are just used as headers when you import one.

    Same with D. They are NOT linked at compile time, they are just compiled and verified.

    Quote:

    What a lot of people don't realize is C++ can do D's linking methodology and more.

    Ahh sorry no, its about the same, except D doesn't have that nasty header include c preprocessor crap to deal with.

    Dustin Dettmer
    Quote:

    Ahh sorry no, its about the same, except D doesn't have that nasty header include c preprocessor crap to deal with.

    Yes I enjoy the "nasty header include" feature. Thats not to say its for everybody, but its a feature that I enjoy very much and 'modern languages' appear to be dropping.

    Thomas Fjellstrom

    You actually enjoy having to handle the following:

    #define FOO 100+1
    int foo = FOO * 2; // does not do what any sane person would expect
    

    And:

    // bar.h
    #include "foo.h"
    
    // foo.h
    #include "bar.h"
    

    Really?

    bamccaig
    Thomas Fjellstrom said:

    #define FOO 100+1
    int foo = FOO * 2; // does not do what any sane person would expect
    

    If that's what you want it to do then it's very useful. Otherwise, use parenthesis. Oooh, hard.

    Thomas Fjellstrom said:

    // bar.h
    #include "foo.h"
    
    // foo.h
    #include "bar.h"
    

    I don't quite understand this part... :-/ Those are useless comments and equally useless comments could be applied in D.

    import foo.bar; // zoo.car
    import zoo.car; // foo.bar
    

    I don't understand the Java package system... Where the hell do they come from and how do I make mine available on the system!? >:( The answer seems to be with the classpath which means I have to do the same thing as include it, but instead I have to add it to the system's classpath or I have to pass it everytime I compile. I think... >:( Stupid! In college when we built GUI apps using NetBeans everything was automatically set up so the programs would run from the IDE... If you tried to compile and run outside the IDE the classpath was missing a ton of packages and that basically meant we couldn't actually use them... ::)

    How does D's (C♭'s) package system work? :-/ Where do the packages come from and how do you add them to a build?

    P.S. In the time I've spent trying to learn how D does things I've learned that D's documentation sucks.

    Thomas Fjellstrom
    Quote:

    If that's what you want it to do then it's very useful. Otherwise, use parenthesis. Oooh, hard.

    Wow. Learn to think once in a while. Its about having to handle that specially. shouldn't be necessary.

    Quote:

    I don't quite understand this part... :-/ Those are useless comments and equally useless comments could be applied in D.

    Doubly for this one. ::)
    These comments are there to tell you what file they would be in. Wow.

    Onewing
    Quote:

    I don't quite understand this part...

    He's mentioning the circular logic of bar.h including foo.h and vice versa, which is confusing. It's like trying to define a word by using a word that is defined by the word you are trying to define. Wha? ???

    [edit] see above post.

    Hard Rock
    Quote:

    Doubly for this one. ::)
    These comments are there to tell you what file they would be in. Wow.

    Does that even work? In any case you can get around this by using forward declaration.

    Quote:

    I don't understand the Java package system... Where the hell do they come from and how do I make mine available on the system!? >:( The answer seems to be with the classpath which means I have to do the same thing as include it, but instead I have to add it to the system's classpath or I have to pass it everytime I compile. I think... >:( Stupid! In college when we built GUI apps using NetBeans everything was automatically set up so the programs would run from the IDE... If you tried to compile and run outside the IDE the classpath was missing a ton of packages and that basically meant we couldn't actually use them... ::)

    I've got a suggestion for you. Why don't you actually try figuring out how it works rather then guessing on something which you apparently know nothing about?

    In any case they work nearly identical to dlls. You have a global classpath you can put all your libraries in, you can also just drop them next to the application your are running and they will automatically be detected.

    spellcaster

    No, it doesn't work. Unless you take care. That's his point.
    At some point, this thread moved from "look how nice D is" to "see, C++ isn't THAT bad, see? SEE?!"

    bamccaig
    Thomas Fjellstrom said:

    Wow. Learn to think once in a while. Its about having to handle that specially. shouldn't be necessary.

    If you were writing the expression you would need the parenthesis anyway. It's no more work than an expression normally requires. And if you actually want FOO*2 to expand into 100+1*2 then it's useful and necessary.

    Thomas Fjellstrom said:

    Doubly for this one. ::)
    These comments are there to tell you what file they would be in. Wow.

    A few simple preprocessor instructions handle that. It's nothing that should make or break the deadline.

    If you're going to illustrate that it's better to separate them so that it looks like the code is from different sources. It takes of couple of seconds and makes what you're trying to say clear.

    bar.h...
    #include "foo.h"
    foo.h...
    #include "bar.h"
    Afterall, it's not very often you see a file with a single preprocessor instruction. :)

    spellcaster said:

    At some point, this thread moved from "look how nice D is" to "see, C++ isn't THAT bad, see? SEE?!"

    No, it went from "D does things nicely" to "C/C++ sucks" to "No, C/C++ doesn't suck".

    Kitty Cat
    Quote:

    And a javadoc-like documentation system is built into the compiler, which means that you'll often get html documentation of the public API by just compiling with the -D argument. It's built in to make it more likely that at least basic docs are available.

    One could argue, no docs are better than bad/incomplete/incorrect docs. If you're not willing to take the time to make proper documentation, the "documentation" is generally not worth reading (just look at ALSA).

    spellcaster

    The point is not that you can't do something with C/C++. It's that some things are - compared to todays standards - not really elegant.

    Thomas Fjellstrom
    Quote:

    Afterall, it's not very often you see a file with a single preprocessor instruction. :)

    Its called an example. Pseudo code even.

    Quote:

    If you were writing the expression you would need the parenthesis anyway.

    Not really:

    const int foo = 1+2;
    int bar = foo * 2;
    

    You can do that now, and should. But people like their pre processor ::)

    Matthew Leverton

    As Snoopy once said, "Good jokes are wasted on birds."

    bamccaig
    Thomas Fjellstrom said:

    Its called an example. Pseudo code even.

    An unclear example is a poor example. Take a second to make your point clear or expect to clarify. And your example was code. Pseudocode is...

    bar.h...
    include foo.h

    foo.h...
    include bar.h
    Not that included files necessarily belong in pseudocode in the first place. :)

    Thomas Fjellstrom said:

    You can do that now, and should. But people like their pre processor ::)

    Which you can do in C++ as well... You don't need D for that.

    Thomas Fjellstrom

    It was perfectly clear to everyone else. Why not you?

    You need hand holding perhaps?

    bamccaig
    Thomas Fjellstrom said:

    It was perfectly clear to everyone else. Why not you?

    You need hand holding perhaps?

    I'm busy with other things. I assumed you were capable of expressing ideas. And "everyone" in this case is like 4 people. ::) Maybe they're just used to interpreting your posts.

    Thomas Fjellstrom

    Yup. Same old bamccaig. Expecting everyone else to hand hold him cause he's "too busy" to think for himself. ::)

    Tobias Dammers

    bamccaig: What are you, mentally challenged? The example is perfectly clear. If you have two files, foo.h and bar.h, each one including the respective other, then you are in a nasty situation. Each file is, by itself, perfectly OK, and you cannot see by looking at any one of them that something is wrong. But use them together, and the compiler will yell at you. And while the example is overly simple (as to clarify things: it is boiled down to the essential part), it illustrates the problem in a way that everybody who has encountered circular dependency issues before will recognize it.
    Of course it only becomes a problem when a project grows huge, and it isn't obvious at a glance which files exactly cause the problem. And the solution, while simple and easy, isn't a very satisfactory one. Consider these classes:
    (parent.h)

    #include "child.h"
    
    class cParent {
      protected:
        cChild* child;
        int bar;
      public:
        int get_bar() const { return bar; }
        int get_child_foo() const { if (child) return child->get_foo(); else return 0; }
    };
    

    (child.h)

    #include "parent.h"
    
    class cChild {
      protected:
        cParent* parent;
        int foo;
      public:
        int get_foo() const { return foo; }
        int get_parent_bar() const { if (parent) return parent->get_bar(); else return 42; }
    };
    

    The solution in this scenario would be to put the function bodies of one class into a separate .cpp file, at least those that use an instance of the other class by value, or dereference a pointer to one.

    There are 2 problems with this:
    - Performance; the out-sourced member functions cannot be inlined. Not a major issue usually, but still.
    - Limited templating. If both classes are templates, then we have a problem. Though one might argue that this may be a sign of over-using templates.

    bamccaig
    Tobias Dammers said:

    What are you, mentally challenged?

    No. Are you?

    Tobias Dammers said:

    The example is perfectly clear...it illustrates the problem in a way that everybody who has encountered circular dependency issues before will recognize it.

    Perfectly clear. ::) I haven't encountered circular dependency issues before. It sounds silly to have two classes each with a member of each other. Do you have an actual correct model where it's applicable? (I've never modeled anything like that before so it's hard to imagine).

    spellcaster
    Quote:

    Mind you, your example was a million times better than Thomas Fjellstrom's.

    Please PM me when we start comparing penis sizes.

    Hard Rock
    Quote:

    It was perfectly clear to everyone else. Why not you?

    I'll probably look like an idiot for writing this, but initially the way you wrote it I didn't follow what you were trying to show either. I can now understand why you wrote it like that (less bbcode) but in any case....

    Dustin Dettmer
    Tobias said:

    Of course it only becomes a problem when a project grows huge, and it isn't obvious at a glance which files exactly cause the problem. And the solution, while simple and easy, isn't a very satisfactory one. Consider these classes:
    (parent.h)

    Exactly! :) and D dumbs down the linking interface so circular dependencies are harder to solve.

    On a personal note my style prefers to have the class skeleton in its own file (keeping file size down is an ongoing problem for me).

    Jonny Cook

    I've always thought that if a program required circular referencing, in many cases, it was because of a design flaw. After working with a program written in C# and seeing how many circular references have been made, and how absolutely horrible it is to work with the code, I'm starting to like C/C++s way of making it hard to do circular references. It prevents people from making circular references all the time, and thus, requires them to put more thought into their design. Of course, that's just my theory. It could be wrong.

    bamccaig
    Dustin Dettmer said:

    Exactly! :) and D dumbs down the linking interface so circular dependencies are harder to solve.

    Are circular dependencies even an issue in D? I thought the whole point was that D eliminates that problem... :-/

    Onewing
    Quote:

    Please PM me when we start comparing penis sizes.

    "...and I see your Schwartz is as big as mine. Let's see how well you handle it."

    bamccaig
    spellcaster said:

    Please PM me when we start comparing penis sizes.

    I need an adult! I need an adult! :'(

    Thomas Fjellstrom
    Quote:

    I need an adult! I need an adult! :'(

    Don't worry, he is one. And quite good at what he does too. 8-)

    Rampage

    Man, this threads are fun.

    Quote:

    Exactly! :) and D dumbs down the linking interface so circular dependencies are harder to solve.

    If D's linking is truly like Java's, there are no problems with circular dependencies like in C/C++. You just have to compile the two interdependent files at the same time. 8-)

    Lars Ivar Igesund

    D handles circular dependencies pretty well, but one should still avoid it as it seldom is a sign of good design. There are some situations in D where you need to be aware of it, and that is if you use module constructors or static ctors, as these will be called in dependency sequence. Thus two mutually dependent modules can't both have such constructors.

    As the coverage functionality in DMD depends on module ctors, it won't work if you have cycles in your module dependency graph.

    torhu
    Quote:

    If D's linking is truly like Java's, there are no problems with circular dependencies like in C/C++. You just have to compile the two interdependent files at the same time. 8-)

    Unfortunately, that doesn't help. The circular dependencies issues that you sometimes get when there's a lot of files (I've run into the problem once or twice with DAllegro, which is around 50 files), can only be solved by moving things around, or sometimes change the order of the import statements. The last time I got it, I moved the definitions that caused the problem into a file of its own.

    D is not suppposed to have this problem, it's just one of the things that its creator (which also is the sole developer of the DMD compiler) hasn't gotten around to fixing yet. Even though he seems to be a a one-man army of coders, he can't do it all at once.

    Someone mentioned that the D documentation sucks, and I agree. The most useful page not on the digitalmars.com site is probably this one:

    http://www.prowiki.org/wiki4d/wiki.cgi?LanguageSpecification/KeywordIndex

    It links to documentation for different uses of all the D keywords, and helped me a lot when I was learning D. Very handy if you already know C++ or Java, and just want to know how D does things differently.

    Kitty Cat
    Quote:

    Someone mentioned that the D documentation sucks, and I agree.

    What I said was that having no documentation is better than bad/incorrect documentation. I couldn't tell you how good D's documentation is, as I've never read it. I just mean to say that having a documentation parser in the compiler is nothing I'd tout as a "feature" because it'll just encourage lazy (bad/incorrect) documentation.

    I've yet to see any documentation generator that uses source code comments to produce documentation, make good documentation and leave the source code readable.

    Unless you're not talking about what I said. :P

    Lars Ivar Igesund

    When torhu talks about circular dependency problems, I believe he actually talks about forward referencing bugs. This is a problem with the compiler, but are "only" bugs, not something inherent in the language itself. They tend to crop up when porting headers/wrapping API's of other libraries, probably because you get structures that you wouldn't otherwise have used when just coding in D, and if the library is large enough, they become hard to track down. It's been a couple of years since I came across a forward reference problem myself.

    The cases where the language prevents circular dependencies are those mentioned in my previous post, and these are well defined and documented.

    torhu
    Quote:

    What I said was that having no documentation is better than bad/incorrect documentation. I couldn't tell you how good D's documentation is, as I've never read it. I just mean to say that having a documentation parser in the compiler is nothing I'd tout as a "feature" because it'll just encourage lazy (bad/incorrect) documentation.

    I've yet to see any documentation generator that uses source code comments to produce documentation, make good documentation and leave the source code readable.

    DDoc is cleaner than javadoc or doxygen. Most or all of digitalmars.com/d is created using DDoc. I encourage you to download the dmd compiler and read the library source in the source/phobos dir. DDoc is somewhere in between NaturalDocs and javadoc when it comes to how nice it looks in the source code.

    /**
     * Do what it takes, and do it good.
     *
     * Params:
     *       x = that's the first one.
     *       y = that's the second one.
     *
     * Returns: The answer to everything.
     *
     * Note: I was pretty drunk when writing this :p
     */
    int doStuff(int x, int y) { */ stuff here */ }
    

    Compile that with 'dmd -c -D dostuff.d'. :)

    bamccaig
    torhu said:

    Someone mentioned that the D documentation sucks, and I agree. The most useful page not on the digitalmars.com site is probably this one:http://www.prowiki.org/wiki4d/wiki.cgi?LanguageSpecification/KeywordIndex

    It links to documentation for different uses of all the D keywords, and helped me a lot when I was learning D. Very handy if you already know C++ or Java, and just want to know how D does things differently.

    Thanks. ;D

    Kitty Cat said:

    What I said was that having no documentation is better than bad/incorrect documentation. I couldn't tell you how good D's documentation is, as I've never read it. I just mean to say that having a documentation parser in the compiler is nothing I'd tout as a "feature" because it'll just encourage lazy (bad/incorrect) documentation.

    I've yet to see any documentation generator that uses source code comments to produce documentation, make good documentation and leave the source code readable.

    Unless you're not talking about what I said. :P

    I don't know who he was referring to, but I did specifically say that...

    bamccaig said:

    In the time I've spent trying to learn how D does things I've learned that D's documentation sucks.

    torhu said:

    Most or all of digitalmars.com/d is created using DDoc.

    Then I just lost faith in DDoc... :'( I'm not really talking about the appearance, but of the content... Just trying to find a page specific to the import statement and packages and how they work is impossible... WTF!?

    Archon
    Quote:

    It sounds silly to have two classes each with a member of each other.

    Nope. If they both have pointers to each other, then it's perfectly fine for them to reference each other - so they can interact. How else is is objectB going to send messages to objectA? Events?

    Thomas Fjellstrom
    Quote:

    I'm not really talking about the appearance, but of the content... Just trying to find a page specific to the import statement and packages and how they work is impossible... WTF!?

    Click "Language" in the first menu block, then "Modules" the second item in the second menu block.

    23yrold3yrold
    Quote:

    Nope. If they both have pointers to each other, then it's perfectly fine for them to reference each other

    They're not talking pointers though, at least I don't think they are. Otherwise what's the big deal?

    Bob

    Does D even have stack allocated objects? If not, then the point of it handling circular dependencies is moot: there are no circular dependencies, and that's how that problem is "solved".

    Finally, please behave. No personal insults. You know who you are.

    bamccaig

    The following seems relevant to the recent discussion on circular dependencies...

    Modules - D Programming Language - Digital Mars said:

    Cycles (circular dependencies) in the import declarations are allowed as long as not both of the modules contain static constructors or static destructors. Violation of this rule will result in a runtime exception.

    - Source

    Thomas Fjellstrom said:

    Click "Language" in the first menu block, then "Modules" the second item in the second menu block.

    Thanks... IMO, it should be Reference or Language Reference. Everything in the /d directory is about the language... :-/ I'm not a fan of that site's design. That article on Modules never did explain where files/directories need to be or how you associate them with a build... :-/ They did say that packages are I think equivalent to filesystem directories and modules are equivalent to a single source file... :-/

    I'm also not a fan of D's Module Scope Operator... :-/

    int x;
    
    int foo(int x)
    {
        if (y)
      return x;    // returns foo.x, not global x
        else
      return .x;    // returns global x
    }
    

    I think a global or module keyword would make it more clean... :-/ There must be a better option than using the dot operator... :-/

    int x;
    
    int foo(int x)
    {
        if (y)
      return x;    // returns foo.x, not global x
        else
            return module.x;  // returns global x
    // -- OR --
            return module_name.x;  // returns global x
    }
    

    VBScript uses a preceding dot operator inside it's With statement to access the With's object... :-/ I'm sort of used to that... I prefer that to JavaScript where you just directly access the properties/methods... Apparently D's with statement has syntax similar to JavaScript... :-/

    // VBScript
    With objObject
        .Property = intValue;
        .Method()
    End With
    

    // D | JavaScript
    with(objObject)
    {
        property = intValue;
        method();
    }
    

    Lars Ivar Igesund
    Quote:

    Does D even have stack allocated objects?

    Yes.

    Dustin Dettmer
    Lars Ivar Igesund said:

    The cases where the language prevents circular dependencies are those mentioned in my previous post, and these are well defined and documented.

    I'm having a hard time understanding... could you translate this code into D for me?

    // header.h
    class Bar;
    
    class Foo {
      void foo();
      void bar();
      Bar *b;
    };
    
    class Bar {
      void foo();
      void bar();
      Foo *f;
    };
    

    1// source.cpp
    2void Foo::foo()
    3{
    4 cout << "Foo\n";
    5}
    6 
    7void Foo::bar()
    8{
    9 b->bar();
    10}
    11 
    12void Bar::foo()
    13{
    14 f->foo();
    15}
    16 
    17void Bar::bar()
    18{
    19 cout << "Bar\n";
    20}

    Matthew Leverton

    In one file:

    1module ref;
    2 
    3import std.stdio : writefln;
    4 
    5class Foo
    6{
    7 public Bar b;
    8
    9 public void foo()
    10 {
    11 writefln("Foo");
    12 }
    13 
    14 public void bar()
    15 {
    16 b.bar();
    17 }
    18}
    19 
    20class Bar
    21{
    22 public Foo f;
    23 
    24 public void foo()
    25 {
    26 f.foo();
    27 }
    28 
    29 public void bar()
    30 {
    31 writefln("Bar");
    32 }
    33}
    34 
    35int main()
    36{
    37 Foo f = new Foo();
    38 Bar b = new Bar();
    39 
    40 f.b = b;
    41 b.f = f;
    42 
    43 f.foo();
    44 f.bar();
    45 b.foo();
    46 b.bar();
    47 
    48 return 0;
    49}

    Compile with: dmd ref.d -ofref.exe

    Or in multiple files:

    foo.d

    1module foo;
    2 
    3import std.stdio : writefln;
    4 
    5import bar;
    6 
    7class Foo
    8{
    9 public Bar b;
    10
    11 public void foo()
    12 {
    13 writefln("Foo");
    14 }
    15 
    16 public void bar()
    17 {
    18 b.bar();
    19 }
    20}

    bar.d

    1module bar;
    2 
    3import std.stdio : writefln;
    4 
    5import foo;
    6 
    7class Bar
    8{
    9 public Foo f;
    10 
    11 public void foo()
    12 {
    13 f.foo();
    14 }
    15 
    16 public void bar()
    17 {
    18 writefln("Bar");
    19 }
    20}

    ref.d

    1module ref;
    2 
    3import foo, bar;
    4 
    5int main()
    6{
    7 Foo f = new Foo();
    8 Bar b = new Bar();
    9 
    10 f.b = b;
    11 b.f = f;
    12 
    13 f.foo();
    14 f.bar();
    15 b.foo();
    16 b.bar();
    17 
    18 return 0;
    19}

    Compile with: dmd ref.d foo.d bar.d -ofref.exe. Or:

    dmd -c ref.d
    dmd -c foo.d
    dmd -c bar.d
    dmd ref.obj foo.obj bar.obj -ofref.exe
    

    Dustin Dettmer

    Ah ok, so theres a sort of 'late-binding'. I suppose I'm just too "C++ trained" to think of this sort of solution.

    HoHo
    Quote:

    I think a global or module keyword would make it more clean... :-/ There must be a better option than using the dot operator... :-/

    IIRC, in C++ you replace .x with ::x to get the global variable. Much better, isn't it?
    :P

    bamccaig
    HoHo said:

    IIRC, in C++ you replace .x with ::x to get the global variable. Much better, isn't it?
    :P

    :-/ That's ugly too... WTF!? >:( It wouldn't really be an issue for my code because I prefix all global variable identifiers with a 'g'.

    int gintGlobalInteger = 0;
    char[] gstrGlobalString = "";
    Object gobjGlobalObject = new Object();
    

    Jonny Cook

    Ewwwwww. Hungarian notation is icky.

    Thomas Fjellstrom
    Quote:

    It wouldn't really be an issue for my code because I prefix all global variable identifiers with a 'g'.

    Uhghghg. ewwww. Next you'll be telling me you also like: "wzpstrSomeStupidString".

    bamccaig
    bamccaig said:

    Ewwwwww. Hungarian notation is icky.

    I find that it can be useful.
    [quote ]Uhghghg. ewwww. Next you'll be telling me you also like: "wzpstrSomeStupidString".
    </quote>
    Nah, I try to keep it simple. If it's not a common type (int, short, long, float, double, char, string) then it's usually grouped in the object category (prefix obj).

    It's not perfect, but I find that it's useful anyway. I'd prefer a better way, but just plain variable identifiers seem even less organized to me. Especially when they have no underscores or case changes...

    int numberofrecords; // Ugly.
    int NumberOfRecords; // Acceptable.
    int intNumberOfRecords; // ;D
    

    My only problem with 'Hungarian notation' is that I haven't figured out a clean way to prefix arrays or pointers... :-/

    int *p_intNumberOfRecords;  // Recently I've been experimenting with a p_
                                // prefix for pointers...
    
    int *p_gintNumberOfRecords; // The problem is when it's a global pointer...
    //         -- OR --
    int *gp_intNumberOfRecords; // It gets a little bit more messy... :'(
    
    int intPlayerIDs[10]; // Don't know what to do for arrays aside from using a plural 
                          // identifier...
    //       -- OR --
    int intPlayerIDArray[10]; // Or you can add an 'Array' postfix.
    

    :-/

    I find it's extra useful in OOP because your private members get prefixes and your public accessors don't.

    1#include <iostream>
    2 
    3class Example
    4{
    5private:
    6 int mintMember; // m=module-level scope, int=integer
    7public:
    8 int Member(void)
    9 {
    10 return mintMember;
    11 }
    12 
    13 void Member(int intMember)
    14 {
    15 mintMember = intMember;
    16 }
    17};
    18 
    19int main(int argc, char* argv[])
    20{
    21 Example *objExample = new Example();
    22 
    23 cout << "Member: " << objExample->Member(); << endl; // Garbage.
    24 objExample->Member(32);
    25 cout << "Member: " << objExample->Member(); << endl; // 32.
    26 
    27 delete objExample;
    28 
    29 return 0;
    30}

    Jonny Cook

    There is no clean form of Hungarian notation. It's just plain icky.

    Thomas Fjellstrom
    Quote:

    int numberofrecords; // Ugly.
    int NumberOfRecords; // Acceptable.
    int intNumberOfRecords; // ;D

    I prefer record_count.

    bamccaig
    Thomas Fjellstrom said:

    I prefer record_count.

    I don't really mind that. If it was just recordcount then I'd say it could use something to make it more clean. I picked up Hungarian notation from the VB.NET classes in college whose textbook used it. It was new to me then and I kind of liked it so I started using it regularly. :-/:)

    int RecordCount;    // Normally I would use RecordCount as the identifier, but
    //     -- OR --     // I was just making up a quick example.
    int intRecordCount;
    

    Thomas Fjellstrom

    I might use recordCount if I was coding C++/Qt.

    Dustin Dettmer

    recordCount or numRecords here. Though to be honest, if the variable was just a count of the records it'd likely be short-scoped. Short-scoped variables I just name generic crap like count or num.

    bamccaig
    Dustin Dettmer said:

    Short-scoped variables I just name generic crap like count or num.

    :o Count of what!? What num!? :'( Personally I was taught to use descriptive variable names at all times. I prefer to use descriptive names so that my code and variables explain adequately what should be happening... And comments fill in the rest. Otherwise, somebody needs to figure out where count or num are coming from and what they represent.

    It's also messy if another count or num is required in the same scope because then you need to rename the other variables or work around it with the new variables. Do I hear a count2/num2? :P

    Thomas Fjellstrom
    Quote:

    :o Count of what!? What num!? :'(

    Context my man. If its a really small if or loop, you know what its a count of. its like using i for a loop var.

    Jakub Wasilewski
    Quote:

    it's like using i for a loop var.

    You mean intI? :)

    bamccaig
    Thomas Fjellstrom said:

    Context my man. If its a really small if or loop, you know what its a count of. its like using i for a loop var.

    I always declare variables at the top of the file, function, or method. So the smallest scope my variables have is function/method-level. I think the only exception is for loop control variables (see below ;)).

    Jakub Wasilewski said:

    You mean intI? :)

    This is where it gets a little bit awkward using Hungarian notation in C/C++ (or C-like languages)... I like using i in those languages, but then it changes naming conventions... In VB-like languages I usually use intIndex. In C-like languages, I usually use i, j, k, l, etc... :-/

    I can't even find any C/C++ code that I've written lately that uses Hungarian notation AND has any need for iteration counters or array indexes... :-/ I don't know what I do!? :'(

    Actually, the simple chat server/client programs that I wrote to demonstrate sockets programming used Hungarian notation and just used i as a for loop control variable. :) I'm happy with that for now...

    Thomas Fjellstrom
    Quote:

    You mean intI? :)

    Kill me now.

    Dustin Dettmer
    Quote:

    So the smallest scope my variables have is function/method-level.

    My functions tend to be small enough to be small-scoped themselves :D.

    God I love small and well documented functions. Why must I always be forced to interface functions without defined purpose?

    bamccaig
    Dustin Dettmer said:

    My functions tend to be small enough to be small-scoped themselves :D.

    Prove it. ;D

    Dustin Dettmer
    bam said:

    Prove it. ;D

    Oh ok sure. Pick a method:

    1 // Updates the target mice. Should be called at a constant rate.
    2 // Primarily handles removing the mice when its time for them to go away.
    3 void think();
    4 
    5 // Used to specify a ball postion for hitsMouse
    6 struct Ball { int x, y, radius; };
    7 
    8 // Returns a TargetMouse instance if 'ball' hits one of the target mice on
    9 // the screen. If 'ball' hits none of the target mice on the screen hitMouse
    10 // returns 0. The caller may destroy the returned TargetMouse if they so please
    11 // using TargetMouse methods but may *NOT* call delete on the pointer.
    12 TargetMouse* hitsMouse(Ball ball);
    13
    14 // Calculates if its time to spawn a new TargetMouse and if nessicary does so
    15 // 'circles' represents the current level, its used to determine where the
    16 // mice will land.
    17 //
    18 // If 'force' is false there is some chance that a mouse will be spawned.
    19 void calculateSpawns(Circles &circles, bool force = false);
    20
    21 // Returns the number of mice that are onscreen
    22 int numberMice();
    23 
    24 // The number of mice that had the 'isDead' flag enabled when they were erased.
    25 // isDead is set when the mice are killed by the user (as opposed to simply expiring
    26 // because of old age).
    27 int numberKilledMice;
    28 
    29 // The number of mice that did not have the 'isDead' flag enabled when they were
    30 // erased. isDead is set when the mice are killed by the user (as opposed to simply
    31 // expiring because of old age).
    32 int numberExpiredMice;
    33 
    34 // Gets rid of all the mice.
    35 void clear();
    36
    37 // Draws all the target mice to the screen.
    38 // 'circles' represents the current level, its used to determine how much
    39 // the level has rotated so the mice can be rotated the correct amount.
    40 // If eyesAllowedInCenter is true there is a slight probability that blinking mouse eyes
    41 // will be drawn on top of the center hole.
    42 void draw(bool eyesAllowedInCenter, Circles &circles, const Tint &tint = Tint());

    nonnus29

    Wow, you guys argue about some stupid sh*t.

    ::)

    MiquelFire

    It's bam's fault! He's normally the one to start it.

    Bob
    Matthew said:

    In one file:

    That doesn't seem to solve anything beyond C. C does it in exactly the same way.

    1class Foo
    2{
    3public:
    4 class Bar* b;
    5
    6 void foo()
    7 {
    8 std::cout << "Foo";
    9 }
    10 
    11 void bar()
    12 {
    13 b->bar();
    14 }
    15};
    16 
    17class Bar
    18{
    19public:
    20 class Foo *f;
    21 
    22 public void foo()
    23 {
    24 f->foo();
    25 }
    26 
    27 public void bar()
    28 {
    29 std::cout << "Bar";
    30 }
    31};
    32 
    33int main()
    34{
    35 Foo *f = new Foo();
    36 Bar *b = new Bar();
    37 
    38 f->b = b;
    39 b->f = f;
    40 
    41 f->foo();
    42 f->bar();
    43 b->foo();
    44 b->bar();
    45 
    46 delete f; // Ok, so you need to manage memory manually...
    47 delete b;
    48 
    49 return 0;
    50}

    Matthew Leverton

    Dustin's example was fairly trivial... all I was doing was translating it to D.

    Bob

    This is why I asked if D has stack-allocated non-POD types. If so, then you should be able to do away with your 'new' calls. If not, then the point is moot because C++ also supports the same feature. You just have to remember to use pointers explicitly (as opposed to implicitly, as in D).

    Lars Ivar Igesund

    You can allocate on the stack by doing

    scope MyObj mystackinstance = new MyObj;

    axilmar
    Quote:

    I think that when people use a language so verbose as C++, over time they tend to believe that all of that complexity is needed in order to be efficient (in terms of runtime speed) and non-ambiguous. So when a language like D comes along and challenges the very notion that such complexity offers nothing, it's a bit of a culture shock.

    I think you overstating things a bit. D is quite similar to C++: it's an imperative object-oriented programming language, very much like C++, C# and Java.

    If you program anything in Haskell/Lisp/Oz, then you could say it's a culture shock.

    For me, D is not real progress in the domain of programming languages, for the following reasons:

    1) D does not help really cut down the amount of code it has to be written for a specific task. D might eliminate some of the tedious typing of C++ (namely: headers, pointers, the operator -> etc) but that is not where the bulk of work is in a program. Most algorithms in C++ are exactly the same in D anyway.

    2) most bugs in a C++ program would be bugs as well in a D program, even if the consequences in the latter are less catastrophic: null pointers, out of bounds indexes, wrong order of operations etc.

    What I would like to see is a truly advanced programming language that really minimizes development time:

    -more declarative programming, less imperative programming.
    -catches logic errors.
    -allows for interactive compilation.
    -allows for incremental development.

    In the end, a D program can be as spaghetti as a C++ program. For me, there is no real reason to migrate to D, especially when the libraries are of high quality (Qt for example) and the job gets done with minimal fuss in C++.

    Lars Ivar Igesund
    Quote:

    1) D does not help really cut down the amount of code it has to be written for a specific task. D might eliminate some of the tedious typing of C++ (namely: headers, pointers, the operator -> etc) but that is not where the bulk of work is in a program. Most algorithms in C++ are exactly the same in D anyway.

    DMDScript, which is a fairly direct C++ -> D port of DMCScript, have 30% fewer lines of code, much because of the lack of tedious typing of explicit memory allocation (yes, I know the next revision of C++ will have optional garbage collection). Several bugs where also caught by the index checking and similar features. It may not be revolution, but a rather huge step in evolution.

    As for incremental development, this is much easier to do in D, if only because it is so much faster to compile.

    HoHo
    Quote:

    As for incremental development, this is much easier to do in D, if only because it is so much faster to compile.

    I can turn off all sorts of fancy optimization flags when compiling my programs and have stuff compiled in a blink of an eye, for multiple files having high-end multicore system also helps quite a bit.

    Though there is one thing that often takes quite a bit of time: linking. Is D compiler any faster than C/C++ compilers (gcc) in that area?

    Lars Ivar Igesund

    The object files are the same, so the linking usually takes the same amount of time (not that I have been bothered by that). Compilation and linking takes a few seconds for larger projects. The linker that comes with the windows version of DMD is blindingly fast though.

    On linux I see a notable slow down when using GDC instead of DMD as the compiler (gcc is used for linking in both cases). This is mainly due to GDC not yet being able to process all files at once.

    Templates can slow down compilation a bit, but is still quite a bit faster than C++ afaik.

    axilmar
    Quote:

    DMDScript, which is a fairly direct C++ -> D port of DMCScript, have 30% fewer lines of code, much because of the lack of tedious typing of explicit memory allocation (yes, I know the next revision of C++ will have optional garbage collection). Several bugs where also caught by the index checking and similar features. It may not be revolution, but a rather huge step in evolution.

    It all depends in the code you write. In Qt, for example, memory management is almost implicit: you never have to delete objects yourself...similar code as in Java Swing.

    Quote:

    As for incremental development, this is much easier to do in D, if only because it is so much faster to compile.

    It may be slightly easier, but not as interactive as I would like. I have played with Common Lisp a little, and interactive development is so much better than the cycle edit-compile-debug.

    Lars Ivar Igesund
    Quote:

    It may be slightly easier, but not as interactive as I would like. I have played with Common Lisp a little, and interactive development is so much better than the cycle edit-compile-debug.

    But then you are talking about interpreted languages, which is quite a different beast (even if it in theory is possible to interpret D).

    torhu

    About the speed of DMD. I posted this in another thread, which is compiling C code, but DMD uses the same code generator as DMC does. Building allegro with dmc is supported in the 4.2 svn branch.

    Quote:

    Command: 'gmake lib STATICLINK=1 ALLEGRO_USE_C=1'

    GCC: 107 seconds
    msvc6: 55 seconds
    DMC: 42 seconds

    I did this a few times and got similiar timings. Of course, this is C, not C++.

    Comparing GDC to DMD is not entirely fair, since like Lars Ivar said, GDC compiles one file at a time, while DMD accepts all the files at once. Building a static link library version of DAllegro takes 0.5 secs with dmd and 11 secs when using gdc's gdmd frontend (gdmd is a perl script). That difference means you don't need a makefile with dmd in this case.

    It's also perfectly reasonable to use dmd for script-like tasks. On unix, just put '#! /bin/dmd -run' at the top of the file, and it's compiled to a temporary file and run. This might sound silly, but it makes sense when you need some special processing done during the build process of a D library, etc. Windows doesn't come with a usable scripting language, so it's a way to avoid the need for extra tools. But I admit it's more of a gimmick sometimes. What I mostly use -run for is to compile and run small test programs etc. No executable or object files are left when the program exits.

    axilmar
    Quote:

    But then you are talking about interpreted languages, which is quite a different beast (even if it in theory is possible to interpret D).

    You can develop in an interpreted language environment, and when you are satisfied with the result, you can produce an executable.

    Lars Ivar Igesund

    Yes, but since D compiles so fast and compiled code probably will execute so much faster than interpreted D, the environment you want would probably be better implemented by making a somewhat more innovative IDE that appears to look like an interpreter by wrapping the compiled executables.

    axilmar
    Quote:

    Yes, but since D compiles so fast and compiled code probably will execute so much faster than interpreted D, the environment you want would probably be better implemented by making a somewhat more innovative IDE that appears to look like an interpreter by wrapping the compiled executables.

    The point of interactive development is not to have to run the program from the start each time you want to change something. Compiler speed is irrelevant.

    Thread #591787. Printed from Allegro.cc