3 ms·

Hah. Voldemort types. The ones that can't be named (in practice becouse too long to fit on a line or remember)?

gpderetta 3y ago
Also because they might be a) an undocumented implementation detail (the result of std::bind for example); b) utterly unutterable like the type of a lambda expression.
masklinn 3y ago
> The ones that can't be named (in practice becouse too long to fit on a line or remember)? Nah those are easy to name, just annoying, it's types which literally don't have an external / public name, like lambdas, or locally defined types.
bheadmaster 3y ago
It's actually a struct that only has a name in the scope of the function which returns `auto`, and thus cannot be named outside of it. Like this: #include <iostream> auto createVoldemortType(int value) { struct Voldemort { int value; }; return Voldemort{value}; } int main() { auto voldemort = createVoldemortType(7); std::cout << voldemort.value << std::endl; // output: 7 }
- krater23 3y ago
  This way to code is a good reason to make auto the same tabu as goto.
- trealira 3y ago
  I wonder how much this complicates parsing C++. Because of this, you can't discard/free struct and class definitions as soon as you leave the scope, like you can in C, because the definition can still escape the scope by being returned from a function with the "auto" keyword.
  - humanrebar 3y ago
    The entities and their destructors still have names that the compiler and linker understand. Programs just can't name them.
    - trealira 3y ago
      I mean that it would complicate just the parser. For many compilers, as soon as the parser sees a left curly brace, it pushes a symbol table onto a stack, and when it sees the corresponding right curly brace, it pops the symbol table off the stack, and "forgets" any declarations that were made inside that scope. That is so things like this work as expected. { int x = 0; { int x = 1; printf("%d\n", x); // prints 1 } printf("%d\n", x); // prints 0 } But, in C++, using the auto keyword, declarations can escape their scope with auto. I'll change the C++ code that OP wrote. The C++ compiler has to correctly resolve cases like this, which means it can't just forget all the declarations within the scope of the function after the definition is done. #include <iostream> auto createVoldemortType(int value) { struct Voldemort { int value; }; return Voldemort{value}; } struct Voldemort { std::string value; }; int main() { auto voldemort = createVoldemortType(7); std::cout << voldemort.value << std::endl; // output: 7 }
      - danhau 3y ago
        During semantic analysis a parser usually attaches symbol info (of some kind) to the already existing abstract syntax tree, or creates a new tree entirely. Whenever it needs to know about a type, it just walks the tree to the node with the type definition. That way there’s really never any data that‘s forgotten. At least that’s how I think the parsers work I‘m familiar with.
        trealira 3y ago
        Yeah, it depends on the compiler. I've read a book about a BLISS compiler [1] that does this, but still uses a stack like I described [2]. It implements a hash table that used linked list nodes for collision. A new declaration adds a new name to the table, and it attaches the node to uses of the name in expressions of the syntax tree. When a scope is exited, the declarations from that scope are removed from the symbol table, but because they're still attached to the syntax tree, they can't just be freed. They're added to a linked list of "purged" nodes, so that the information they contain can be used later during code generation, and then freed. One-pass compilers don't have this problem; they really can just free the memory for reuse, because after they exit a scope, they've already generated the assembly or machine code from the high-level language. However, I don't know what LLVM or GCC, or any other remotely modern compiler, does. I haven't read the code much. [1]: https://en.wikipedia.org/wiki/The_Design_of_an_Optimizing_Compiler https://en.wikipedia.org/wiki/The_Design_of_an_Optimizing_Co... [2]: Actually, it intertwines the stack and the symbol table in a complicated way, so there's only one hash table, and multiple stacks within it. It's explained by a diagram they include on page 13. You can find a PDF of it here: https://kilthub.cmu.edu/articles/journal_contribution/The_design_of_an_optimizing_compiler/6610535 https://kilthub.cmu.edu/articles/journal_contribution/The_de...
- fuzztester 3y ago
  How does the argument 7 get passed to the value field in the Voldemort struct? I don't see any code ther that does that. Is it implicitly passed? I don't know C++, though I did know C somewhat well earlier.
  - fuzztester 3y ago
    Oops, I missed the line: return Voldemort{value}; I guess that does it.
fuzztester 3y ago
>Hah. Voldemort types. The ones that can't be named Ha ha, that reminds me of that phrase of yore, "the quality without a name (qwan)" (google it), which was heavily bandied about years ago, during the heyday of C++ and the software patterns movement (which continued a lot in the days of Java, of course). James Coplien (IIRC) and others of that time come to mind. https://en.m.wikipedia.org/wiki/The_Timeless_Way_of_Building https://en.m.wikipedia.org/wiki/The_Timeless_Way_of_Building https://en.m.wikipedia.org/wiki/Pattern_language https://en.m.wikipedia.org/wiki/Pattern_language https://en.m.wikipedia.org/wiki/Jim_Coplien https://en.m.wikipedia.org/wiki/Jim_Coplien Though I read a fair amount about that stuff, a lot of of it went over my head, but later, I did understand some of the patterns, after reading the design patterns book, and trying out some of them. The template method pattern is my favourite pattern, because I understand it more well than many of the others :), and also because it is the basis of software frameworks (inversion of control, aka the Hollywood principle - "don't call me, I'll call you"). Other patterns that I like and understand are the command pattern, the interpreter pattern, the chain of responsibility pattern, and flyweight pattern, to name a few. Builder and Factory, not so much. Singleton is straightforward, or is it really? impls matter :) And I have written a few toy frameworks, which is fun to do and use.

Also because they might be a) an undocumented implementation detail (the result of std::bind for example); b) utterly unutterable like the type of a lambda expression.

