On Tuesday, 4 August 2015 at 20:47:00 UTC, Jonathan M Davis wrote:
> LOL. I finally got some bugs sorted out on the project that I'm working on at work (in C++), which means that I can get back to what I was working on implementing before, and about all I recall for sure is that I was working on the unit tests for it. I don't know where I was with them. I find myself wishing that I had -cov so that I could figure out what I had left to test... :(
>
> It often seems like the advantages of some of D's features are more obvious when you have to go back to another language like C++ which doesn't have them.

What do you dislike about C++ coverage tooling in comparison with D's?

On Tuesday, 4 August 2015 at 22:42:50 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 4 August 2015 at 20:47:00 UTC, Jonathan M Davis wrote:
>> LOL. I finally got some bugs sorted out on the project that I'm working on at work (in C++), which means that I can get back to what I was working on implementing before, and about all I recall for sure is that I was working on the unit tests for it. I don't know where I was with them. I find myself wishing that I had -cov so that I could figure out what I had left to test... :(
>>
>> It often seems like the advantages of some of D's features are more obvious when you have to go back to another language like C++ which doesn't have them.
>
> What do you dislike about C++ coverage tooling in comparison with D's?

To get code coverage in C++, I'd have to go track down a tool to do it. There is none which is used as part of our normal build process at work. As it is, we only have unit tests because I went and added what was needed to write them and have been writing them. No one else has been writing them, and if I want any kind of code coverage stuff set up, I'd have to go spend the time to figure it out. With D, it's all built-in, and I don't have to figure out which tools to use or write any of them myself - either for unit testing or code coverage. They're just there and ready to go.

- Jonathan M Davis

On Wednesday, 5 August 2015 at 04:10:22 UTC, Jonathan M Davis wrote:
> On Tuesday, 4 August 2015 at 22:42:50 UTC, Ola Fosheim Grøstad wrote:
>> On Tuesday, 4 August 2015 at 20:47:00 UTC, Jonathan M Davis wrote:
>>> [...]
>>
>> What do you dislike about C++ coverage tooling in comparison with D's?
>
> To get code coverage in C++, I'd have to go track down a tool to do it. There is none which is used as part of our normal build process at work. As it is, we only have unit tests because I went and added what was needed to write them and have been writing them. No one else has been writing them, and if I want any kind of code coverage stuff set up, I'd have to go spend the time to figure it out. With D, it's all built-in, and I don't have to figure out which tools to use or write any of them myself - either for unit testing or code coverage. They're just there and ready to go.
>
> - Jonathan M Davis

This is nonsense, what major C++ compiler doesn't provide code coverage?

I feel like 99% of C++ vs D arguments on this forum are comparing C++98 to D.

On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote:
> ...

One thing I didn't see mentioned at all is Rust's plugin system.

Rust plugin to embed C++ directly in Rust:
https://github.com/mystor/rust-cpp
Rust plugin to use Rust with whitespace instead of braces:
https://github.com/mystor/slag


Syntax extensions, lint plugins, etc are all possible via the plugin interface.
https://doc.rust-lang.org/book/compiler-plugins.html

Honestly, this is pretty cool :/

This thread is really long so I didn't read all the posts. Sorry if this has been mentioned.

On Wednesday, 5 August 2015 at 04:10:22 UTC, Jonathan M Davis wrote:
> To get code coverage in C++, I'd have to go track down a tool to do it. There is none which is used as part of our normal build process at work. As it is, we only have unit tests because I went and added what was needed to write them and have been writing them.

I also tend to use the features that can be directly used from the compiler switches more than external programs. I tend to look at "--help" first. Maybe one should also list programs that are distributed with the compiler in the compiler "--help" listing.

On Wednesday, 5 August 2015 at 06:03:14 UTC, rsw0x wrote:
> Syntax extensions, lint plugins, etc are all possible via the plugin interface.
> https://doc.rust-lang.org/book/compiler-plugins.html
>
> Honestly, this is pretty cool :/

Yes, it looks very cool. It lowers the threshold for experimentation and testing new ideas.

On Wednesday, 5 August 2015 at 06:03:14 UTC, rsw0x wrote:
>
> This thread is really long so I didn't read all the posts. Sorry if this has been mentioned.

Don't worry, I don't recall anybody talking about it. Nevertheless, plugins aren't unique to Rust: GCC and Clang allow plugins. Nevertheless, I think that the Rust C++ plugin you posted was cool. Reminds me of Rcpp.

On 08/03/2015 11:19 AM, Max Samukha wrote:
> On Monday, 3 August 2015 at 06:52:41 UTC, Timon Gehr wrote:
>> On 08/02/2015 09:02 PM, Max Samukha wrote:
>>> On Sunday, 26 July 2015 at 23:29:18 UTC, Walter Bright wrote:
>>>
>>>> For example, the '+' operator. Rust traits sez "gee, there's a +
>>>> operator, it's good to go. Ship it!" Meanwhile, you thought the
>>>> function was summing some data, when it actually is creating a giant
>>>> string, or whatever idiot thing someone decided to use '+' for.
>>>
>>> Number addition and string concatenation are monoid operations. In this
>>> light, '+' for both makes perfect sense.
>>
>> '+' is usually used to denote the operation of an abelian group.
>
> The point is that '+' for string concatenation is no more of an 'idiot
> thing' than '~'.

My point is that it is. String concatenation is not commutative.

On Wednesday, 5 August 2015 at 15:58:28 UTC, Timon Gehr wrote:

>> The point is that '+' for string concatenation is no more of an 'idiot
>> thing' than '~'.
>
> My point is that it is. String concatenation is not commutative.

Ok, good point. Except that '+' in a programming language is not the mathematical '+'. Why define '+' as strictly commutative operation and not more generally as an abstract binary operation, considering the middle dot is unavailable? Or, if we want to stick to the math notation, then '*' would be more appropriate than the idiot thing '~'.

On Wednesday, 5 August 2015 at 17:12:29 UTC, Max Samukha wrote:
> On Wednesday, 5 August 2015 at 15:58:28 UTC, Timon Gehr wrote:
>
>>> The point is that '+' for string concatenation is no more of an 'idiot
>>> thing' than '~'.
>>
>> My point is that it is. String concatenation is not commutative.
>
> Ok, good point. Except that '+' in a programming language is not the mathematical '+'. Why define '+' as strictly commutative operation and not more generally as an abstract binary operation, considering the middle dot is unavailable? Or, if we want to stick to the math notation, then '*' would be more appropriate than the idiot thing '~'.

Nobody want to stay in the math world. Not that math are worthless, but it has this tendency to make simple things absurdly complex by requiring you to learn a whole area of math to understand the introduction.

This is commonly referred as the monad curse: once you understand what a monad is, you loose all capacity to explain it. In fact, Most developers have used some sort of monad, but only a very small portion know they were using one or can explain you what it is.

Mathematical language is geared toward generality and correctness, not practicality. That makes sens in the context of math, that do not in the context of every day programming.