On Monday, 5 February 2018 at 16:03:44 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 5 February 2018 at 12:23:58 UTC, psychoticRabbit wrote:
>> No. C++ is primarliy about higher order abstractions. That's why it came about.
>> Without the need for those higher order abstractions, C is just fine - no need for C++
>
> Actually, many programmers switched to C++ in the 90s just to get function overloads and inlining without macros.
>

Not me. I refused (during the 90's) to use C++ for anything ;-)
(my housemate loved C++ though - to this day, I still don't know why..)

> If you think C is just fine then I'm not sure why you are interested in D.

Cause D is interesting (too)... do I have to choose only one language??

I have my own IDE - which I wrote, and i can switch between (currently) 7 different languages - with just a single click of my mouse button. I'll keep adding more languages that interest me.


>> The benefits of C, come from C - and only C (and some good compiler writers)
>
> Not sure what you mean by that.

I mean C++ was implemented upon the foundation of C - as such, C++ was able to take advantage of what that foundation offered.


> There is little overhead by using C++ over C if you set your project up for that. The only benefits with C these days is portability.
>
>> (depends on what 'many' means)  - There certinaly are 'numerous' (what ever that means) projects trying to create a better c - which contradicts your assertion.
>
> Which ones are you thinking of?

I looked at several recently  - I can't recall them all .. but for starters..

(C2 -- interestingly this seems a lot like D)
http://c2lang.org/site/

(CheckedC - a Microsoft Research Project to 'extend' C)
https://www.microsoft.com/en-us/research/project/checked-c/

On Monday, 5 February 2018 at 23:42:18 UTC, welkam wrote:
> There is PGO (Profile Guided Optimization) that can do that without additional language extensions. You need to find better example to support your claims.

It is sometimes impossible. Some parts of the Linux kernel cannot be profiled at all, for example. My claim is simple: you switch from gcc -> you lose this thing. I don't even care if it has actually mattered. I had a choice then, and now I don't. I have different choices now.

On Tuesday, 6 February 2018 at 02:31:42 UTC, psychoticRabbit wrote:
> Plenty of others seems to have a different opinion ;-)

That's just my opinion. My generation has plenty of C++ programmers, but I have no acquaintance who does userspace C. I would never do that too, unless forced to work with existing code base. I don't know why would freshman\young dude do that today.

On Monday, 5 February 2018 at 20:12:09 UTC, Walter Bright wrote:
> On 2/5/2018 12:06 AM, Boris-Barboris wrote:
>> I think that would be most logical thing to have, but that would also imply preprocessor, or at least it's restricted subset, wich you most probably though about as well.
>
> Sure. I could use the Boost licensed preprocessor in DMC, or the Boost licensed preprocessor in Warp.

I tried Warp on a non-trivial C codebase. It didn't work (by which I mean the code wouldn't compile with it). I don't know how clang managed to build a (for all practical purposes I can see) bug-compatible preprocessor from scratch to gcc, but it did and in large projects it makes a difference.

Atila

On Monday, 5 February 2018 at 22:56:47 UTC, Jonathan M Davis wrote:
> On Monday, February 05, 2018 18:54:32 John Gabriele via Digitalmars-d wrote:
>> What is the specific purpose of -betterC? I see from <https://dlang.org/spec/betterc.html> that it's (A) useful when targeting constrained environments, and (B) for easier embedding of D libraries into larger projects. But I think I've read elsewhere in this forum that it was specifically useful for the DMD implementation itself.
>>
>> Is betterC intended to be used for standalone "D -betterC" programs where C might've otherwise been used? My impression of D so far is that it can indeed already be used as a better C by avoiding the GC yourself, or invoking it yourself when appropriate.
>>
>> It may be useful if that betterc.html page gave a rationale for it; to avoid any confusion on what its intended purpose is.
>
> Based on Walter's comments, I get the impression that he thinks that the primary benefit of -betterC is to make it easier to port a C program to D, because then you can port it piece by piece rather than having to do it all at once. After that, it's D, and you can ditch -betterC and start taking advantage of the full feature set of D. Certainly, that's all that I would ever consider using -betterC for. I have zero interest in giving up on the features that require druntime. If I were going to consider that, I'd just ditch D for C++. At least then, I'd get a fully featured language even if it isn't as nice as D.

Thanks, Jonathan! Sounds like a great tool to have available to assist migrating to D.

> However, there are some folks who like the idea of using -betterC as their primary or only way to use D, because they don't want the runtime for whatever reason. Some of that comes from the fact that it's easier to link against a D library from a C/C++ program when the D library doesn't require the runtime, but I don't think that that's the only reason.

