char *concat(char *p, char *q)
{
size_t plen = strlen(p);
size_t qlen = strlen(q);
char *r = (char*)malloc(plen + qlen + 1);
assert(r);
memcpy(r, p, plen);
memcpy(r + plen, q, qlen + 1);
return r;
}
And never mind the issue of when to free() r. Contrast with D: string concat(string p, string q)
{
return p ~ q;
}
P.S. Yes, I know about the potential overflow problem with `plen + qlen + 1`.I might not pick D as a beginner language simply because it unfortunately isn't very popular, but I certainly wouldn't pick C as a beginner language.
int *p = 2;
Look, you and I know this is horrible and should probably be a war crime, but you have to admit: it's elegant. The ability to pierce the abstraction with C is the only reason it's on that list. I can teach people how computers actually work without getting to assembly (though it's usually a good idea to go there). It all depends on the goal. If your goal is to understand how computers execute programs, then a little C doesn't hurt.> But it teaches bad habits, which have to be unlearned.
Apologies, but you're confused again: you've conflated learning how to code, with learning to be a software engineer. They're related, but less so than you think.
In my experience, it is impossible to teach a student a lesson that requires experience without providing them the opportunity to experience it. Teach someone Basic, let them do bad things, then show them the light.
"If you give a man a fish" and all that.
When I see `int *p = 2;`, "elegant" is not at all what comes to mind. "Bug" is what comes to mind.
Reminds me of my wood shop teacher. He showed me the right way to use hand tools, from the start, which pays off every time since that I use one. He also showed how to use power tools, and never failed to show us the missing finger on his hand - the price for taking shortcuts.
Whenever I use the table saw, I think of his finger stub and slow down, take my time, and do it right.
Keep in mind that I created D because I wanted to program in it. It is based on my decades of experience with other languages and supporting those languages and knowing where people go wrong with them and where the problems are.
> C
C is a simple language, but grasping how it works is not simple. To get C you need to understand assembler, which is not simple at all. The misunderstandings novices have about pointers, for example, are misunderstandings about how computers work.
C is loaded with legacy problems, too, like uninitialized variables containing garbage. There's all that confusion between prototypes and non-prototypes. Implicit coercion of 2 to a pointer:
The C preprocessor is nowhere near as simple as it appears. Arrays are determined to decay to uncontrolled pointers. Buffer overflows are pervasive, even among the most professional programs.D (as Better C) is a very C-like language, but minus those problems. It's reasonable to say it is much more easily learned. It has far fewer footguns.
> You've confused
I may have been unclear, but I am not confused.
I've written two C compilers from scratch, and 3 C preprocessors. I know every last dirty detail of C.
Basic, however, we can agree is a simple language. But it teaches bad habits, which have to be unlearned.