www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] C vs C++

reply Dukc <ajieskola gmail.com> writes:
C++ is meant as an advancement of C. And it's used as one. Dmd 
was written in C++ until version 2.069, and countless other 
programs, both open and closed source still use it. It makes 
sense - it's a superset of C (well, almost), so one can always 
fall back to C features when the more complex features of C++ 
don't justify themselves.

Yet, many of the most well-known and successful programmers 
[don't see it like 
that](https://harmful.cat-v.org/software/c++/coders-at-work). Can 
it be that C++ is so complex that even conservative use of it 
makes your codebase so unreadable that even the archaic C is a 
better choice? Think how crazy this is - the cream of of our 
profession resort to pointer / length pairs over `std::vector`, 
and copy-pasting the module name to every public declaration over 
using namespaces.

There has to be HUGE downsides in C++ for this competent people 
to resort to this drastic avoidance. They do say what the 
downsides of C++ are about: too big a language to learn well, so 
code ends up using features the reader does not know. Still, if 
this is the case one would think it had been long since generally 
aknowledged: C++ guidebooks would tell to avoid less-known 
language features absent strong reasons, and later languages 
ought to have more pressure to be more minimalist like Go and 
less "CISC" like D or Rust. Yet, complex D features like ranges 
(okay, more of a Phobos feature), operator overloading, CTFE, 
objects and templates don't seem to be commonly hated.

This inconsistency in our attitude towards language complexity is 
interesting in my opinion. I want to hear your opinions, would 
you rather use C or C++ in your job if you had to pick one ("it 
depends"-answers okay). But most importantly, why? What do you 
make of that C++ complexity seems to be so appreciated and so at 
contempt at the same time?
Aug 26 2022
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Friday, 26 August 2022 at 21:16:20 UTC, Dukc wrote:

 C++ is meant as an advancement of C.


The choice between `C++ 'and' C ` is very simple. Because `C++` 
can be more abstract.

In my eyes, the advantages of the `latest C++`: `templates, 
concepts, variable template parameters, folding expressions (very 
convenient), `, and `corotine` etc. There are also various 
easy-to-use `containers`.

  What `d` needed is to reasonably `arrange` personnel and 
determine the order of the `problems` to be solved.

Problem is complex, so `'C++'` is complex. Similarly, when it 
needs to be complex, it must be complex.
Aug 26 2022
parent reply Dukc <ajieskola gmail.com> writes:
On Saturday, 27 August 2022 at 01:22:31 UTC, zjh wrote:

 On Friday, 26 August 2022 at 21:16:20 UTC, Dukc wrote:

 C++ is meant as an advancement of C.


 The choice between `C++ 'and' C ` is very simple. Because `C++` 
 can be more abstract.

 In my eyes, the advantages of the `latest C++`: `templates, 
 concepts, variable template parameters, folding expressions 
 (very convenient), `, and `corotine` etc. There are also 
 various easy-to-use `containers`.


That's roughly what I'd think too. Still, so much excellent 
programmers pick C over C++, at least according to the article I 
linked.

Why they do that, that's what I'm wondering. I can maybe 
understand it for some firmware or device driver where everything 
is so low-level anyway that C++ doesn't offer much benefit but 
otherwise it's just mind-boggling.


  What `d` needed is to reasonably `arrange` personnel and 
 determine the order of the `problems` to be solved.


D wipes the floor with both of them anyway.
Aug 29 2022
next sibling parent zjh <fqbqrr 163.com> writes:
On Monday, 29 August 2022 at 19:15:41 UTC, Dukc wrote:

 On Saturday, 27 August 2022 at 01:22:31 UTC, zjh wrote:



 but otherwise it's just mind-boggling.



Nothing. They just chose the `wrong language` at the beginning. 
When they found out, they could not jump out.
They have accumulated their own function library, they can not do 
without it.
Aug 29 2022
prev sibling next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/29/22 3:15 PM, Dukc wrote:


 That's roughly what I'd think too. Still, so much excellent programmers 
 pick C over C++, at least according to the article I linked.


Keep in mind, that article is 13 years old. C++ has changed a lot since 
then. So has the programming language landscape. D2 was at version 2.035.

-Steve
Aug 29 2022
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 29 August 2022 at 19:15:41 UTC, Dukc wrote:

 On Saturday, 27 August 2022 at 01:22:31 UTC, zjh wrote:

 [...]


 That's roughly what I'd think too. Still, so much excellent 
 programmers pick C over C++, at least according to the article 
 I linked.

 Why they do that, that's what I'm wondering. I can maybe 
 understand it for some firmware or device driver where 
 everything is so low-level anyway that C++ doesn't offer much 
 benefit but otherwise it's just mind-boggling.


 [...]


 D wipes the floor with both of them anyway.


Only if you ignore the ecosystem, and that the two best 
optimizing D compilers have a backend written in C++, better 
grammar and semantics only gets you so far.
Aug 29 2022
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 29 August 2022 at 19:15:41 UTC, Dukc wrote:

 Why they do that, that's what I'm wondering. I can maybe 
 understand it for some firmware or device driver where 
 everything is so low-level anyway that C++ doesn't offer much 
 benefit but otherwise it's just mind-boggling.


* C is the only language that can be considered as a lingua 
franca and will remain in that position in the forseeable future. 
Far more programmers can use your library if you write it in C 
than in any other language.

* C++ does not have an OS mandated ABI, which most of the time is 
an advantage as  you can evolve and optimize more, but not for 
all use cases.

* You also loose a lot if you use C++ without a runtime. As a 
consequence of that it is much easier to convert a random C 
library so that it works without a runtime than to do the same 
with a random C++ library. So if you want your library to be 
useful in all contexts then you are better off writing it in C.

* You can easily convince yourself that the C-library you write 
for Python does not export symbols that Python does not require. 
It is easier to understand the consequences of using language 
features in C when writing plugins etc for other languages.

* C allows more typing hacks, more things are undefined behaviour 
in C++.

* "restrict" is standardized in C, compiler dependent in C++.

Does it make sense to pick C over C++ for language reasons? No… 
usually not. Are there other reasons? Yes.
Aug 30 2022
parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 30 August 2022 at 13:06:30 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 29 August 2022 at 19:15:41 UTC, Dukc wrote:

 ....





 * C++ does not have an OS mandated ABI, which most of the time 
 is an advantage as  you can evolve and optimize more, but not 
 for all use cases.

 ....


Neither does C, what is commonly called the C ABI, is the ABI 
from OSes written in C.

In the OSes that happen to have been written in C++, there is a 
C++ ABI, e.g. ARM mbed, Nokia SymbianOS,...
Aug 30 2022
prev sibling next sibling parent Abdulhaq <alynch4048 gmail.com> writes:
On Friday, 26 August 2022 at 21:16:20 UTC, Dukc wrote:

 This inconsistency in our attitude towards language complexity 
 is interesting in my opinion. I want to hear your opinions, 
 would you rather use C or C++ in your job if you had to pick 
 one ("it depends"-answers okay). But most importantly, why? 
 What do you make of that C++ complexity seems to be so 
 appreciated and so at contempt at the same time?


I'm a polyglot developer (going back to assembler, LISP, even 
COBOL for a few weeks), but most of my professional coding has 
been in Python, Java, and older 4GLs (LOL). However I have used C 
and C++ a lot in my hobby code and I've learnt over time that I 
now understand them better than many 'professionals'.

Around 20 yrs ago I decided to write a chess playing program that 
would make moves based on a strategy rather than brute force. I 
first wrote it in Java (around 1.4.2) and surprise, surprise it 
was dog slow. So I rewrote it in C++ and I was very disappointed 
to find that it was still very slow, in nodes per second, 
compared to other engines. Finally I rewrote it in C, and saw 
good performance. I later realised this was because in Java and 
C++ I was using 'new' for each computed new position (node). In C 
I just made a huge flat array up front at the start.

Anyway, to learn C++ I had used some sort of Teach Yourself C++ 
in 24hrs book (yes, really). It taught all about the wonders of 
inheritance etc.

Later, I started reading Herb Sutter's Guru of The Week column. I 
decided that there were too many gotchas and reluctantly 
abandoned C++ for hobby work. I also read a book with interviews 
with many famous software engineers, and most of them hated C++ 
(https://www.goodreads.com/book/show/6713575-coders-at-work).

At this stage I was helping to engineer high level designs for 
commercial aircraft using Qt, VTK, SciPy, python, CAD kernel 
software - we were doing good, technical work to a high standard. 
It was professionally held together with good quality python code 
calling libraries written in C++ and Fortran.

Onwards, and I read Andrei's TDPL. I was excited by this! My 
first foray into D was exciting but ultimately I had to write too 
many tools to build a tool to build a tool. I also did not see a 
clear direction for D, and decided to sit it out (where I am 
today).

Then, I read Bjarne's A Tour Of C++, which is excellent. I 
practised with it and interviewed for a couple of C++ jobs. I 
realised that they knew less about C++ than me, and were living 
in the world of C++ 98. Also, the pay was not very good! I did 
not pursue those jobs.

Finally, now to answer your question, I would choose to use C++ 
over C if I was coding in a small team. For a bigger team? I 
might well just sit it out and keep looking for work in 
python/java.
Aug 30 2022
prev sibling next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Friday, 26 August 2022 at 21:16:20 UTC, Dukc wrote:

 C++ is meant as an advancement of C. And it's used as one. Dmd 
 was written in C++ until version 2.069, and countless other 
 programs, both open and closed source still use it. It makes 
 sense - it's a superset of C (well, almost), so one can always 
 fall back to C features when the more complex features of C++ 
 don't justify themselves.

 [...]


I'd much rather use C++ over C. As to why C programmers don't 
migrate, well:

https://www.youtube.com/watch?v=D7Sd8A6_fYU
Aug 30 2022
parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 30 August 2022 at 11:53:40 UTC, Atila Neves wrote:

 On Friday, 26 August 2022 at 21:16:20 UTC, Dukc wrote:

 I'd much rather use C++ over C. As to why C programmers don't 
 migrate, well:

 https://www.youtube.com/watch?v=D7Sd8A6_fYU


Good video, thanks. So, you think it's all psychology? 
Considering we have popular political movements that can't IMO be 
explained rationally (won't say which movements I'm thinking 
here), potentially so. If we can be emotions-before-reason about 
politics, it only makes sense we can be emotions-before-reason 
about our tools.

Still, I hope there are more charitable reasons. We wouldn't want 
to declare C choosers to be fools after all. One could be what 
the top comment on that video says: "It wasn't the language 
itself, it was the people, and how they chose to use the 
language, and how they chose to show everyone how smart they were 
by using every possible feature of the language to its largest 
extent possible".
Sep 01 2022
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 1 September 2022 at 09:38:48 UTC, Dukc wrote:

 On Tuesday, 30 August 2022 at 11:53:40 UTC, Atila Neves wrote:

 [...]


 Good video, thanks. So, you think it's all psychology? 
 Considering we have popular political movements that can't IMO 
 be explained rationally (won't say which movements I'm thinking 
 here), potentially so. If we can be emotions-before-reason 
 about politics, it only makes sense we can be 
 emotions-before-reason about our tools.

 [...]


Psychology does play a big role, consider that many won't touch 
anything past C89 + compiler extensions, and C23 has just been 
finalized.
Sep 01 2022
parent Dukc <ajieskola gmail.com> writes:
On Thursday, 1 September 2022 at 11:41:08 UTC, Paulo Pinto wrote:

 Psychology does play a big role, consider that many won't touch 
 anything past C89 + compiler extensions, and C23 has just been 
 finalized.


Lol, I'm stretching my imagination on what could be their reasons 
for *that*. Is not having to write `int` at the beginning of a 
function so addictive?
Sep 01 2022
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Thursday, 1 September 2022 at 09:38:48 UTC, Dukc wrote:

 On Tuesday, 30 August 2022 at 11:53:40 UTC, Atila Neves wrote:

 On Friday, 26 August 2022 at 21:16:20 UTC, Dukc wrote:

 I'd much rather use C++ over C. As to why C programmers don't 
 migrate, well:

 https://www.youtube.com/watch?v=D7Sd8A6_fYU


 Good video, thanks. So, you think it's all psychology?


Yes, because it definitely has nothing to do with tech.


 Considering we have popular political movements that can't IMO 
 be explained rationally (won't say which movements I'm thinking 
 here), potentially so. If we can be emotions-before-reason 
 about politics, it only makes sense we can be 
 emotions-before-reason about our tools.


It's the same thing, it's politics all the way down.


 Still, I hope there are more charitable reasons.


Sadly, probably not.


 We wouldn't want to declare C choosers to be fools after all.


There are reasons to choose C. Some of them will be used by 
people post-hoc explaining their choice even if it had nothing to 
do with it. The decision isn't rational, the explanation 
afterwards is the brain trying to make sense of the original 
decision. See: "I can't use a GC language because..."


 One could be what the top comment on that video says: "It 
 wasn't the language itself, it was the people, and how they 
 chose to use the language, and how they chose to show everyone 
 how smart they were by using every possible feature of the 
 language to its largest extent possible".


That same person claims that "but the worst ANSI C I have 
encountered was easier to fix than the worst C++ I have 
encountered". Not in my experience. And that's part of the 
problem: we're all shaped by our own past experiences, and that's 
easy to see when looking at what different programmers 
prioritise. I think it's all a reaction to being burned before 
and avoiding *that*, but we've all been burned in very, very 
different ways.
Sep 08 2022
parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 8 September 2022 at 14:50:01 UTC, Atila Neves wrote:

 One could be what the top comment on that video says: "It 
 wasn't the language itself, it was the people, and how they 
 chose to use the language, and how they chose to show everyone 
 how smart they were by using every possible feature of the 
 language to its largest extent possible".


 That same person claims that "but the worst ANSI C I have 
 encountered was easier to fix than the worst C++ I have 
 encountered". Not in my experience.


Going crazy with macros will certainly make C as hard to read as 
any C++. But I think there may be a point in this otherwise. In C 
one pretty much only has to avoid being clever with the 
preprocessor, and it's hard to totally mess up the readability. 
But in C++ there are so much complex features that the code can 
have much worse readability issues than those caused by typical C 
problems (poor naming, no comments, lots of global state, 
oversized functions).

Worse, the complex C++ features are often recommended by the 
guidebooks, as opposed to macro trickery which is officially 
advised against.

Maybe the conclusion is that C++ is virtually always better than 
C in itself, but it's use is teached so badly that it often ends 
up worse.


 And that's part of the problem: we're all shaped by our own 
 past experiences, and that's easy to see when looking at what 
 different programmers prioritise. I think it's all a reaction 
 to being burned before and avoiding *that*, but we've all been 
 burned in very, very different ways.


Since D is a fairly complex language, I think we should talk more 
about when we should avoid the most complex features, such as 
traits. I suspect typical D programmers are not burned by 
overengineered language features as much as C programmers. Don't 
get me wrong, traits are great, but they do have a complexity 
cost in readability and error message quality. Sometimes a less 
perfect but simpler feature is the better choice even in D.

Related to getting burned by C++: Teoh made [an interesting 
rant](https://forum.dlang.org/post/mailman.216.1614033303.24831.digitalm
rs-d puremagic.com) about that before.
Sep 08 2022
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Sep 08, 2022 at 09:15:27PM +0000, Dukc via Digitalmars-d wrote:
[...]

 Going crazy with macros will certainly make C as hard to read as any
 C++.  But I think there may be a point in this otherwise. In C one
 pretty much only has to avoid being clever with the preprocessor, and
 it's hard to totally mess up the readability.


Are you ... *sure*? :-P

Haha, wait till you see some of the C code I've had to deal with.
Somebody, in a glorious fit of NIH, had decided that it was a good idea
to reinvent C++'s OO -- except partially, inconsistently, and without
the syntax niceties and compiler guarantees -- by writing function
pointers everywhere. And I mean, literally *everywhere*: open up a page
of code the code, and almost every line involves at least 1 call to a
function pointer. Most lines contain at least 2-3, some really bad ones
have 6 or more.  Basically, it's trying to imitate C++ polymorphic code
except in C.  But the problem is, since this is all hand-made and not
supported nor enforced by the compiler, the correspondence between
function pointers and logical virtual method calls is not 1-to-1...
meaning that sometimes you *think* a certain funcptr call would go
somewhere, but it goes somewhere else instead, because somebody along
the line decided to "override" it (unofficially) in order to, I don't
know, fix a bug or something.

And being all hand-spun, it's anybody's guess where these funcptrs are
initialized. You don't have syntactic ctors and class definitions that
you can look up to find out; these are all squirrelled away in obscure
parts of the code that, themselves, are chockful of funcptrs leading who
knows where.  Suspect a bug on some particular line of code?  Good luck
figuring out where that funcptr actually leads...  Well, you say, that's
easy, just find out where it's initialized.  OK, so you try to figure
out where it's initialized (hint: it's not anywhere you might imagine,
you have to search long and hard for it).  After you locate the code
that initializes it (by which time you're already tearing out your hair
in frustration), you see that it's also riddled with funcptr calls
head-to-toe, and exactly which value it uses to initialize the original
funcptr is dependent on a whole bunch of other funcptrs that leads who
knows where.  So, to figure out where 1 funcptr leads to, you have to
decipher 15 others.  And each of them, in turn, requires deciphering
where another 15 lead to (because their respective initialization
functions, you see, are written in exactly the same way).

So you can stare at the original function until the cows come home, and
you'd have no idea what it actually does.  Forget about reading the
code; the only way to figure this out is to use a debugger and
breakpoint it, then inspect where the funcptrs actually point to at
runtime.  Trying to decipher the initialization code is like getting
caught in a shark loan: you start out with a debt of 1 funcptr, and you
end up owing another 15, and for each of the 15, you owe yet another 15.
Compound funcptr interest FTW.

Yep, definitely hard to totally mess up readability in C. :-P



 But in C++ there are so much complex features that the code can have
 much worse readability issues than those caused by typical C problems
 (poor naming, no comments, lots of global state, oversized functions).


These are by far not the only problems with C. :-D  (See above. :-P)


[...]

 Maybe the conclusion is that C++ is virtually always better than C in
 itself, but it's use is teached so badly that it often ends up worse.


Um, no.  SFINAE + Koenig lookup.  That combo alone will give you
migraines for weeks, if not months.  No amount of good/bad teaching will
negate the fact that this combo is the stuff of nightmares.  Add to it
mix all the other "niceties" of C++, and ... yeah. Not going there.  I
think I'm suffering from C++ PTSD.

At least in C, once you nailed down that darned funcptr, you *know* it
isn't gonna cheat on you and go on a tryst with a completely unrelated
module that you hadn't suspected was surreptitiously #include'd where
the same identifier was gratuitously reused just to spice up your life.
Identifier hijacking FTW!


[...]

 Since D is a fairly complex language, I think we should talk more
 about when we should avoid the most complex features, such as traits.


One of the things I love about D is: the easier it is to write something
and the simpler it looks, the higher the chances are that it's actually
correct.  (Contrast this with C++, where the simplest way to write
something is almost certainly the wrong way; the right way involves
arcane incantations of black magic that not even seasoned C++ coders
have come to an agreement of which way is actually correct. And the
resulting code reads very much like an undecipherable arcane inscription
reverse-encrypted in Klingon.)

So I'd say the rule of thumb in D is, write it in the simplest way
possible to achieve what you want. If that fails, then consider the next
more complex thing up the ladder of complexity.  Only reach for the
ultimate weapon (did I hear, string mixin? ;-)) when no other recourse
suffices.



 I suspect typical D programmers are not burned by overengineered
 language features as much as C programmers. Don't get me wrong, traits
 are great, but they do have a complexity cost in readability and error
 message quality. Sometimes a less perfect but simpler feature is the
 better choice even in D.


