May 16

On Monday, 16 May 2022 at 10:45:51 UTC, Guillaume Piolat wrote:

>

And, C++ compilers have bugs too and when you get one there is no nice centralized Bugzilla to post it to.

I believe MS has totally revamped their compiler suite and all writings on this topic suggests that they are leading in implementing C++20.

Whatever has been true in the past may not hold in 2022. You could say the same about D, too, I am sure.

May 16

On Monday, 16 May 2022 at 08:33:08 UTC, Mike Parker wrote:

>

breakage), but I suspect many D projects and libraries died off because their creators moved on to other things before they got their projects to the state they wanted.

But why did they move on?

People have different answers, some related to the evolution of D as we can see in this thread.

May 16

On Monday, 16 May 2022 at 11:21:52 UTC, Ola Fosheim Grøstad wrote:

>

But why did they move on?

People have different answers, some related to the evolution of D as we can see in this thread.

It may be major compatibility violation.

For large compatibility problems, migration tools should be provided.

May 16

Again: I won't answer you inevitable next message; because my time seems to be more limited.

On Monday, 16 May 2022 at 11:18:36 UTC, Ola Fosheim Grøstad wrote:

>

I believe MS has totally revamped their compiler suite and all writings on this topic suggests that they are leading in implementing C++20.

I'm not sure why do you even bring Microsoft? I found more bugs in ICC than MSVC fwiw.
MSVC has worse codegen, error messages, than clang, and I don't see a reason why that would change. MSVC has not undergo a new rewrite, it's part by part.

>

Whatever has been true in the past may not hold in 2022.

I stand by my words, having done maintenance for both C++ and D projects for more than 6 years each, that D requires less work/debt to keep it up to date with compilers, especially because the front-end is the same and stdlib also the same. Moreover, the experience is like night and day, with D being far less heavy on mental load.

May 16

On Monday, 16 May 2022 at 12:10:36 UTC, Guillaume Piolat wrote:

>

How does your D code call C++ code?

May 16

On Monday, 16 May 2022 at 12:10:36 UTC, Guillaume Piolat wrote:

>

I'm not sure why do you even bring Microsoft? I found more bugs in ICC than MSVC fwiw.

People say that Microsoft didn't provide the needed resources to develop their C++ compiler for a while because they strategically wanted a move over to native C#, so their compiler lagged behind the standards. This has changed and they are now reportedly taking a lead in implementing the ISO standard.

From what I can tell the funding situation for the C++ eco system has improved over the past few years. Difficult to make an objective assessment, of course.

May 16
On Sun, May 15, 2022 at 10:21:18AM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/15/2022 4:55 AM, H. S. Teoh wrote:
> > There is, of course, the option of rewriting said C library in D.
> In my experience, it is not an option to rewrite working C code into D.
> 
> Note that I have successfully converted small and medium C code projects to D. I've done other translations of programs from one language to another.

I've converted a medium-sized C++ project into D. (Not a library, though, which would entail different mechanics because there'd be external code that uses it, so API compatibility becomes an issue.)


> 1. if you don't have a test suite for the program, a successful conversion becomes an order of magnitude harder

Very true.


> 2. converting a program all at once does not work. It must be done incrementally, one function at a time

On the contrary, with the C++ project that I converted, I found it too onerous to convert one function at a time. I started off that way, but quickly found it too painful because of tight coupling in the original code -- converting a single function sometimes actually requires converting 15 functions because they are all interdependent and/or use share the same data structures.

In theory I could've done it, I suppose. But I eventually threw in the towel, and decided to leap into D cold-turkey. Strictly speaking it was more a complete rewrite in D from ground up than converting, using the C++ code more like an external reference for comparing behaviour than actually converting the code itself.  Fortunately, I had a largish website that provided plenty of actual use cases for the program, so even though it wasn't technically a test suite it did serve as a check for whether I failed to match the old C++ behaviour, as well as a progress meter of how far the D code has progressed.

Now the entire project is in D, and I'm mighty proud of it. It's much more maintainable than the original C++ codebase, and thanks to D's modern features it's much easier to implement new features without constantly getting bogged down by the amount of babysitting that C++ demands.


> 3. even so, when faced with a large, complex project, there's just no business case for doing a conversion
> 
> Even just converting the .h files to D can be a major, rather unpleasant undertaking. We've put a lot of time into converting the various system .h files into D for druntime. There's always a risk of a mistake, and we've made them and the result is bizarre crashes because of ABI mismatches.  Hand-checking them is error-prone, tedious and very boring work.
[...]

Yes, automatic conversion is the way to go.  Even when I'm "hand-copying" C prototypes into D, I always use cut-n-paste + edit afterwards, rather than typing it out from scratch, because the latter is so much more error-prone.  My latest project, which uses libxcb heavily, has a sed script for doing 90% of the work recasting C types into D -- routine stuff like uint8_t -> ubyte, etc..  Routine work is the most dangerous in terms of likelihood of human error, because humans are bad at doing repetitive things accurately. After the first 5 times your brain just zones out and defers to muscle memory, and mistakes creep in that you're not even conscious of.


T

-- 
Береги платье снову, а здоровье смолоду.
May 16
On Sun, May 15, 2022 at 11:41:06PM +0000, forkit via Digitalmars-d wrote: [...]
> No. My argument is not that ImportC is wrong, or even useless.
> 
> My argument has to be taken *in context* of wanting programmers to write safer, more secure code, and how ImportC does not advance that aim, and *possibly* does the exact opposite.
> 
> So, by raising my concern, I hope to get people to think twice before importing C code into their D projects, with the aim of not even needing to know what that C code does.

IMO this is misguided.  Without ImportC, it takes more effort to use a C library.  Which incentivizes would-be project authors to just write more C to interface with the library, rather than put in the effort to leap through the hoops just so you can write D.  The net result is more unsafe C code is written.

With ImportC (fully implemented -- though we're not quite there yet), it's easy to call an existing C library from D, so there's less resistance to writing D code to interface with it. The net result is *less* C code is written, more D code is written.

And I'm sure you'll agree that more D code and less C code == more safety and security, than the other way round.


T

-- 
Being forced to write comments actually improves code, because it is easier to fix a crock than to explain it. -- G. Steele
May 16

On Monday, 16 May 2022 at 14:21:30 UTC, H. S. Teoh wrote:

>

IMO this is misguided. Without ImportC, it takes more effort to use a C library.

Yes, if it actually works with all the macros in a clean and intuitive way. Meaning, the resulting D code should not look much worse than the corresponding C code.

The biggest impact IMHO is that the threshold for trying out C-libraries is lowered. If you have to create your own binding your are essentially "locked in" due to the effort you spent just to get started.

The larger the C-library is and the more frequently it is updated, the more impactful this feature might be.

May 16
On 5/16/2022 1:33 AM, Mike Parker wrote:
> It's very easy to start a new project on a whim in any language, but getting it to the state you're aiming for and maintaining it long-term require discipline and commitment. Talk to people who actually maintain projects long-term to see what their take is.

Yup. The last 1% takes 99% of the time.

My old C and C++ projects all suffered from bit rot. This is due to a variety of factors, like:

1. the language changes
2. the compilers get stricter
3. implementation defined behavior changes
4. undefined behavior changes
5. portability problems
6. build system changes
7. operating system changes

Heck, just reworking it to be a git repository takes time and effort.