> I'd say C has embraced macros for good reasons, as a minimalistic language design strategy  (newest C version using it for generics), but C++ has no longer an excuse for providing it.

Excuses for C++ :

1. Backwards compatibility with existing C++ code
2. Being able to call C code that depends on macro definitons to actually work
3. The aforementioned cases in which templates can't do the job

With regards to #3: see when you use `mixin` in D code? You need a macro to achieve the equivalent task in C++. It's either that or boilerplate. Yay when I get to write D, boo when I just have to use C++. I feel dirty every time I type `#define`, but I'd feel dirtier if I repeated code all over the place. As always, it's a trade-off.

Atila

On Monday, 1 June 2015 at 17:17:18 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 1 June 2015 at 16:57:00 UTC, Jonathan M Davis wrote:
>> I use macros for stuff like exceptions all the time - e.g.
>>
>> THROW(MyException, ("This value is wrong: %d", foo));
>
> ick! Yes,  if you want stack-trace like information in release-builds you need to use the macro system, but that's because __FILE__ and __LINE__ are macros! That's a C deficiency.
>  Usually your debugger gets you what you are looking for without this in debug builds, right?

Goodness no. The exception needs to have that information in it, and I want exceptions logged so that I can track what happened without running in a debugger - and in release mode as well as debug mode. And it's not like I can necessarily reproduce the problem by rerunning the program anyway, so relying on the debugger for this sort of thing just doesn't fly in general, much as it might in simple cases.