[...]

Agreed.


T

-- 
"A man's wife has more power over him than the state has." -- Ralph Emerson
Sep 08 2022
parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 8 September 2022 at 22:26:12 UTC, H. S. Teoh wrote:

 Haha, wait till you see some of the C code I've had to deal 
 with. Somebody, in a glorious fit of NIH, had decided that it 
 was a good idea to reinvent C++'s OO -- except partially, 
 inconsistently, and without the syntax niceties and compiler 
 guarantees -- by writing function pointers everywhere. And I 
 mean, literally *everywhere*: open up a page of code the code, 
 and almost every line involves at least 1 call to a function 
 pointer. Most lines contain at least 2-3, some really bad ones 
 have 6 or more.  Basically, it's trying to imitate C++ 
 polymorphic code except in C.  But the problem is, since this 
 is all hand-made and not supported nor enforced by the 
 compiler, the correspondence between function pointers and 
 logical virtual method calls is not 1-to-1... meaning that 
 sometimes you *think* a certain funcptr call would go 
 somewhere, but it goes somewhere else instead, because somebody 
 along the line decided to "override" it (unofficially) in order 
 to, I don't know, fix a bug or something.


You got me to doubt my assessment ;).



 Maybe the conclusion is that C++ is virtually always better 
 than C in itself, but it's use is teached so badly that it 
 often ends up worse.


 Um, no.  SFINAE + Koenig lookup.  That combo alone will give 
 you migraines for weeks, if not months.  No amount of good/bad 
 teaching will negate the fact that this combo is the stuff of 
 nightmares.  Add to it mix all the other "niceties" of C++, and 
 ... yeah. Not going there.  I think I'm suffering from C++ PTSD.


