MyEmail {l Wrote}:See, that's a prime example of how people are plagued by conventional knowledge. Their too stuck on what society teaches them instead of pushing the boundaries and expanding.
You are very arrogant. How do you know I said that because I'm stuck into "conventional knowledge" rather than from a "been there, done that" point of view?
MyEmail {l Wrote}:Zlodo {l Wrote}:It doesn't solve the biggest problems with the standard C preprocessor
It doesn't? You could have fooled me, as I certainly don't have to deal with most of those issues (not even the debugging one). The features I have implemented are very useful, and actually fixes many of the issues the C macro system has. In fact, and just for an example, debugging is actually much easier than traditional C.
I don't have to deal with any of those issues because I don't use macros. I use inline functions and templates instead. You know, the tools provided by the language, instead of a preprocessor based frankenstein solution.
And in fact I don't see where and how your system actually avoids multiple macro parameters evaluation. What happens if one of the expression you pass as a macro parameter in your example have a side effect?
MyEmail {l Wrote}:Oh, and anyone who has issues with C-macros are just too inexperienced to use them correctly.
Or perhaps experienced enough to realize that they have been superseded by much better solution for almost every use case.
MyEmail {l Wrote}:I guarantee you have never seen code like mine before.
And now I wish it would have stayed that way. But more seriously, I have seen (and myself wrote) lots of shitty code where people tried too hard to be clever but just ended up needlessly complicating everything for absolutely no gain at all. You are not unique.
MyEmail {l Wrote}:Take a look at a quick test-case scenario (which demonstrates the most basic features):
<snip scrublord code>
That implements a memory allocation system similar to C++, but is much faster (performance AND dev-time wise). It is also far more versatile. For example, in a single new() call I could pass separate someValue arguments to each constructor, which is impossible to do in C++ without workarounds (allocate an array of pointers to objects, and manually allocate each object).
You are wrong. Google "placement new". Also have a look at C++11 and ponder what can be done with perfect forwarding and vararg templates. Or ponder no longer and have a look at the various "emplace" methods in C++11 STL containers.
Your example is not convincing. You have a whole page of ugly incantations where I'd have a handful of lines of C++ code to do the exact same thing, with no macro involved.
MyEmail {l Wrote}:I could even call different constructors AND use different parameters for each in a single new() call--try and do that in C++.
By that logic, I can do absolutely anything in C++ in one line of code (which calls a function).
MyEmail {l Wrote}:The unimaginably great potential found in this basic example alone shows just useful it is.
lol
MyEmail {l Wrote}:In fact, I would argue it is easier to debug than C++ code. Consider this example: Each and every function (including constructors) have a unique identifier because its required in C. This means you know exactly what constructor/function is being called, whereas in C++ function mismatching can happen all the time because it does not require unique identifiers--you could accidentally be calling the wrong constructor because of a inline conversion operator, or the countless other situations where this could occur. On the flip side of the coin in my C+Scheme hybrid this will never happen.
You are wrong. Google "C++ name mangling".