> (I don't use exceptions in C++)

My condolences.

> It's a problem if you need it. It is almost always used to address language design flaws or other structural flaws.

Even if that's true, you're still stuck unless they fix the language. If/until C++ provides alternate solutions to the kinds of things that require macros right now, you need macros. I can always wish that C++ were better, but if I'm programming in C++, I have to deal with what it provides. The only way around that is to use another language (like D), and it that were an option, I probably wouldn't be using C++ in the first place.

It sounds to me like you're too against macros for your own good. Sure, they suck, but that's just life with C++ unless you want to make life harder for yourself. Simply wishing that the situation were better doesn't make it so.

- Jonathan M Davis

On Monday, 1 June 2015 at 18:44:02 UTC, Atila Neves wrote:
> 1. Backwards compatibility with existing C++ code
> 2. Being able to call C code that depends on macro definitons to actually work
> 3. The aforementioned cases in which templates can't do the job
>
> With regards to #3: see when you use `mixin` in D code? You need a macro to achieve the equivalent task in C++. It's either that or boilerplate. Yay when I get to write D, boo when I just have to use C++. I feel dirty every time I type `#define`, but I'd feel dirtier if I repeated code all over the place. As always, it's a trade-off.

Yes, it is a trade-off. 20 years ago I tried to write terser code and do code gen with macros if possible, now I don't mind some repeated code as it is often easier to understand later on than indirections and I often find that building tables etc with an external tool is cleaner than macros anyway.

Some boiler plate, like SFINAE templates for testing type properties ("does the class have a .length() function") look really ugly in C++ compared to newer languages, but I keep those tucked away in a header file, so it is not so bad. The good thing about this is that I don't get tempted to add SFINAE constructs I don't understand, which is an advantage when debugging...

I agree macros are needed for reasonable C interop, but _unfortunately_ the presence of macros is like a sleeping pillow for the C++ language-designers that allows them to add new pieces without getting down to a clean core language.

As for mixins, I don't like those either. You can often get around that with analysis that leads to a well thought out design, but I agree that  sometimes it is too late for that and boilerplate or macros ensue as a result of evolution… The question then is, would a lack of textual-substitution-first-aid have made the architect/programmers spend more time on design before coding?

So yes, providing and using macros is a trade-off, but I usually of the wrong kind. (E.g. a convenient excuse for not cleaning up the language or the application design)

On Monday, 1 June 2015 at 18:54:18 UTC, Jonathan M Davis wrote:
> It sounds to me like you're too against macros for your own good. Sure, they suck, but that's just life with C++ unless you want to make life harder for yourself. Simply wishing that the

But it doesn't make my C++ life harder, it makes my C++ life better. I don't need them, where I would use macros in C, I can usually make do with a constexpr or a template and get type safety and more readable code.

But I hope you see my point that __FILE__ and __LINE__ would be better done with introspection, also in D? Such "magic cookies" are signs of a lack of orthogonality.

(And it can be done as hidden registers/parameters in the language implementation so that you can have separate compilation and compile time evaluation of introspection where possible.)

On Tuesday, 2 June 2015 at 05:58:43 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 1 June 2015 at 18:54:18 UTC, Jonathan M Davis wrote:
>> It sounds to me like you're too against macros for your own good. Sure, they suck, but that's just life with C++ unless you want to make life harder for yourself. Simply wishing that the
>
> But it doesn't make my C++ life harder, it makes my C++ life better. I don't need them, where I would use macros in C, I can usually make do with a constexpr or a template and get type safety and more readable code.
>
> But I hope you see my point that __FILE__ and __LINE__ would be better done with introspection, also in D? Such "magic cookies" are signs of a lack of orthogonality.
>
> (And it can be done as hidden registers/parameters in the language implementation so that you can have separate compilation and compile time evaluation of introspection where possible.)

D's semantics for __FILE__ and __LINE__ are so much better than C++'s. I sorely miss D's semantics for them whenever I'm in C++. Having them get the values from the call site rather than the declaration site is so much more useful that it's not even funny.

- Jonathan M Davis

On Tuesday, 2 June 2015 at 06:32:43 UTC, Jonathan M Davis wrote:
> D's semantics for __FILE__ and __LINE__ are so much better than C++'s. I sorely miss D's semantics for them whenever I'm in C++. Having them get the values from the call site rather than the declaration site is so much more useful that it's not even funny.

But you are referring to evaluation of default parameters. Evaluating default parameters at the call site can be problematic, so I don't think this is obvious at all.

All functions have a conceptual object which is the "activation record", often represented by the stack frame (but in some languages a heap object). It would be reasonable to be able to query this "activation record" object, just like you have "this" that refers to the object of a method you could have a "thisfunction.caller.lineno" etc.

On Tuesday, 2 June 2015 at 06:42:13 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 2 June 2015 at 06:32:43 UTC, Jonathan M Davis wrote:
>> D's semantics for __FILE__ and __LINE__ are so much better than C++'s. I sorely miss D's semantics for them whenever I'm in C++. Having them get the values from the call site rather than the declaration site is so much more useful that it's not even funny.
>
> But you are referring to evaluation of default parameters. Evaluating default parameters at the call site can be problematic, so I don't think this is obvious at all.
>
> All functions have a conceptual object which is the "activation record", often represented by the stack frame (but in some languages a heap object). It would be reasonable to be able to query this "activation record" object, just like you have "this" that refers to the object of a method you could have a "thisfunction.caller.lineno" etc.

That would be even greater if they would be chained ! What a debug tool we could get out of this ! I know ! We should call them "stack traces" ! Catchy !

On Mon, 01 Jun 2015 11:10:09 +0000, Ola Fosheim Grøstad wrote:

> But I think web browsers are slowly moving towards a situation where you soon can make sensible games in webgl + asm.js using home-made engines using "native javascript" (basically javascript targetting LLVM IR) or pnacl (LLVM IR).  So the distinction between native and non-native is getting blurred.

this whole thing is complete disaster. instead of designing a simple virtual machine with well-defined commands, they keep uglifying already ugly js. this is so bad that i believe that we will live with that for many years (really, i see that the worst technology with as many ugliness one can stuff into it usually wins; that "web shit" is ugly enough).

On Tuesday, 2 June 2015 at 09:18:27 UTC, ketmar wrote:
> On Mon, 01 Jun 2015 11:10:09 +0000, Ola Fosheim Grøstad wrote:
>
>> But I think web browsers are slowly moving towards a situation where you
>> soon can make sensible games in webgl + asm.js using home-made engines
>> using "native javascript" (basically javascript targetting LLVM IR) or
>> pnacl (LLVM IR).  So the distinction between native and non-native is
>> getting blurred.
>
> this whole thing is complete disaster. instead of designing a simple
> virtual machine with well-defined commands, they keep uglifying already
> ugly js. this is so bad that i believe that we will live with that for
> many years (really, i see that the worst technology with as many ugliness
> one can stuff into it usually wins; that "web shit" is ugly enough).

Thankfully mobile OSes and desktop app stores seem to be on the right track to kill this.

http://www.quirksmode.org/blog/archives/2015/05/web_vs_native_l.html

On Tue, 02 Jun 2015 09:44:24 +0000, Paulo  Pinto wrote:

> Thankfully mobile OSes and desktop app stores seem to be on the right track to kill this.

yet they pushing cromeos and firefoxos...