I disagree somewhat, because it could be taught that one should 
avoid or be extra conservative with SFINAE because Koening 
lookup, and many other things, tend to mess it up. That's what I 
meant with bad teaching: encouraging to use C++ features which 
bite back like that.


 Only reach for the ultimate weapon (did I hear, string mixin? 
 ;-)) when no other recourse suffices.


In my opinion string mixins should not always be the last resort. 
Sure they have the downside that they are essentially macros that 
can do anything. Walter did wisely requiring the `mixin` keyword 
when using them, so they stand out clearly and are too ugly to be 
tempting.

But mixins have the upside that they are much simpler to 
understand than template and trait trickery. That's why a string 
mixins are IMO sometimes better than clever templates.
Sep 09 2022
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Fri, Sep 09, 2022 at 09:36:16AM +0000, Dukc via Digitalmars-d wrote:

 On Thursday, 8 September 2022 at 22:26:12 UTC, H. S. Teoh wrote:


[...]

 Um, no.  SFINAE + Koenig lookup.  That combo alone will give you
 migraines for weeks, if not months.  No amount of good/bad teaching
 will negate the fact that this combo is the stuff of nightmares.
 Add to it mix all the other "niceties" of C++, and ... yeah. Not
 going there.  I think I'm suffering from C++ PTSD.


 
 I disagree somewhat, because it could be taught that one should avoid
 or be extra conservative with SFINAE because Koening lookup, and many
 other things, tend to mess it up. That's what I meant with bad
 teaching: encouraging to use C++ features which bite back like that.


