On 9/3/2015 3:27 AM, Manu via Digitalmars-d wrote:
> Our major active project at work also now depends on Emscripten and
> PNaCl; 2 exotic LDC targets which would get my office onto D
> quicksmart!

ping Adam Ruppe?

> I've never suffered C++ so violently.

I feel your pain!

On 9/3/2015 7:30 AM, Jacob Carlborg wrote:
> On 2015-09-03 15:09, Adam D. Ruppe wrote:
>
>> what about Borland's compiler?
>
> That would be Taumetric in Walter's list [1][2].
>
> [1] https://en.wikipedia.org/wiki/Borland_C%2B%2B
> [2] https://en.wikipedia.org/wiki/Turbo_C%2B%2B

Apple had licensed Symantec C++ at one point. I sometimes wonder what influence it had on clang.

On Thursday, 3 September 2015 at 13:12:07 UTC, Adam D. Ruppe wrote:
> On Thursday, 3 September 2015 at 06:45:16 UTC, Jacob Carlborg wrote:
>> There's a lot of stuff other languages can do that JS can't. For example, classes, which a lot of developers prefer to use in favor of the weird object system in JS.

If you don't change the prototype object, then it is mostly similar, but more flexible. Functions are constructors and prototype objects are class definitions. You could also use typescript, typescript playground is quite fun. It allows you to explore the JS output in realtime.

> You can kinda do classes in JS, it just isn't pretty syntax. In the D to JS toy I did, I just did an array of function pointers to handle the virtual functions, similar to how D is compiled to machine code.
>
> It'd be fairly ugly to write by hand but when converting languages, it works well enough.

Huh? Dynamic languages have dynamic lookup, how is that different from virtual functions?

On Thursday, 3 September 2015 at 10:04:58 UTC, deadalnix wrote:
> On Thursday, 3 September 2015 at 09:56:55 UTC, Ola Fosheim Grøstad wrote:
>> On Thursday, 3 September 2015 at 06:18:54 UTC, deadalnix wrote:
>>> It is twice as slow as native. That's far from allowing generation of pure assembly.
>>
>> It is translatable to pure assembly, addressing is modulo heap size. Performance is a different issue since it does not provide SIMD yet.
>
> SIMD is not even remotely close to explaining the perf difference.

What browser? Only FF supports it. Chrome just JIT it IIRC.

On Thursday, 3 September 2015 at 06:56:16 UTC, Walter Bright wrote:
> On 9/2/2015 9:28 PM, H. S. Teoh via Digitalmars-d wrote:
>> Yes, serve existing customers well, and they will spread the word for
>> you, leading to more customers. Divert your energy to please
>> non-customers in hopes of winning them over, and you may end up driving
>> away what customers you do have.
>
> That's a good description of the approach I prefer.

Unless you sell DMD, how about providing a definition of "customer"? If you don't pay attention to evaluations, then surely the competition will steal your thunder and you'll end up as Cobol; on a long tail in maintenance mode.

On Thursday, 3 September 2015 at 21:01:10 UTC, Ola Fosheim Grostad wrote:
> Huh? Dynamic languages have dynamic lookup, how is that different from virtual functions?

The specific implementation I used was like what D compiles to: index into an array. So it is a bit clunky to do obj.vtbl[2](args) rather than obj.foo(args).

On Thursday, 3 September 2015 at 07:04:11 UTC, Walter Bright wrote:
> On 9/2/2015 9:55 PM, Ola Fosheim Grostad wrote:
>> Most C++ compilers are dead.
>
> Actually, only a tiny handful of original C++ compilers were ever created. The rest are just evolved versions of them.
>
> To list them (from memory):
>
> Cfront (Bjarne Stroustrup)
> Zortech C++ (Me)
> G++ (Michael Tiemann)
> Clang
> Edison Design Group (Daveed Vandevorde)
> Taumetric (Michael Ball)
> Microsoft
>
> There were a lot of original C compilers developed, but they pretty much all failed to make the transition to C++.

I expected the list to be longer. Which one represents the non-cfront SGI compilers? SGI was quite heavily into C++ unlike most of the Unix world.

On Thursday, 3 September 2015 at 18:14:45 UTC, Walter Bright wrote:
> I sometimes wonder what influence it had on clang.

In terms of design, not more than any other C++ compiler would have as far as I can tell. Might be interesting for you to have a closer look at it at some point though for comparison (it's non-copyleft, so no need to be afraid of lawyers there).

 — David

On 9/3/2015 2:37 PM, David Nadlinger wrote:
> On Thursday, 3 September 2015 at 18:14:45 UTC, Walter Bright wrote:
>> I sometimes wonder what influence it had on clang.
>
> In terms of design, not more than any other C++ compiler would have as far as I
> can tell. Might be interesting for you to have a closer look at it at some point
> though for comparison (it's non-copyleft, so no need to be afraid of lawyers
> there).

Yeah, I'd have to read through the source code. But it's still copyrighted, and I prefer not to be subject to taint. For years, many people did not believe I could have created a C++ compiler on my own, and they were quick to believe any possibility that I didn't. Refusing to look at other compilers helped a lot with this.

I'm still the only person to have ever created a C++ compiler from front to back. :-) Of course, DMC++ is a C++98 compiler, and C++ has moved on.

On 9/3/2015 2:28 PM, Ola Fosheim Grostad wrote:
> I expected the list to be longer.

I don't. It takes 10 years to write a C++ compiler, and most companies wanting to get into the business found it far more practical to buy one as a starting point.


> Which one represents the non-cfront SGI
> compilers? SGI was quite heavily into C++ unlike most of the Unix world.

I don't know, but many companies tended to hide where they got their starting point. I know about a few of them simply from being in the business and knowing the players.

It's like VCRs. There were only a couple makers of VCR guts, but a lot of VCR boxes with different brand names on them that repackaged the same old guts. The same goes for dishwashers, SD cards, DVD blanks, etc.

EDG licensed their front end to a lot of companies who made their own branded C++ compilers, such as Intel C++.