masklinn 3y ago

> The ones that can't be named (in practice becouse too long to fit on a line or remember)? Nah those are easy to name, just annoying, it's types which literally don't have an external / public name, like lambdas, or locally defined types.

bheadmaster 3y ago

It's actually a struct that only has a name in the scope of the function which returns `auto`, and thus cannot be named outside of it. Like this: #include <iostream> auto createVoldemortType(int value) { struct Voldemort { int value; }; return Voldemort{value}; } int main() { auto voldemort = createVoldemortType(7); std::cout << voldemort.value << std::endl; // output: 7 }

krater23 3y ago
This way to code is a good reason to make auto the same tabu as goto.
trealira 3y ago
I wonder how much this complicates parsing C++. Because of this, you can't discard/free struct and class definitions as soon as you leave the scope, like you can in C, because the definition can still escape the scope by being returned from a function with the "auto" keyword.
- humanrebar 3y ago
  The entities and their destructors still have names that the compiler and linker understand. Programs just can't name them.
  - trealira 3y ago
    I mean that it would complicate just the parser. For many compilers, as soon as the parser sees a left curly brace, it pushes a symbol table onto a stack, and when it sees the corresponding right curly brace, it pops the symbol table off the stack, and "forgets" any declarations that were made inside that scope. That is so things like this work as expected. { int x = 0; { int x = 1; printf("%d\n", x); // prints 1 } printf("%d\n", x); // prints 0 } But, in C++, using the auto keyword, declarations can escape their scope with auto. I'll change the C++ code that OP wrote. The C++ compiler has to correctly resolve cases like this, which means it can't just forget all the declarations within the scope of the function after the definition is done. #include <iostream> auto createVoldemortType(int value) { struct Voldemort { int value; }; return Voldemort{value}; } struct Voldemort { std::string value; }; int main() { auto voldemort = createVoldemortType(7); std::cout << voldemort.value << std::endl; // output: 7 }
    - danhau 3y ago
      During semantic analysis a parser usually attaches symbol info (of some kind) to the already existing abstract syntax tree, or creates a new tree entirely. Whenever it needs to know about a type, it just walks the tree to the node with the type definition. That way there’s really never any data that‘s forgotten. At least that’s how I think the parsers work I‘m familiar with.
      - trealira 3y ago
        Yeah, it depends on the compiler. I've read a book about a BLISS compiler [1] that does this, but still uses a stack like I described [2]. It implements a hash table that used linked list nodes for collision. A new declaration adds a new name to the table, and it attaches the node to uses of the name in expressions of the syntax tree. When a scope is exited, the declarations from that scope are removed from the symbol table, but because they're still attached to the syntax tree, they can't just be freed. They're added to a linked list of "purged" nodes, so that the information they contain can be used later during code generation, and then freed. One-pass compilers don't have this problem; they really can just free the memory for reuse, because after they exit a scope, they've already generated the assembly or machine code from the high-level language. However, I don't know what LLVM or GCC, or any other remotely modern compiler, does. I haven't read the code much. [1]: https://en.wikipedia.org/wiki/The_Design_of_an_Optimizing_Compiler https://en.wikipedia.org/wiki/The_Design_of_an_Optimizing_Co... [2]: Actually, it intertwines the stack and the symbol table in a complicated way, so there's only one hash table, and multiple stacks within it. It's explained by a diagram they include on page 13. You can find a PDF of it here: https://kilthub.cmu.edu/articles/journal_contribution/The_design_of_an_optimizing_compiler/6610535 https://kilthub.cmu.edu/articles/journal_contribution/The_de...
fuzztester 3y ago
How does the argument 7 get passed to the value field in the Voldemort struct? I don't see any code ther that does that. Is it implicitly passed? I don't know C++, though I did know C somewhat well earlier.
- fuzztester 3y ago
  Oops, I missed the line: return Voldemort{value}; I guess that does it.

fuzztester 3y ago

>Hah. Voldemort types. The ones that can't be named Ha ha, that reminds me of that phrase of yore, "the quality without a name (qwan)" (google it), which was heavily bandied about years ago, during the heyday of C++ and the software patterns movement (which continued a lot in the days of Java, of course). James Coplien (IIRC) and others of that time come to mind. https://en.m.wikipedia.org/wiki/The_Timeless_Way_of_Building https://en.m.wikipedia.org/wiki/The_Timeless_Way_of_Building https://en.m.wikipedia.org/wiki/Pattern_language https://en.m.wikipedia.org/wiki/Pattern_language https://en.m.wikipedia.org/wiki/Jim_Coplien https://en.m.wikipedia.org/wiki/Jim_Coplien Though I read a fair amount about that stuff, a lot of of it went over my head, but later, I did understand some of the patterns, after reading the design patterns book, and trying out some of them. The template method pattern is my favourite pattern, because I understand it more well than many of the others :), and also because it is the basis of software frameworks (inversion of control, aka the Hollywood principle - "don't call me, I'll call you"). Other patterns that I like and understand are the command pattern, the interpreter pattern, the chain of responsibility pattern, and flyweight pattern, to name a few. Builder and Factory, not so much. Singleton is straightforward, or is it really? impls matter :) And I have written a few toy frameworks, which is fun to do and use.