That's the problem with C++: its features bite back.  What business does
a feature that bites back have in a programming language??  Regardless
of how the language is taught, such features shouldn't be in the
language in the first place.  To shamelessly quote myself:

	A programming language should be a toolbox for the programmer to
	draw upon, not a minefield of dangerous explosives that you have
	to very carefully avoid touching in the wrong way. -- Me.



 Only reach for the ultimate weapon (did I hear, string mixin? ;-))
 when no other recourse suffices.


 
 In my opinion string mixins should not always be the last resort. Sure
 they have the downside that they are essentially macros that can do
 anything.  Walter did wisely requiring the `mixin` keyword when using
 them, so they stand out clearly and are too ugly to be tempting.
 
 But mixins have the upside that they are much simpler to understand
 than template and trait trickery. That's why a string mixins are IMO
 sometimes better than clever templates.


It depends on the use case.  Templates are much nicer than mixins in
certain cases, but in other cases it may be the other way round.

Hence my rule-of-thumb for D: write the code in the simplest way
possible; when that fails, reach for the next simplest tool.

In fact, in my own D projects I have resorted to external codegen in
some cases, instead of adding yet another layer of mixins/templates to
the code.  Sometimes, it's not worth the extra complexity and
maintenance burden just to have the bragging rights that you did it all
within the confines of the language; sometimes, the more sensible thing
to do is just to write a utility program that generates the desired D
code, and compile that into your main executable.

