On Wed, 01 Jul 2015 13:43:26 +0000, Jonathan M Davis wrote:

> On Wednesday, 1 July 2015 at 11:18:17 UTC, ketmar wrote:
>> On Wed, 01 Jul 2015 10:16:13 +0000, Ola Fosheim Grøstad wrote:
>>
>>> Quite a few niche-libraries are C++ only.
>>
>> throw 'em away, they full of bugs and broken code anyway.
> 
> Qt? AFAIK, it's C++-only, and it's widely considered to be one of the best GUI toolkits out there.

for C++. all so-called "bindings" are ugly as hell. mostly 'cause Qt is not a "GUI toolkit", but a programming platform, tied to C++. using it as library outside of C++ world is a huge mistake.


> but the fact that someone chooses to use
> C++ instead of C for their library doesn't make it junk

it does. there is no single reason to write a *library* in C++, if it's intended to be used outside of C++ world.


> and plenty of folks care primarily about C++, in which case, it's a non-issue.

so let 'em be in their wonderful C++ world. no need to drag that abomination to other worlds.

On Wed, 01 Jul 2015 02:53:53 -0400, ketmar <ketmar@ketmar.no-ip.org> wrote:

> On Mon, 29 Jun 2015 11:30:52 -0400, bitwise wrote:
>
>> IMO,
>> the D community's time would be better spent improving D/C++ interop
>> than trying to make D a systems language.
>
> but that interop is excellent now! for, see, if some library has no C API,
> only C++ API, authors of that library are heavily brain-damaged, and the
> troubles library brings will be much greater than any benefits one can
> get. and if it has C API, most of it can be translated with sed and
> manually fixed (i'm doing that any time i need a new binding).

It is pretty good, but it's the little things, like these:

1) no clear specification/wiki with info on which compilers are supposed to work together
-dmd and xcode default compiler work, but I found this out through trial and error

2) need to qualify your extern(C++) interface overrides with "extern(C++)"
-this shouldn't be necessary

3) extern(C++) interfaces/classes can't have virtual destructors
-even if you can't call it, as the docs specify, you should be able to put "~this();" or something into an extern(C++) interface as a placeholder so that your C++ class can have a virtual destructor.

4) C++ namespaces shouldn't conflict with module namespace scope
-this should work:
module N;
extern(C++, N) {
    interface X{}
    void foo();
}

If the above cannot work, we should be able to do something like this:

module N;
extern(C++, alias M N) or extern(C++, M = N)
{ void foo(); }
M.foo();
N.foo(); // error, foo is in "M" scope in D-land


  Bit

On Wednesday, 1 July 2015 at 14:30:26 UTC, ketmar wrote:
> using it as library outside of C++ world is a huge mistake.

I can't agree with this. PyQt is the most usable UI toolkit for Python in my experience.

 - David

On Wednesday, 1 July 2015 at 14:30:26 UTC, ketmar wrote:
> so let 'em be in their wonderful C++ world. no need to drag that abomination to other worlds.

You can't really write libraries in C if you need inlining to get good performance. Such libraries are usually written in C++.

To get those ported and maintained you need a significant user-mass. Maybe Rust can do it if they can sustain growth, but it will take several years to get there. So good C++ interop is the cheap option.

On 6/30/2015 8:55 AM, bitwise wrote:
> Waiiit a minute...reading this again, it seems you are talking about writing
> code for a single system.
>
> In that case, yea, I suppose you can get by without versions. The market in
> multi-platform mobile apps is not something that should be ignored though.

D has multi-platform support in the D runtime library and it works. So do other languages, that don't even have version declarations.

On Thu, 02 Jul 2015 02:08:58 -0400, bitwise wrote:

> It is pretty good, but it's the little things, like these:

the whole thing i'm talking about is "no C++ interop is necessary, eVaR!" ;-)

On Thu, 02 Jul 2015 08:15:38 +0000, Ola Fosheim Grøstad wrote:

> On Wednesday, 1 July 2015 at 14:30:26 UTC, ketmar wrote:
>> so let 'em be in their wonderful C++ world. no need to drag that abomination to other worlds.
> 
> You can't really write libraries in C if you need inlining to get good performance. Such libraries are usually written in C++.

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!

On Thu, 02 Jul 2015 06:12:26 +0000, David Nadlinger wrote:

> On Wednesday, 1 July 2015 at 14:30:26 UTC, ketmar wrote:
>> using it as library outside of C++ world is a huge mistake.
> 
> I can't agree with this. PyQt is the most usable UI toolkit for Python in my experience.

except that python is a one big huge mistake... ;-)

On Thursday, 2 July 2015 at 10:28:16 UTC, ketmar wrote:
> On Thu, 02 Jul 2015 02:08:58 -0400, bitwise wrote:
>
>> It is pretty good, but it's the little things, like these:
>
> the whole thing i'm talking about is "no C++ interop is necessary, eVaR!" ;-)

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.

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

- Jonathan M Davis

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.