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

-- 
Береги платье снову, а здоровье смолоду.

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

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.