(Of course, this does assume a reasonably sane build system... if you're
stuck with Certain Hobbled Build Tools *cough*notnamingnameshere*cough*,
then over-complex templates and unreadable mixins may be your only
recourse. :-P)


T

-- 
Winners never quit, quitters never win. But those who never quit AND never win
are idiots.
Sep 09 2022
parent reply JG <someone simewhere.com> writes:
On Friday, 9 September 2022 at 15:58:12 UTC, H. S. Teoh wrote:

 On Fri, Sep 09, 2022 at 09:36:16AM +0000,


...

 In fact, in my own D projects I have resorted to external 
 codegen in some cases, instead of adding yet another layer of 
 mixins/templates to the code.  Sometimes, it's not worth the 
 extra complexity and maintenance burden just to have the 
 bragging rights that you did it all within the confines of the 
 language; sometimes, the more sensible thing to do is just to 
 write a utility program that generates the desired D code, and 
 compile that into your main executable.

 (Of course, this does assume a reasonably sane build system... 
 if you're stuck with Certain Hobbled Build Tools 
 *cough*notnamingnameshere*cough*, then over-complex templates 
 and unreadable mixins may be your only recourse. :-P)


 T


In my experience this can lead to, hard to debug code, since the 
error is in the generated code. Although of course debugging 
template heavy or mixin filled code is also not a picnic. How do 
you avoid this kind of  problem? For instance if you use, say, 
vide.d templates, which are an example of heavy usage of compile 
time features, and make a mistake in a template you often get a 
somewhat meaningful error message relating to the template file. 
This would probably be harder  with an external tool (since it 
would have to be able error check arbitrary d).
Sep 09 2022
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Sat, Sep 10, 2022 at 05:57:53AM +0000, JG via Digitalmars-d wrote:

 On Friday, 9 September 2022 at 15:58:12 UTC, H. S. Teoh wrote:

 On Fri, Sep 09, 2022 at 09:36:16AM +0000,


 ...

 In fact, in my own D projects I have resorted to external codegen in
 some cases, instead of adding yet another layer of mixins/templates
 to the code.  Sometimes, it's not worth the extra complexity and
 maintenance burden just to have the bragging rights that you did it
 all within the confines of the language; sometimes, the more
 sensible thing to do is just to write a utility program that
 generates the desired D code, and compile that into your main
 executable.




[...]

 In my experience this can lead to, hard to debug code, since the error
 is in the generated code.


In fact, this is precisely the advantage of separately generating the
code: you can examine the generated .d file for yourself and see
precisely what was generated.



 Although of course debugging template heavy or mixin filled code is
 also not a picnic. How do you avoid this kind of  problem?


Template-heavy / mixin-filled code is a nightmare to debug, if they were
not written to be debuggable. Because you cannot see what's the final
code that the compiler compiles.  Whereas generating a .d file as a
separate compilation step lets you examine the file yourself and find
where the bug is.



 For instance if you use, say, vide.d templates, which are an example
 of heavy usage of compile time features, and make a mistake in a
 template you often get a somewhat meaningful error message relating to
 the template file.


That's because the diet templates' code was written to generate these
nice error messages. When you run into a case the authors didn't
anticipate, good like trying to debug the heavily-nested diet code...

Of course, an error in a separately-generated .d file may not be trivial
to debug either, but presumably you also wrote the helper utility that
did it, so by seeing the error in the generated .d file, it would guide
you to look at the section of the helper utility responsible for
generating that bit of code, and you can go from there.



 This would probably be harder  with an external tool (since it would
 have to be able error check arbitrary d).


This is another disadvantage of using templates/mixins: external tools
have to be able to parse templates and magically infer what exactly is
the mixed-in string, in order to help you.  An externally-generated .d
file is just regular D code, you just use standard code utilities on it
and you're ready to go.


T

-- 
They say that "guns don't kill people, people kill people." Well I think the
gun helps. If you just stood there and yelled BANG, I don't think you'd kill
too many people. -- Eddie Izzard, Dressed to Kill
Sep 10 2022
parent reply JG <someone somewhere.com> writes:
On Saturday, 10 September 2022 at 13:58:51 UTC, H. S. Teoh wrote:

 On Sat, Sep 10, 2022 at 05:57:53AM +0000, JG via Digitalmars-d 
 wrote:

 [...]




 [...]

 [...]


 In fact, this is precisely the advantage of separately 
 generating the code: you can examine the generated .d file for 
 yourself and see precisely what was generated.



 [...]


 Template-heavy / mixin-filled code is a nightmare to debug, if 
 they were not written to be debuggable. Because you cannot see 
 what's the final code that the compiler compiles.  Whereas 
 generating a .d file as a separate compilation step lets you 
 examine the file yourself and find where the bug is.



 [...]


 That's because the diet templates' code was written to generate 
 these nice error messages. When you run into a case the authors 
 didn't anticipate, good like trying to debug the heavily-nested 
 diet code...

 Of course, an error in a separately-generated .d file may not 
 be trivial to debug either, but presumably you also wrote the 
 helper utility that did it, so by seeing the error in the 
 generated .d file, it would guide you to look at the section of 
 the helper utility responsible for generating that bit of code, 
 and you can go from there.



 [...]


 This is another disadvantage of using templates/mixins: 
 external tools have to be able to parse templates and magically 
 infer what exactly is the mixed-in string, in order to help 
 you.  An externally-generated .d file is just regular D code, 
 you just use standard code utilities on it and you're ready to 
 go.


 T


