On Thu, 02 Jul 2015 11:39:11 +0000, Ola Fosheim Grøstad wrote:

> On Thursday, 2 July 2015 at 10:29:39 UTC, ketmar wrote:
>> ahem. i don't even know how i managed to do that all the time with "static inline" in .h files... i'm a black magicman!
> 
> Doesn't matter what you are, but what language core libraries are written in.

"You can't really write libraries in C if you need inlining to get good performance."

ahem. i can. with C. what am i doing wrong?

On Thu, 02 Jul 2015 11:09:23 +0000, Jonathan M Davis wrote:

> Well, you're entitled to your opinion, and you're definitely free to
> avoid C++ libraries if that what you want, but there are plenty of D
> users who want good C++ interop (and for some projects, pretty much
> require it - especially the corporate folks), so there's actually a
> fairly high demand for it. And part of why the C++ interop that we have
> is as good as it is now is because it was needed to port the compiler's
> frontend to D and have it still work with the backends of the three main
> compilers.
> So, it's there because it serves a very practical purpose.

and still not working reliably, partly due to absence of standardized mangling schemes and ABI in C++. this is a neverending chase.


> So, use it or don't, but don't expect everyone to agree with you that interoperability with C++ is useless.

but i can try! ;-)

On Thursday, 2 July 2015 at 11:55:48 UTC, ketmar wrote:
> ahem. i can. with C. what am i doing wrong?

Well, you can't because you don't have templates. The most recent C version have a hacked up version of generics, but who knows if/when Microsoft  will implement it.

People write core libraries in C++. Why they do it is not the main point, but they actually have good reasons to choose C++ over C no matter what C-wizzkids with C++-allergies claim… ;^]

On Thu, 02 Jul 2015 12:35:18 +0000, Ola Fosheim Grøstad wrote:

> On Thursday, 2 July 2015 at 11:55:48 UTC, ketmar wrote:
>> ahem. i can. with C. what am i doing wrong?
> 
> Well, you can't because you don't have templates.

that's why my hashtables supports alot of types, including ints, strings, structs and inlined? hm...


> People write core libraries in C++. Why they do it is not the main point, but they actually have good reasons to choose C++ over C no matter what C-wizzkids with C++-allergies claim… ;^]

yes. the main reason is "let's prevent using our library in any sane language!"

On Thursday, 2 July 2015 at 14:42:10 UTC, ketmar wrote:
> that's why my hashtables supports alot of types, including ints, strings, structs and inlined? hm...

Hashing isn't type-dependent. You can't really do it well in C with things like extensible physics and sound synthesis.

>> People write core libraries in C++. Why they do it is not the main point, but they actually have good reasons to choose C++ over C no matter what C-wizzkids with C++-allergies claim… ;^]
>
> yes. the main reason is "let's prevent using our library in any sane language!"

Nah, it's more like "let's solve this in a language where this can be done in a convenient manner and will be used by many people".

As for D... I'm not really sure if D can get good C++ interop without changing language semantics. A 75% solution isn't really good enough to cover libraries that rely heavily on template composition.

On Fri, 03 Jul 2015 06:11:49 +0000, Ola Fosheim Grøstad wrote:

> Nah, it's more like "let's solve this in a language where this can be done in a convenient manner and will be used by many people".

wait, are you talking about C here? 'cause it's about C.

On 06/28/15 16:21, Joakim via Digitalmars-d wrote:
> On Sunday, 28 June 2015 at 13:43:39 UTC, Artur Skawina wrote:
>> On 06/28/15 05:06, Joakim via Digitalmars-d wrote:
>>> So you're trying to avoid writing this?
>>>
>>> version(linux) version(D_LP32)
>>>     version = valistIsCharPointer;
>>> else version(Windows)
>>>     version = valistIsCharPointer;
>>>
>>> While your version is more concise, I actually think the current form is more clear.
>>
>> And wrong. Spot the bug.
> 
> Eh, that idiom is not commonly used so I wasn't exactly clear on the syntax, but you're presumably referring to the need for braces?

