5 ms·
Yes, I mean java.util.LinkedList. Obviously, one can do manual writing of Java (or even use m4 macros or hijack the C preprocessor... the preprocessor doesn't
by KMag 6y ago
Yes, I mean java.util.LinkedList. Obviously, one can do manual writing of Java (or even use m4 macros or hijack the C preprocessor... the preprocessor doesn't know anything about C beyond tokenization) for anything C++ templates can do. It's just tedious and potentially error-prone. Here's hoping Java eventually gets reified generics.
- MaxBarraclough 6y ago> can do manual writing of Java (or even use m4 macros or hijack the C preprocessor... the preprocessor doesn't know anything about C beyond tokenization) for anything C++ templates can do Sounds broadly true, but I'm not sure it's precisely right. How could std::is_same be implemented?
- KMag 6y ago> How could std::is_same be implemented? You would perform manual static context-sensitive text expansion, just like the C++ template expander does. In this case, you end up just manually expanding it all the way out to a true or false by hand. I'm just saying that the C++ template expander only performs static context-sensitive text replacements, ending in valid template-free C++ code. The template engine doesn't introduce any magic that can't be done more tediously in template-free C++ by hand, so you can do the same tricks in Java by hand. Now, Java doesn't have non-primitive value types, so you'd have to manually flatten some classes in order to get the same layout without the class boundary forcing an indirection. Java also doesn't allow interior references while C++ absolutely does, but that's outside the C++ template expander / template sub-language.
- gpderetta 6y agoC++ templates cannot be implemented purely by text replacement as most of it is type driven. It is true that you can do anything that templates do by hand, but that's true for any language construct (at the limit you could write asm).
- KMag 6y ago> C++ templates cannot be implemented purely by text replacement as most of it is type driven. The static types (and constant values in some cases) are the context. That's the "context-sensitive" part of "context-sensitive expansion". > It is true that you can do anything that templates do by hand, but that's true for any language construct (at the limit you could write asm). Yes. That's my point. I was replying to someone saying that they could remove a layer of indirection from a linked list by writing a custom data structure that had the next and previous references, and I was pointing out that they're essentially running C++ template expansion by hand. There's nothing surprising there.
- MaxBarraclough 6y ago> You would perform manual static context-sensitive text expansion, just like the C++ template expander does. Sure, if you move all your code into your new language that transpiles to C, but that was my point, the lack of language integration means there's plenty it can't do that C++ templates can do. An example from [0]: std::is_same_v<int, std::int64_t> In C, I don't know that there's any way to determine whether int and int64_t are the same type. [0] https://en.cppreference.com/w/cpp/types/is_same https://en.cppreference.com/w/cpp/types/is_same
- deleted 6y ago[deleted]
- xxs 6y agoObviously you can do public class Node<T>{ Node prev, next; //stuff comes here .... } Then extend and have the overall code that deals with modifying the datastructure, but it's overall ugly. Personally I have written enough datastructures where linking nodes is useful. For example: red/black tree + insert order 'next' makes for a decent implementation of a moving median. Yet, that's not what almost any developer would do normally.
- KMag 6y agoBut isn't that just what you were suggesting in the GP post in order to get rid of a layer of indirection?
- xxs 6y agoPerhaps, most of the time I have not created a general use data structure - just highly specialized ones. Extending would allow no references/indirection but it's rather ugly and it has to provide another function to instantiate (I'd consider reflection, i.e. Class.newInstance() not to be a good way to handle the case).