I agree in part with what you say, perhaps I will try it again 
sometime.
My last attempt was a few years ago being fed up writing go and 
not having templates. So I wrote a program that transformed "my 
templated go" into go.
For small things it was fine but when I tried to use it more 
seriously I
found trying to bug fix it painful. (In case someone feels the 
need to inform me that go has generics now - I am aware of that. 
I tried them I think they are not too great).
Sep 10 2022
parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Sat, Sep 10, 2022 at 05:05:18PM +0000, JG via Digitalmars-d wrote:

 On Saturday, 10 September 2022 at 13:58:51 UTC, H. S. Teoh wrote:


[...]

 This is another disadvantage of using templates/mixins: external
 tools have to be able to parse templates and magically infer what
 exactly is the mixed-in string, in order to help you.  An
 externally-generated .d file is just regular D code, you just use
 standard code utilities on it and you're ready to go.




[...]

 I agree in part with what you say, perhaps I will try it again
 sometime.  My last attempt was a few years ago being fed up writing go
 and not having templates. So I wrote a program that transformed "my
 templated go" into go.  For small things it was fine but when I tried
 to use it more seriously I found trying to bug fix it painful.


[...]

If I'm not mistaken, sounds like what you had wasn't so much a code
generator as a Go preprocessor, of sorts.  I usually don't bother with
codegen in this case, because D's templates work wonderfully.  The kind
of codegen that I'd need an external codegen to do, is usually when
there's some external data source or API driving the codegen (which in
theory I can do purely in D with CTFE and reflection, but at
considerable compile-time cost).

For example, automatically generating D APIs for GLSL shader uniform /
vertex attribute bindings by inspecting GLSL code.  The generated D code
allow me to use nice object.field syntax to set these bindings,
eliminating a whole bunch of fiddly boilerplate that would be very
error-prone to write manually.

Or processing input 3D data files and auto-generating code for uploading
vertex data converted to the appropriate format to the GPU, and
exporting a nice API for manipulating these objects. Especially in this
case, although in theory it's possible to load the data files with
string imports and process them in CTFE, the result would be compilation
unacceptably slow.  By processing them separately, I only need to
generate the target .d file once, and it can be compiled as a normal
source file, and only need to be regenerated when something changes in
the input data files.


T

-- 
You are only young once, but you can stay immature indefinitely. -- azephrahel
Sep 13 2022
prev sibling next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 8/26/22 14:16, Dukc wrote:


 one can always fall back to C features when the
 more complex features of C++ don't justify themselves.


It can be too easy to fall back to C without justification. Real code 
I've seen not too long ago:

    foo(("hello" + bar()).c_str());

Why the c_str() there I wonder... But don't worry: foo makes a fresh 
string to put it in a struct object member anyway. O... K..., I guess...

Another one:

   strncpy(obj.path, zar("blah").c_str(), FILEPATH_LENGTH - 1);

Four problems:

1) As mentioned, what the c_str()!

2) Faith-based programming by using obj.path's hard-coded array size as 
FILEPATH_LENGTH.

3) Where is the null terminator, buddy? Rather, when are you going to 
read the man page?

4) What happens if the path doesn't fit?

Isn't that way too many problems in a single line of C++ code?


 Can it be that C++ is so complex


True.


 that even conservative use of it makes
 your codebase so unreadable that even the archaic C is a better choice?


I disagree. I had decided long time ago that C++ would always beat C by 
the following features alone:

1) Constructors and destructors

2) Exceptions

3) Templates

Except, you need to code to a platform where a C++ compiler is not 
available.

I say that under long experience with a very well-written C framework. 
It was trying to be C++ and that's fair but C is too cumbersome to use. 
Defining equivalents of vector, hash map, etc. with macros is amazing 
but gets painful very quickly.

I liked the bail macros though; they were imitating exceptions:

   err = foo();
   bair_error();

finally:
   // Do cleanup
   return err;

But correct usage of those goodies depended on programmer attention. For 
example, you had to have an 'err' variable in such functions, you had to 
'return err', etc.


 There has to be HUGE downsides in C++ for this competent people to
 resort to this drastic avoidance.


Let's not underestimate humans. It is much easier to rationalize staying 
with your favorite language than learning a new one. And C++ makes that 
choice easy.

Personally, I went to laughable extents to search for dislikable things 
in Rust. :/


 it had been long since generally aknowledged: C++ guidebooks would
 tell to avoid less-known language features absent strong reasons


There are the clearly failed ones like std::auto_ptr, std::strstream, 
etc. Other than that, C++ people carry the esoteric guidelines like 
badges of honor. I used to be one. I was proud that you could not write 
good C++ without having read 5 specific books. And it was an equity 
issue as well: Those books were not available to most of the non-English 
speaking people.

C++ is a language that requires one to read and learn and read and learn 
and follow at least 400+ rules to write correct programs. There is no 
other way to say it. And that is nothing but a failure. (Why am I 
bashing C++ again! Argh!) My respect towards leaders of the C++ 
community fell because they don't see any problem and continue to sell 
C++ as the best thing ever, "inventing" everything, etc. They even say 
things like "Another language is not a solution [...] Java tried..." 
Stomping language design just because Java failed is not an argument. 
How about getting back to what C++ tried and failed. And instead of 
saying things like "A language with reference types? No thanks!", C++ 
experts should say "A language with 400+ rules to follow? No thanks!"


 This inconsistency in our attitude towards language complexity is
 interesting in my opinion.


One word: Humans...


 would you
 rather use C or C++ in your job if you had to pick one


Hands down C++. And again, I used both of those languages very 
extensively in very good written frameworks.


 What do you make of
 that C++ complexity seems to be so appreciated and so at contempt at the
 same time?


Humans... I did ask a Google intern once who was visiting from Europe 
and working on some awesome C++ project. He was an expert in C++ and was 
presenting his work at one of our local meetups. I asked him "Why C++ 
when there are so many new modern languages popping up?". He laughed and 
said "Because it's hard!".