I didn't even look as far as the 'else', but that is another good
reason to avoid 'version'.
What I was referring to was the use of subtly different identifiers
- the original used 'Linux', but your version has 'linux'. Such
changes are hard to see even in a four-liner; they are almost
impossible to catch in a larger change. Which will likely pass code
review, where the focus in on logic, not spelling. The compiler is
supposed to catch the latter kind of errors, but it has no chance to
do this because of D's 'version' semantics. So performance- and even
security-relevant issues can remain unnoticed, until someone has to
figure out why something that can't happen does happen, or why a
platform feature isn't being used. The situation is bad enough when
dealing with predefined identifiers, but gets worse with local user-
defined ones. You might get 'Linux' vs 'linux' right, but is it
'freebsd', 'freeBSD', 'FreeBSD' or 'Free_BSD'? Unless you happen to
use that OS, you /will/ get it wrong.
When reviewing code, will you always spot 'version(ALPHA)',
'version(Sparc)', 'version(x86_64)' and 'version(MIPS_64)'?
You're even less likely to notice:

   version(vaListIsCharPointer)
     ...

>> That's the real reason why 'version' needs to be banned from the codebase. You should *never* use D's 'version'.

D has another feature that provides the same functionality and
is not affected by the problem, so just use that -- 'static if'.
And have just one exception; a 'config' module which is allowed
to access predefined version identifiers (but does not define
any local ones, just normal enum constants). Not perfect, but at
least this issue will not bite you anywhere else. If someone writes

   static if (config.Linux) ...

or

   static if (config.vaListIsCharPointer) ...

then the compiler will always catch the bug. The other D-version problems mentioned in this thread will then disappear too.

artur

On Saturday, 4 July 2015 at 15:04:32 UTC, Artur Skawina wrote:
> What I was referring to was the use of subtly different identifiers
> - the original used 'Linux', but your version has 'linux'. Such
> changes are hard to see even in a four-liner; they are almost
> impossible to catch in a larger change. Which will likely pass code
> review, where the focus in on logic, not spelling. The compiler is
> supposed to catch the latter kind of errors, but it has no chance to
> do this because of D's 'version' semantics. So performance- and even
> security-relevant issues can remain unnoticed, until someone has to
> figure out why something that can't happen does happen, or why a
> platform feature isn't being used.

Well, technically, _he_ was wrong, as D defines 'linux' and not 'Linux', and I was just correcting Daniel.  Note also that I changed it to D_LP32, even though neither one is predefined, because that at least follows the naming convention of D_LP64, which does exist.

> The situation is bad enough when
> dealing with predefined identifiers, but gets worse with local user-
> defined ones. You might get 'Linux' vs 'linux' right, but is it
> 'freebsd', 'freeBSD', 'FreeBSD' or 'Free_BSD'? Unless you happen to
> use that OS, you /will/ get it wrong.
> When reviewing code, will you always spot 'version(ALPHA)',
> 'version(Sparc)', 'version(x86_64)' and 'version(MIPS_64)'?
> You're even less likely to notice:
>
>    version(vaListIsCharPointer)
>      ...

A fair criticism, but one that also applies to the C++ #ifdefs I quoted previously.

>>> That's the real reason why 'version' needs to be banned from the codebase. You should *never* use D's 'version'.
>
> D has another feature that provides the same functionality and
> is not affected by the problem, so just use that -- 'static if'.
> And have just one exception; a 'config' module which is allowed
> to access predefined version identifiers (but does not define
> any local ones, just normal enum constants). Not perfect, but at
> least this issue will not bite you anywhere else. If someone writes
>
>    static if (config.Linux) ...
>
> or
>
>    static if (config.vaListIsCharPointer) ...
>
> then the compiler will always catch the bug. The other D-version problems mentioned in this thread will then disappear too.

Only drawback is that you have to import that config module everywhere for those constants to be defined.  I agree that mistyping and checking a large array of version constants can cause problems, don't think it's enough to throw "version" out though.

On 7/4/2015 2:24 PM, Joakim wrote:
> I agree that mistyping and checking a large array of
> version constants can cause problems

It's one reason why this style is recommended:

    version (linux)
    {
	...
    }
    else version (Windows)
    {
	...
    }
    else
	static assert(0);

On Saturday, 4 July 2015 at 22:43:40 UTC, Walter Bright wrote:
> On 7/4/2015 2:24 PM, Joakim wrote:
>> I agree that mistyping and checking a large array of
>> version constants can cause problems
>
> It's one reason why this style is recommended:
>
>     version (linux)
>     {
> 	...
>     }
>     else version (Windows)
>     {
> 	...
>     }
>     else
> 	static assert(0);

Yeah, and while version identifiers can certainly be error-prone, it's not like allowing arbitrary conditions or even &&ing and ||ing version identifiers would make them _less_ error-prone. We're dealing with the type of thing that seems to just be fundamentally error-prone such that the best that we can do is disallow some of the worst cases and adopt practices which mitigate the risk. We _do_ need version statements (or an equivalent) though, otherwise it would be be pretty hard to write cross-platform code.

- Jonathan M Davis