Ah, I see. Around this notion then is where I'm seeing some folks here concerned about D "choosing a direction". If your impression (your first paragraph) is correct, then D has actually not changed direction (wrt betterC) in the first place.

Incidentally, this is one of those situations that reminds me how important names are, for example:

  * "D" = "the new and improved next incarnation of C/C++"
  * "-betterC" = "use this as a better (and in place of) C"

Naming is hard!

On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
> I am sure there will be lots of opinions regarding this post but its suffice to say that my decision to go with Go ( no pun intended ) is finally. I hope this final post is some indication of the issues that have plagued my decision process.

Thanks for the detailed post.  I'm an old C/C++ guy (got started with C++ back in the cfront days), and have been kicking the tires on D recently.  The poor state of libraries is something that may push me away from D as well.  In my case, need opencl and crypto libs.  The opencl package in dub is a crude wrapper around the original C API.  I couldn't find any sha lib, so I've started porting a reference sha3 implementation from C.

I, like you, may end up jumping off the ship though.  I've done a bit of work with golang before, so maybe I'll take another look at it.  The opencl bindings aren't much better, but there are ready-made sha3 libs I can use instead of porting from C.

On Tuesday, 6 February 2018 at 20:25:22 UTC, Ralph Doncaster wrote:
> The opencl package in dub is a crude wrapper around the original C API.  I couldn't find any sha lib, so I've started porting a reference sha3 implementation from C.

Don't port libraries like that, just call them directly. Porting crypto stuff is just asking for bugs and there's fairly little benefit over just calling them.

On Tue, Feb 06, 2018 at 08:55:31PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
> On Tuesday, 6 February 2018 at 20:25:22 UTC, Ralph Doncaster wrote:
> > The opencl package in dub is a crude wrapper around the original C API.  I couldn't find any sha lib, so I've started porting a reference sha3 implementation from C.
> 
> Don't port libraries like that, just call them directly. Porting crypto stuff is just asking for bugs and there's fairly little benefit over just calling them.

Yeah, porting crypto code is usually a bad idea unless you're a crypto expert.  Careless porting of crypto code is often vulnerable especially to side-channel attacks due to unexpected interactions with the target language and/or subtle semantic differences.

D was designed especially to interface with C as painlessly as possible, so if your chosen crypto library has a C API, the best approach is just to call it directly.  Wrapping an idiomatic D interface around it is nice, but I'd still leave the actual implementation to the C library.


T

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.

On Tuesday, 6 February 2018 at 20:55:31 UTC, Adam D. Ruppe wrote:
> On Tuesday, 6 February 2018 at 20:25:22 UTC, Ralph Doncaster wrote:
>> The opencl package in dub is a crude wrapper around the original C API.  I couldn't find any sha lib, so I've started porting a reference sha3 implementation from C.
>
> Don't port libraries like that, just call them directly. Porting crypto stuff is just asking for bugs and there's fairly little benefit over just calling them.

Is there an automatic way to make D wrappers for all the C function calls?

There's also the problem that the test code for the C/C++ libraries would have to be wrapped up into the library or ported to D.

Although I'm new to D, I do know crypto quite well, and especially sha3/keccak.  One reason I considered porting was to see if dmd outputs better code than gcc.  On x86_64 with the xmm registers there is enough room for 1600 bits of the keccak state to be stored in registers, but gcc 5.4 will still use RAM for the state.  It stays in L1, but storing all the state in registers should be much faster as it would avoid a lot of mov instructions loading parts of the state into registers.

On Tuesday, February 06, 2018 21:44:16 Ralph Doncaster via Digitalmars-d wrote:
> One reason I considered porting was to
> see if dmd outputs better code than gcc.

It almost certainly won't. dmd compiles code lightning fast and has a decent optimizer, but it's really not on par with gcc or llvm's optimizers at this point. For quite some time now, Walter's focus has been on D's frontend, not on the dmd backend (which is dmc), and he's the main person who would improve the backend, whereas gcc and llvm have a number of folks working on improving their optimizers. If you want comparable optimization, then you'd need to use gdc or ldc - though until gdc has another release, it's using a rather old version of the frontend, so ldc would be better; the gdc folks were seriously delayed in updating after the frontend switched to D.

When using gdc or ldc, you can get binaries that compare quite favorably with C/C++ - even beat them in some case - but in general, if you compare C/C++ code compiled with gcc or clang, it will probably beat dmd compiled code - not necessarily by leaps and bounds but consistently enough that if you want your code to be as fast as possible, then you use gdc or ldc for your production builds.

- Jonathan M Davis