C++ is carried forward by an amazing mass of very smart people who are 
in it for the standardese, the conferences, knowledge of the esoteric 
("do you know how you can create integer ids at compile time for 
somethings in your struct definitions and blah"), blog posts, etc.

Ali
Aug 30 2022
prev sibling next sibling parent reply JN <666total wp.pl> writes:
On Friday, 26 August 2022 at 21:16:20 UTC, Dukc wrote:

 C++ is meant as an advancement of C. And it's used as one. Dmd 
 was written in C++ until version 2.069, and countless other 
 programs, both open and closed source still use it. It makes 
 sense - it's a superset of C (well, almost), so one can always 
 fall back to C features when the more complex features of C++ 
 don't justify themselves.


I think there is a large group of programmers who are looking for 
a successor to C. C is attractive for several reasons. The 
limited set of features is a benefit sometimes, because you don't 
overthink your design and many libraries in C can interoperate 
with each other easily (compare with D where you have to reason 
OOP vs more functional style,  nogc vs GC or even betterC). Code 
completion will almost always work because there are no templates 
to get in your way (macros can be messy though). The ABI is well 
defined, so you can easily interact with your code from other 
languages. The WASM story is developing well too.

However, C is showing it's age. Manual memory management without 
any help from runtime/static analysis is passé. Lack of function 
and operator overloading is annoying. Arrays which decay to 
pointers and arrays that don't remember their length eat 
countless manhours trying to debug those issues.

Out of the newcoming languages, Zig is trying to fit that niche 
the most. I can't get over the syntax, but I'd really like to try 
it someday, when it reaches 1.0 version.
Aug 30 2022
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 31/08/2022 8:02 AM, JN wrote:

 However, C is showing it's age.


Nah, C was never state of the art.

C was a bad language in the 1970's and its still a bad language today.

It did not succeed due to its feature set, but its syntax.

Other languages like ML existed within a few years of C which have 
significantly more powerful features (as in, D still can't match it for 
some things)!
Aug 30 2022
parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 30 August 2022 at 20:17:51 UTC, rikki cattermole 
wrote:

 On 31/08/2022 8:02 AM, JN wrote:

 However, C is showing it's age.


 Nah, C was never state of the art.

 C was a bad language in the 1970's and its still a bad language 
 today.

 It did not succeed due to its feature set, but its syntax.

 Other languages like ML existed within a few years of C which 
 have significantly more powerful features (as in, D still can't 
 match it for some things)!


It succeed, because of UNIX, just like JavaScript on the browser, 
if the OS already offers a free compiler, which uses it for 
everything it is writtten on, no one is going to pay for 
something else.

This naturally changed when Sun decided spliting SunOS into user 
and developer editions was a good idea.

GNU also helped as the initial GNU manifesto required C as the 
main language for its UNIX cloning project (later revisions added 
support for C++, Java, not bothering to check the current 
version).

Had AT&T been allowed to sell Bell Labs research from the get go, 
and history might have turned out quite different for anything 
UNIX related, when it would be a commercial product at the same 
price level as VAX/VMS, System 360 and others.
Aug 30 2022
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 30 August 2022 at 20:02:44 UTC, JN wrote:

 On Friday, 26 August 2022 at 21:16:20 UTC, Dukc wrote:

 C++ is meant as an advancement of C. And it's used as one. Dmd 
 was written in C++ until version 2.069, and countless other 
 programs, both open and closed source still use it. It makes 
 sense - it's a superset of C (well, almost), so one can always 
 fall back to C features when the more complex features of C++ 
 don't justify themselves.


 I think there is a large group of programmers who are looking 
 for a successor to C. C is attractive for several reasons. The 
 limited set of features is a benefit sometimes, because you 
 don't overthink your design and many libraries in C can 
 interoperate with each other easily (compare with D where you 
 have to reason OOP vs more functional style,  nogc vs GC or 
 even betterC). Code completion will almost always work because 
 there are no templates to get in your way (macros can be messy 
 though). The ABI is well defined, so you can easily interact 
 with your code from other languages. The WASM story is 
 developing well too.

 However, C is showing it's age. Manual memory management 
 without any help from runtime/static analysis is passé. Lack of 
 function and operator overloading is annoying. Arrays which 
 decay to pointers and arrays that don't remember their length 
 eat countless manhours trying to debug those issues.

 Out of the newcoming languages, Zig is trying to fit that niche 
 the most. I can't get over the syntax, but I'd really like to 
 try it someday, when it reaches 1.0 version.


C was already showing its age in the mid-90's, when compared 
againt languages like Modula-2 (1978) or Object Pascal (1986), 
and in what concerns language features (except for comptime), Zig 
is pretty much what those languages offered.

The key question remains, will the UNIX folks and embedded 
hardware communities, ever adopt anything other than C?

Even on the embedded world, using C99 is considered being modern, 
let alone something else.
Aug 30 2022
prev sibling next sibling parent MrJay <mrjcraft2021 gmail.com> writes:
On Friday, 26 August 2022 at 21:16:20 UTC, Dukc wrote:

 C++ is meant as an advancement of C. And it's used as one. Dmd 
 was written in C++ until version 2.069, and countless other 
 programs, both open and closed source still use it. It makes 
 sense - it's a superset of C (well, almost), so one can always 
 fall back to C features when the more complex features of C++ 
 don't justify themselves.

 Yet, many of the most well-known and successful programmers 
 [don't see it like 
 that](https://harmful.cat-v.org/software/c++/coders-at-work). 
 Can it be that C++ is so complex that even conservative use of 
 it makes your codebase so unreadable that even the archaic C is 
 a better choice? Think how crazy this is - the cream of of our 
 profession resort to pointer / length pairs over `std::vector`, 
 and copy-pasting the module name to every public declaration 
 over using namespaces.

 There has to be HUGE downsides in C++ for this competent people 
 to resort to this drastic avoidance. They do say what the 
 downsides of C++ are about: too big a language to learn well, 
 so code ends up using features the reader does not know. Still, 
 if this is the case one would think it had been long since 
 generally aknowledged: C++ guidebooks would tell to avoid 
 less-known language features absent strong reasons, and later 
 languages ought to have more pressure to be more minimalist 
 like Go and less "CISC" like D or Rust. Yet, complex D features 
 like ranges (okay, more of a Phobos feature), operator 
 overloading, CTFE, objects and templates don't seem to be 
 commonly hated.

 This inconsistency in our attitude towards language complexity 
 is interesting in my opinion. I want to hear your opinions, 
 would you rather use C or C++ in your job if you had to pick 
 one ("it depends"-answers okay). But most importantly, why? 
 What do you make of that C++ complexity seems to be so 
 appreciated and so at contempt at the same time?


C and C++ is very complicated, I recently had to choose between C 
and C++, but I ended up choosing D instead. the reasons why are.
1. to many baskets not enough eggs.
2. Community designed complexity.

* To many baskets not enough eggs
C was designed to be a systems level programming language, it 
became a general purpose language because of community and 
industry effort, C++ was not designed to be anything it is an 
extension on C it was designed to be C plus extra features, as 
C++ became designed they want there cake and to eat it to, 
meaning that they want every good feature from many other popular 
languages like Haskell, or Python or whatever, however the 
difference between what D has done and C++ is doing that D was 
for the most part designed to Read fast Write fast and Run Fast, 
its on the home page, C++ is designed to be fast, and every other 
feature that C++ tries to add is just a bonus if they can even 
get it to work, for example I cant image C++ with a GC, however 
they talk about adding usability features, and it sure sounds 
like that would be a feature that would help their target 
audience, the designers talk about adding features to help 
scientists but its just talk unless they actually do it, and a GC 
would help, but they are not willing to make sacrifices to make a 
general purpose language, D is a general purpose language, it 
sacrifices Speed when it needs to when you want to just test an 
idea, but you can also make it as fast as C or C++. the design 
has clean edges even if its very broad, while C++ is also very 
broad but it has very rough edges.

* Community Designed complexity
When I tried to learn C++ the part that made me the most confused 
was the community, C style code tends to be faster than C++ style 
code, at least by my metrics and the metrics I have seen, so I 
want to use C to make faster programs, but I like many of the C++ 
libraries and some of the nice features, however when I go to 
learn C++ so much code is in C++ style as a beginner I really 
didnt want to decipher it all, so I just wanted to use C instead 
but then I find out about this awesome C++ library and the cycle 
continues, though this issue was self inflicted, all I had to do 
to fix the issue was to not care about how fast my code is, but 
that is the whole purpose of using C and C++, typically use that 
your code is fast. so why use C++ for ease of use, for me it was 
supposed to be for speed. so again like what I mentioned above 
its meant to be for speed but the code people write is because 
its "Correct" code, because that code according to someone is 
easier, which tends to be slower.

the community the language design in some ways.
Aug 30 2022
prev sibling parent reply sonal13 <singhalishaas60 gmail.com> writes:
On Friday, 26 August 2022 at 21:16:20 UTC, Dukc wrote:

 C++ is meant as an advancement of C. And it's used as one. Dmd 
 was written in C++ until version 2.069, and countless other 
 programs, both open and closed source still use it. It makes 
 sense - it's a superset of C (well, almost), so one can always 
 fall back to C features when the more complex features of C++ 
 don't justify themselves.

 Yet, many of the most well-known and successful programmers 
 [don't see it like 
 that](https://harmful.cat-v.org/software/c++/coders-at-work). 
 Can it be that C++ is so complex that even conservative use of 
 it makes your codebase so unreadable that even the archaic C is 
 a better choice? Think how crazy this is - the cream of of our 
 profession resort to pointer / length pairs over `std::vector`, 
 and copy-pasting the module name to every public declaration 
 over using namespaces.

 There has to be HUGE downsides in C++ for this competent people 
 to resort to this drastic avoidance. They do say what the 
 downsides of C++ are about: too big a language to learn well, 
 so code ends up using features the reader does not know. Still, 
 if this is the case one would think it had been long since 
 generally aknowledged: C++ guidebooks would tell to avoid 
 less-known language features absent strong reasons, and later 
 languages ought to have more pressure to be more minimalist 
 like Go and less "CISC" like D or Rust. Yet, complex D features 
 like ranges (okay, more of a Phobos feature), operator 
 overloading, CTFE, objects and templates don't seem to be 
 commonly hated.

 This inconsistency in our attitude towards language complexity 
 is interesting in my opinion. I want to hear your opinions, 
 would you rather use C or C++ in your job if you had to pick 
 one ("it depends"-answers okay). But most importantly, why? 
 What do you make of that C++ complexity seems to be so 
 appreciated and so at contempt at the same time?


The fact that C++ is a superset of C also means that it can be 
used to extend C programs. This is often done by adding new 
features or functionality to the program. For example, a C++ 
program could be used to add object-oriented programming features 
to a C program.

Overall, C++ is a powerful and versatile language that is 
well-suited for a wide variety of programming tasks. It is a good 
choice for both beginners and experienced programmers.

Here are some additional things to consider about C++ and C and 
check this to learn more about [c++ and 
c](https://www.interviewbit.com/blog/difference-between-c-and-cpp/).

C++ is a compiled language, which means that the code is 
converted into machine code before it is executed. This makes C++ 
programs faster than interpreted languages, such as Python.
C++ is a statically typed language, which means that the types of 
variables and expressions must be declared before they are used. 
This makes C++ programs more reliable and easier to debug.
C++ is a complex language, with a steep learning curve. However, 
it is a powerful language that can be used to create 
high-performance applications.
If you are interested in learning C++ or C, there are many 
resources available online and in libraries. There are also many 
online courses and tutorials that can help you get started.
Jun 23 2023
parent drug007 <drug2004 bk.ru> writes:
23.06.2023 13:17, sonal13 пишет:

 
 The fact that C++ is a superset of C also means that it can be used to 
 extend C programs. This is often done by adding new features or 
 functionality to the program. For example, a C++ program could be used 
 to add object-oriented programming features to a C program.
 


I wouldn't say that c++ is a superset of C. There is a difference 
between these similar languages.
Jun 23 2023