On 08/21/2015 01:43 AM, Walter Bright wrote:
>
> I'm still amazed by how even modern C++ code bases embed the trickiest,
> most bizarre uses of the preprocessor and then build their entire code
> structure around it.

I probably haven't seen all the stuff you have, but I find that's the only way to tolerate working in C++: Macro the crap out of it :)

On 8/21/2015 7:24 AM, Nick Sabalausky wrote:
> I probably haven't seen all the stuff you have,

I'd be ashamed of such code if I'd written it, and if I was a C++ program manager I wouldn't allow such in the code base.

I don't understand why the C++ committee, in its quest to improve the language, has not pushed forward with proper replacements for typical preprocessor uses, with the intent of eventually deprecating it entirely.


> but I find that's the only way
> to tolerate working in C++: Macro the crap out of it :)

I try to practice what I preach, and the C++ code base for dmd has been gradually getting rid of its use of the preprocessor (even though it's pretty tame use as these things go).

On 8/21/2015 2:26 AM, Kagamin wrote:
> On Thursday, 20 August 2015 at 22:22:26 UTC, Walter Bright wrote:
>> I posted in another thread a while back a list of D features that C++ is
>> rushing to incorporate.
>
> Just found the proposal for transitive const:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4388.html

Note this gem:

"Renamed class from logical_const to propagate_const as the former is used with different meaning in the D community."

This oblique reference indicates that this idea is taken from D, and again confirms that D is the future of C++.

On 2015-08-21 23:55, Walter Bright wrote:
> I don't understand why the C++ committee, in its quest to improve the
> language, has not pushed forward with proper replacements for typical
> preprocessor uses, with the intent of eventually deprecating it entirely.

With modules being already implemented in Clang, is there a legitimate use case for the preprocessor left?

-- 
/Jacob Carlborg

On 24-Aug-2015 09:17, Jacob Carlborg wrote:
> On 2015-08-21 23:55, Walter Bright wrote:
>> I don't understand why the C++ committee, in its quest to improve the
>> language, has not pushed forward with proper replacements for typical
>> preprocessor uses, with the intent of eventually deprecating it entirely.
>
> With modules being already implemented in Clang, is there a legitimate
> use case for the preprocessor left?
>

Code generation and crude meta-programming.

-- 
Dmitry Olshansky

On Monday, 24 August 2015 at 06:17:06 UTC, Jacob Carlborg wrote:
> On 2015-08-21 23:55, Walter Bright wrote:
>> I don't understand why the C++ committee, in its quest to improve the
>> language, has not pushed forward with proper replacements for typical
>> preprocessor uses, with the intent of eventually deprecating it entirely.
>
> With modules being already implemented in Clang, is there a legitimate use case for the preprocessor left?

implement this in D
https://github.com/solodon4/Mach7

On Monday, 24 August 2015 at 06:17:06 UTC, Jacob Carlborg wrote:
> On 2015-08-21 23:55, Walter Bright wrote:
>> I don't understand why the C++ committee, in its quest to improve the
>> language, has not pushed forward with proper replacements for typical
>> preprocessor uses, with the intent of eventually deprecating it entirely.
>
> With modules being already implemented in Clang, is there a legitimate use case for the preprocessor left?

I use it all the time for handling log messages and throwing exceptions. Without that, you can't get stuff like the current file and line number, because C++ isn't smart enough to use the call point for __FILE__ and __LINE__. So, you either use macros so that the code _is_ at the call point, or you have to do it manually, and no one is going to do that sort of thing manually. I'm sure that there are other use cases, but those are the ones that I use all the time.

Also, in my experience, getting static or global variables to work with dlls when you need them is hell, so it pretty much inevitably comes down to either using a macro or making it a function with a static variable inside it which it returns. I usually go with the useless function, but the macro sure seems tempting sometimes.

To really replace macros - especially in a language that's already using them - you pretty much have to replace every use case for them, and I really don't see that happening to C++. Also, getting rid of macros would break C compatibility, which they won't do. Even if they add better alternatives to the language and recommend that you use those instead, they'll still support macros because of C.

- Jonathan M Davis

On 8/23/2015 11:40 PM, Jonathan M Davis wrote:
> To really replace macros - especially in a language that's already using them -
> you pretty much have to replace every use case for them, and I really don't see
> that happening to C++. Also, getting rid of macros would break C compatibility,
> which they won't do. Even if they add better alternatives to the language and
> recommend that you use those instead, they'll still support macros because of C.

C++ continues to support old, bad practices while relentlessly advocating other techniques as best practices. So far, I have not seen that w.r.t. the preprocessor.

On 2015-08-24 08:35, rsw0x wrote:

> implement this in D
> https://github.com/solodon4/Mach7

It's just a matter of syntax.

-- 
/Jacob Carlborg

On Thursday, 20 August 2015 at 22:07:10 UTC, John Carter wrote:
> https://twitter.com/yukihiro_matz/status/634386185507311616
>
> Pity that concepts looks to be a very painful syntax for expressing what D does so clearly.

One big difference is that C++1z concepts are supposed to allow looking for external functions, not only methods. That would require some kind of principled hijacking of templates in Dlang (or else the constraint template would keep looking for the functions, called by ufcs, either inside the type of in the templates declaration position). I haven't managed to work that out yet except by using mixins :/