C++, epiphanies, article content ideas
-
Disclaimer: What I'm about to talk about is C++ implementation details. C++ compilers aren't *necessarily* implemented the way I describe in theory, but in practice they virtually all are - at least the major ones, AFAIK. C++ is very "lexical" in how it works. The bones of the OOP, method overloading, and template instantiations are implemented in part through name mangling, which is fundamentally lexical vs having a different, say, integer or binary key for each of the above. The template instantiations work like a mail merge, but with "smart" template parameters (by smart I mean, not simply lexical but type aware, compiler resolved). The actual template code is basically search and replaced, but template resolution is "smart" (similar to how i used the word above) in that it can resolve recursively and stuff, so it's a bit more complicated than strict search replace, but it's close. C++ in many ways (but not all ways) is C with syntactic sugar. C++ OOP isn't special. It's basically C with a combination of name mangling, and hiding the first (implicit)
thisargument consider the following#include
class foo {
int m_bar;
public:
foo(/*foo* this*/) : /*this->*/m_bar(0) {} int bar(/\*foo\* this\*/) const { return this->m\_bar; } void bar(/\*foo\* this, \*/ int value) { this->m\_bar = value; }};
typedef struct _foo_c {
int bar;
} foo_c_t;void foo_foo_foo_c_t(foo_c_t* handle) {
// : m_bar(0)
handle->bar = 0;
}
int foo_bar_foo_c_t(foo_c_t* handle) {
// return this->bar;
return handle->bar;
}
void foo_bar_foo_c_t_int(foo_c_t* handle, int value) {
// this->bar = value;
handle->bar = value;
}int main(int argc, char** argv) {
foo foo_cpp;
foo_cpp.bar(42);foo\_c\_t foo\_c; foo\_foo\_foo\_c\_t(&foo\_c); foo\_bar\_foo\_c\_t\_int(&foo\_c,42); printf("foo\_cpp: %d, foo\_c: %d\\n",foo\_cpp.bar(),foo\_bar\_foo\_c\_t(&foo\_c)); return 0;}
That's C++ and its rough equivalent as C code, and the C is similar to how the C++ resolves internally. I feel like understanding that helped me greatly understand C++. I'm wondering if any other C++ developers out there had a similar epiphany about the language that helped them understand it better, and what it was. Part of it is I was thinking of compiling an article about this, but the above isn't enough by itself. I'm hoping to add more content, but maybe some of you who have had similar epiphanies about the language
-
Disclaimer: What I'm about to talk about is C++ implementation details. C++ compilers aren't *necessarily* implemented the way I describe in theory, but in practice they virtually all are - at least the major ones, AFAIK. C++ is very "lexical" in how it works. The bones of the OOP, method overloading, and template instantiations are implemented in part through name mangling, which is fundamentally lexical vs having a different, say, integer or binary key for each of the above. The template instantiations work like a mail merge, but with "smart" template parameters (by smart I mean, not simply lexical but type aware, compiler resolved). The actual template code is basically search and replaced, but template resolution is "smart" (similar to how i used the word above) in that it can resolve recursively and stuff, so it's a bit more complicated than strict search replace, but it's close. C++ in many ways (but not all ways) is C with syntactic sugar. C++ OOP isn't special. It's basically C with a combination of name mangling, and hiding the first (implicit)
thisargument consider the following#include
class foo {
int m_bar;
public:
foo(/*foo* this*/) : /*this->*/m_bar(0) {} int bar(/\*foo\* this\*/) const { return this->m\_bar; } void bar(/\*foo\* this, \*/ int value) { this->m\_bar = value; }};
typedef struct _foo_c {
int bar;
} foo_c_t;void foo_foo_foo_c_t(foo_c_t* handle) {
// : m_bar(0)
handle->bar = 0;
}
int foo_bar_foo_c_t(foo_c_t* handle) {
// return this->bar;
return handle->bar;
}
void foo_bar_foo_c_t_int(foo_c_t* handle, int value) {
// this->bar = value;
handle->bar = value;
}int main(int argc, char** argv) {
foo foo_cpp;
foo_cpp.bar(42);foo\_c\_t foo\_c; foo\_foo\_foo\_c\_t(&foo\_c); foo\_bar\_foo\_c\_t\_int(&foo\_c,42); printf("foo\_cpp: %d, foo\_c: %d\\n",foo\_cpp.bar(),foo\_bar\_foo\_c\_t(&foo\_c)); return 0;}
That's C++ and its rough equivalent as C code, and the C is similar to how the C++ resolves internally. I feel like understanding that helped me greatly understand C++. I'm wondering if any other C++ developers out there had a similar epiphany about the language that helped them understand it better, and what it was. Part of it is I was thinking of compiling an article about this, but the above isn't enough by itself. I'm hoping to add more content, but maybe some of you who have had similar epiphanies about the language
honey the codewitch wrote:
C++ in many ways (but not all ways) is C with syntactic sugar.
One might argue that C is just assembler with syntactic sugar too. :-D I think you could make the same argument about any of the C Family of languages: C, C++, Objective C, Java, C# etc. Perhaps even Go and Rust? And, of course, we can't forget that Bjarne Stroustrup's original work on C++ (C with classes) was implemented with [Cfront - Wikipedia](https://en.wikipedia.org/wiki/Cfront), which converted C++ code to plain C.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
-
honey the codewitch wrote:
C++ in many ways (but not all ways) is C with syntactic sugar.
One might argue that C is just assembler with syntactic sugar too. :-D I think you could make the same argument about any of the C Family of languages: C, C++, Objective C, Java, C# etc. Perhaps even Go and Rust? And, of course, we can't forget that Bjarne Stroustrup's original work on C++ (C with classes) was implemented with [Cfront - Wikipedia](https://en.wikipedia.org/wiki/Cfront), which converted C++ code to plain C.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
No. In C# a class is first class, binary structured as a class to the CLI, with metadata, etc. In C++, a class is little more than what I demonstrated with code above - a bunch of renamed methods with a hidden this parameter. I guess I wasn't clear. I even produced code to try to make it clear. Meh. But I guess yeah - Cfront existed. C++ is C with syntactic sugar.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
honey the codewitch wrote:
C++ in many ways (but not all ways) is C with syntactic sugar.
One might argue that C is just assembler with syntactic sugar too. :-D I think you could make the same argument about any of the C Family of languages: C, C++, Objective C, Java, C# etc. Perhaps even Go and Rust? And, of course, we can't forget that Bjarne Stroustrup's original work on C++ (C with classes) was implemented with [Cfront - Wikipedia](https://en.wikipedia.org/wiki/Cfront), which converted C++ code to plain C.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
Cfront (I had forgotten that name!) taught me "everything" about OO. I guess I should say "all the fundamentals" - OO has developed since then. I had been OO programming since 1979, student exercises in Simula, but our Compiler Construction course did not address OO at all. (Maybe later editions of the dragon book did, but not the current edition when we were students.) So, when we got a chance to see in cleartext how a compiler realized OO mechanisms, it was like a revelation to us. My memory and calendar suggest that we had access to the C++ compiler earlier than 1983, the official release date of Cfront - maybe it was in 1982. It wasn't uncommon for professors and students swimming across the pond to return with all sorts of new and fancy software discretely hidden in their briefcases. Maybe the 'Cfront' name wasn't assigned to it, and that is why I don't remember the name.
Religious freedom is the freedom to say that two plus two make five.
-
Disclaimer: What I'm about to talk about is C++ implementation details. C++ compilers aren't *necessarily* implemented the way I describe in theory, but in practice they virtually all are - at least the major ones, AFAIK. C++ is very "lexical" in how it works. The bones of the OOP, method overloading, and template instantiations are implemented in part through name mangling, which is fundamentally lexical vs having a different, say, integer or binary key for each of the above. The template instantiations work like a mail merge, but with "smart" template parameters (by smart I mean, not simply lexical but type aware, compiler resolved). The actual template code is basically search and replaced, but template resolution is "smart" (similar to how i used the word above) in that it can resolve recursively and stuff, so it's a bit more complicated than strict search replace, but it's close. C++ in many ways (but not all ways) is C with syntactic sugar. C++ OOP isn't special. It's basically C with a combination of name mangling, and hiding the first (implicit)
thisargument consider the following#include
class foo {
int m_bar;
public:
foo(/*foo* this*/) : /*this->*/m_bar(0) {} int bar(/\*foo\* this\*/) const { return this->m\_bar; } void bar(/\*foo\* this, \*/ int value) { this->m\_bar = value; }};
typedef struct _foo_c {
int bar;
} foo_c_t;void foo_foo_foo_c_t(foo_c_t* handle) {
// : m_bar(0)
handle->bar = 0;
}
int foo_bar_foo_c_t(foo_c_t* handle) {
// return this->bar;
return handle->bar;
}
void foo_bar_foo_c_t_int(foo_c_t* handle, int value) {
// this->bar = value;
handle->bar = value;
}int main(int argc, char** argv) {
foo foo_cpp;
foo_cpp.bar(42);foo\_c\_t foo\_c; foo\_foo\_foo\_c\_t(&foo\_c); foo\_bar\_foo\_c\_t\_int(&foo\_c,42); printf("foo\_cpp: %d, foo\_c: %d\\n",foo\_cpp.bar(),foo\_bar\_foo\_c\_t(&foo\_c)); return 0;}
That's C++ and its rough equivalent as C code, and the C is similar to how the C++ resolves internally. I feel like understanding that helped me greatly understand C++. I'm wondering if any other C++ developers out there had a similar epiphany about the language that helped them understand it better, and what it was. Part of it is I was thinking of compiling an article about this, but the above isn't enough by itself. I'm hoping to add more content, but maybe some of you who have had similar epiphanies about the language
honey the codewitch wrote:
I'm wondering if any other C++ developers out there had a similar epiphany about the language that helped them understand it better, and what it was.
Certainly that wasn't the case for me. I didn't have a problem understanding the language. I had a problem thinking about problems that lead to Object Oriented designs. Rather than structured designs.
honey the codewitch wrote:
but with "smart" template parameters (by smart I mean, not simply lexical but type aware, compiler resolved).
I solve enterprise problems. And I have been doing that for a very long time. Language syntax sugar is often just gets in the way of large scale solutions which must be maintained for decades. A company that is going to be successful is going to hire a large number of developers and that means they will tend towards the average and not the above average. And they will have specific and limited skill sets that they have learned, even senior developers. Relying on esoteric language features lead to nothing but confusion and higher maintenance costs.
-
honey the codewitch wrote:
I'm wondering if any other C++ developers out there had a similar epiphany about the language that helped them understand it better, and what it was.
Certainly that wasn't the case for me. I didn't have a problem understanding the language. I had a problem thinking about problems that lead to Object Oriented designs. Rather than structured designs.
honey the codewitch wrote:
but with "smart" template parameters (by smart I mean, not simply lexical but type aware, compiler resolved).
I solve enterprise problems. And I have been doing that for a very long time. Language syntax sugar is often just gets in the way of large scale solutions which must be maintained for decades. A company that is going to be successful is going to hire a large number of developers and that means they will tend towards the average and not the above average. And they will have specific and limited skill sets that they have learned, even senior developers. Relying on esoteric language features lead to nothing but confusion and higher maintenance costs.
Ummm, templates are not an esoteric language feature. The Standard Template Library is based around them.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Ummm, templates are not an esoteric language feature. The Standard Template Library is based around them.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Using a library and writing one are two different things. I have written an XML parser. I have also used XML libraries. I would much rather find and use an existing. I have also written templates (with care.) But that doesn't mean that I want all developers to write them. Not in enterprise systems.
-
Using a library and writing one are two different things. I have written an XML parser. I have also used XML libraries. I would much rather find and use an existing. I have also written templates (with care.) But that doesn't mean that I want all developers to write them. Not in enterprise systems.
Fair enough. I do embedded, and I write libraries, so I use templates often enough. It's particularly useful when doing hardware mapping of a C++ based device controller. The pins for example, can be set at compile time because they're soldered onto the board, and IMO it's much cleaner than a #define.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Fair enough. I do embedded, and I write libraries, so I use templates often enough. It's particularly useful when doing hardware mapping of a C++ based device controller. The pins for example, can be set at compile time because they're soldered onto the board, and IMO it's much cleaner than a #define.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
hardware mapping of a C++ based device controller.
Sounds good. But I don't want some mid-level developer that just discovered templates and databases to decide that he/she is going to improve the world by creating templates that encapsulate everything in the database layer.