Crimsontide
|
|
« Reply #5440 on: August 26, 2017, 04:24:00 PM » |
|
Ideally a language would provide some fundamental primitives that can be used to express whatever the user wants. Users really like encapsulation, but not necessary on an object-object basis. Users really like polymorphism, but not necessarily on a class to class basis, and not necessarily tied into C++-style inheritence. Users really like code-generation for compile-time polymorphism, but not necessarily in the form of C++ templates, which pollute translation units with codegen spam. Ideally users can express strict memory patterns across their statements and expressions (like the above examples), but not necessarily in the form of C++ deep copies or other OOP-ey messes.
What primitives would you propose?
|
|
|
Logged
|
|
|
|
qMopey
|
|
« Reply #5441 on: August 27, 2017, 02:14:42 PM » |
|
I haven't done much language design study. Try focusing on defining new types. Try to break down the separation between compiler-supported types and user defined types. Maybe like a data file can be read by the compiler to install a new type of data, and all type primitives (including the default ones that come packaged with the compiler) are defined in this format. It would be sweet if these data types could be defined in-code, sort of like a .c header.
|
|
|
Logged
|
|
|
|
Crimsontide
|
|
« Reply #5442 on: August 27, 2017, 04:43:49 PM » |
|
I haven't done much language design study. Try focusing on defining new types. Try to break down the separation between compiler-supported types and user defined types. Maybe like a data file can be read by the compiler to install a new type of data, and all type primitives (including the default ones that come packaged with the compiler) are defined in this format. It would be sweet if these data types could be defined in-code, sort of like a .c header. How do you envision that being different than say a struct with some operator overloads?
|
|
|
Logged
|
|
|
|
|
Tycho Brahe
|
|
« Reply #5444 on: August 28, 2017, 09:24:17 AM » |
|
Isn't this exactly where things like metaprogramming come in? For example a tool like Eigen that applies template metaprogramming to optimise and simplify linear algebraic operations: http://eigen.tuxfamily.org/index.php?title=Main_PageYou will always eventually need to copy memory - the question is when, and how you describe that move. If you use metaprogramming where a function call isn't *actually* a function call, but a templated macro, you can attach more domain knowledge that the compiler can use to generate an optimised version of the code that you want.
|
|
|
Logged
|
|
|
|
JWki
|
|
« Reply #5445 on: August 28, 2017, 09:33:26 AM » |
|
Isn't this exactly where things like metaprogramming come in? For example a tool like Eigen that applies template metaprogramming to optimise and simplify linear algebraic operations: http://eigen.tuxfamily.org/index.php?title=Main_PageYou will always eventually need to copy memory - the question is when, and how you describe that move. If you use metaprogramming where a function call isn't *actually* a function call, but a templated macro, you can attach more domain knowledge that the compiler can use to generate an optimised version of the code that you want. At the cost of being close to impossible to debug and reason about. C++ templates weren't designed to be used for metaprogramming from the get go and it shows.
|
|
|
Logged
|
|
|
|
Garthy
|
|
« Reply #5446 on: August 28, 2017, 02:41:07 PM » |
|
At the cost of being close to impossible to debug and reason about. C++ templates weren't designed to be used for metaprogramming from the get go and it shows.
To be available in C++55, after we've gone through a few more iterations and we finally get honest about the fact that people are wanting to do things with the language that require a real metaprogramming support langauge. In the meantime I just use scripting (eg. Ruby) in my own projects to produce code when the meta goes into metastasis. Externally sometimes, or embedded in the code itself and managed by a tool. I use the simpler template stuff frequently, but only delve into the hairier template stuff when it's paying my rent. Templates have been stretched far beyond what they were usefully designed for. I think it confirms a need for something more powerful.
|
|
|
Logged
|
|
|
|
InfiniteStateMachine
|
|
« Reply #5447 on: August 28, 2017, 04:44:35 PM » |
|
Isn't this exactly where things like metaprogramming come in? For example a tool like Eigen that applies template metaprogramming to optimise and simplify linear algebraic operations: http://eigen.tuxfamily.org/index.php?title=Main_PageYou will always eventually need to copy memory - the question is when, and how you describe that move. If you use metaprogramming where a function call isn't *actually* a function call, but a templated macro, you can attach more domain knowledge that the compiler can use to generate an optimised version of the code that you want.
Templates have been stretched far beyond what they were usefully designed for. I think it confirms a need for something more powerful.
See my link in the above post. One of the goals of that paper is to have a more formal way to do that without abusing templates. One of the examples is how to eliminate Qt's moc stuff using this method. I do not enjoy getting bugs where I have to reverse engineer some template madness written by someone who no longer works with me.
|
|
|
Logged
|
|
|
|
InfiniteStateMachine
|
|
« Reply #5448 on: August 28, 2017, 04:49:02 PM » |
|
Another option is to start looking at languages like D where static code generation was a concern in the design from day 1.
|
|
|
Logged
|
|
|
|
Garthy
|
|
« Reply #5449 on: August 28, 2017, 05:17:06 PM » |
|
Templates have been stretched far beyond what they were usefully designed for. I think it confirms a need for something more powerful.
See my link in the above post. One of the goals of that paper is to have a more formal way to do that without abusing templates. One of the examples is how to eliminate Qt's moc stuff using this method. Thankyou for directing me to the link you posted earlier. I had not read it before, but I've now read the intro and skimmed the rest. This would be a positive direction to head in. Not exactly the way I'd approach it myself, but I'd still be cheering it on. As long as they're careful with opacity issues (ie. it doesn't produce something harder to diagnose than templates) I can see something like this catching on and becoming popular.
|
|
|
Logged
|
|
|
|
InfiniteStateMachine
|
|
« Reply #5450 on: August 29, 2017, 06:48:36 AM » |
|
Yeah I'm both interested and fearful of the implications.
One of my bigger fears would be keyword collision from multiple libraries.
|
|
|
Logged
|
|
|
|
Ordnas
|
|
« Reply #5451 on: August 29, 2017, 11:59:02 PM » |
|
If C++ will introduce template constraints and static if, it would be at the same level of D (aside from the not-understandable error messages)?
|
|
|
Logged
|
Games:
|
|
|
Schrompf
|
|
« Reply #5452 on: August 30, 2017, 02:39:27 AM » |
|
And static if is already there, since C++17.
|
|
|
Logged
|
Snake World, multiplayer worm eats stuff and grows DevLog
|
|
|
JWki
|
|
« Reply #5453 on: September 01, 2017, 01:17:33 AM » |
|
still fucking about with FBX importing, getting inconsistent behaviours out of what I thought was correct code. unsure whether I'm just missing something that has to be configured depending on the file being imported or whether my code is actually not correct yet.
|
|
|
Logged
|
|
|
|
InfiniteStateMachine
|
|
« Reply #5454 on: September 01, 2017, 05:59:38 AM » |
|
That sounds about right, FBX is so wonky.
|
|
|
Logged
|
|
|
|
JWki
|
|
« Reply #5455 on: September 01, 2017, 01:04:18 PM » |
|
That sounds about right, FBX is so wonky.
Yeah kinda but well it also kinda works - Blender can import the stuff I'm having issues with just fine so it's certainly doable.
|
|
|
Logged
|
|
|
|
Garthy
|
|
« Reply #5456 on: September 01, 2017, 02:37:16 PM » |
|
That sounds about right, FBX is so wonky.
Yeah kinda but well it also kinda works - Blender can import the stuff I'm having issues with just fine so it's certainly doable. Every 3D format that contains any kind of animation information is bad. Really, really bad. The tools that export that information aren't that much better. Any reliable importer is filled with workarounds to deal with broken functionality, and flaws in the original tool/exporter can't be fixed without breaking existing importers, not that the people producing the software that make those models give a damn anyway, they already have your money. The burden gets pushed out to the tools that deal will all this rubbish output. If you can pull out something from this cesspit that even vaguely resembles the original model, you're already doing a damn fine job.
|
|
|
Logged
|
|
|
|
JWki
|
|
« Reply #5457 on: September 02, 2017, 12:35:04 AM » |
|
That sounds about right, FBX is so wonky.
Yeah kinda but well it also kinda works - Blender can import the stuff I'm having issues with just fine so it's certainly doable. Every 3D format that contains any kind of animation information is bad. Really, really bad. The tools that export that information aren't that much better. Any reliable importer is filled with workarounds to deal with broken functionality, and flaws in the original tool/exporter can't be fixed without breaking existing importers, not that the people producing the software that make those models give a damn anyway, they already have your money. The burden gets pushed out to the tools that deal will all this rubbish output. If you can pull out something from this cesspit that even vaguely resembles the original model, you're already doing a damn fine job. TBF OpenFBX is doing a damn fine job rather than me. Anyhow FBX being the primary exchange format being used in the industry (yay for lobby work, gj Autodesk) I'm still pretty certain that the baseline of "this kinda works" is still somewhat higher than what I have atm. Might also look into OpenGEX at some point, and maybe glTF.
|
|
|
Logged
|
|
|
|
ferreiradaselva
|
|
« Reply #5458 on: September 09, 2017, 05:49:16 PM » |
|
I hate to write this kind of code: static void get_graphics_state(void) { GLfloat value_GL_COLOR_CLEAR_VALUE[4]; GLdouble value_GL_DEPTH_CLEAR_VALUE; GLint value_GL_BLEND_SRC_RGB; GLint value_GL_BLEND_SRC_ALPHA; GLint value_GL_BLEND_DST_RGB; GLint value_GL_BLEND_DST_ALPHA; GLint value_GL_BLEND_EQUATION_RGB; GLint value_GL_BLEND_EQUATION_ALPHA; GLfloat value_GL_BLEND_COLOR[4]; GLint value_GL_LOGIC_OP_MODE; GLint value_GL_CULL_FACE_MODE; GLint value_GL_FRONT_FACE; GLdouble value_GL_DEPTH_RANGE[2]; /* Clear color */ default_program.graphics_state.clear.color.enable = true; glGetFloatv(GL_COLOR_CLEAR_VALUE, &value_GL_COLOR_CLEAR_VALUE); default_program.graphics_state.clear.color.r = 0.0f; default_program.graphics_state.clear.color.g = 0.0f; default_program.graphics_state.clear.color.b = 0.0f; default_program.graphics_state.clear.color.a = 1.0f; /* Clear depth */ glGetDoublev(GL_DEPTH_CLEAR_VALUE, &value_GL_DEPTH_CLEAR_VALUE); default_program.graphics_state.clear.depth.enable = true; default_program.graphics_state.clear.depth.value = value_GL_DEPTH_CLEAR_VALUE; /* Blend */ glGetIntegerv(GL_BLEND_SRC_RGB, &value_GL_BLEND_SRC_RGB); glGetIntegerv(GL_BLEND_SRC_ALPHA, &value_GL_BLEND_SRC_ALPHA); glGetIntegerv(GL_BLEND_DST_RGB, &value_GL_BLEND_DST_RGB); glGetIntegerv(GL_BLEND_DST_ALPHA, &value_GL_BLEND_DST_ALPHA); glGetIntegerv(GL_BLEND_EQUATION_RGB, &value_GL_BLEND_EQUATION_RGB); glGetIntegerv(GL_BLEND_EQUATION_ALPHA, &value_GL_BLEND_EQUATION_ALPHA); glGetFloatv(GL_BLEND_COLOR, &value_GL_BLEND_COLOR); default_program.graphics_state.blend.enable = glIsEnabled(GL_BLEND); default_program.graphics_state.blend.function.source_rgb = value_GL_BLEND_SRC_RGB; default_program.graphics_state.blend.function.destination_rgb = value_GL_BLEND_SRC_ALPHA; default_program.graphics_state.blend.function.source_alpha = value_GL_BLEND_DST_RGB; default_program.graphics_state.blend.function.destination_alpha = value_GL_BLEND_DST_ALPHA; default_program.graphics_state.blend.equation.mode_rgb = value_GL_BLEND_EQUATION_RGB; default_program.graphics_state.blend.equation.mode_alpha = value_GL_BLEND_EQUATION_ALPHA; default_program.graphics_state.blend.color.r = value_GL_BLEND_COLOR[0]; default_program.graphics_state.blend.color.g = value_GL_BLEND_COLOR[1]; default_program.graphics_state.blend.color.b = value_GL_BLEND_COLOR[2]; default_program.graphics_state.blend.color.a = value_GL_BLEND_COLOR[3]; /* Color logic operation */ glGetIntegerv(GL_LOGIC_OP_MODE, &value_GL_LOGIC_OP_MODE); default_program.graphics_state.color_logic_operation.enable = glIsEnabled(GL_COLOR_LOGIC_OP); default_program.graphics_state.color_logic_operation.logic_operation = value_GL_LOGIC_OP_MODE; /* Face culling */ glGetIntegerv(GL_CULL_FACE_MODE, &value_GL_CULL_FACE_MODE); glGetIntegerv(GL_FRONT_FACE, &value_GL_FRONT_FACE); default_program.graphics_state.cull_face.enable = glIsEnabled(GL_CULL_FACE); default_program.graphics_state.cull_face.mode = value_GL_CULL_FACE_MODE; default_program.graphics_state.cull_face.front = value_GL_FRONT_FACE; /* Depth */ glGetDoublev(GL_DEPTH_RANGE, &value_GL_DEPTH_RANGE); default_program.graphics_state.depth.enable = glIsEnabled(GL_DEPTH_TEST); default_program.graphics_state.depth.function = TEST_FUNCTION_LESS; default_program.graphics_state.depth.near = value_GL_DEPTH_RANGE[0]; default_program.graphics_state.depth.far = value_GL_DEPTH_RANGE[1]; default_program.graphics_state.depth.clamp = glIsEnabled(GL_DEPTH_CLAMP); /* Dither */ default_program.graphics_state.dither.enable = glIsEnabled(GL_DITHER); }
It's just grabbing some OpenGL states, but it's just the kind of code that is annoying to write.
|
|
|
Logged
|
|
|
|
JWki
|
|
« Reply #5459 on: September 10, 2017, 02:33:57 AM » |
|
I hate to write this kind of code: static void get_graphics_state(void) { GLfloat value_GL_COLOR_CLEAR_VALUE[4]; GLdouble value_GL_DEPTH_CLEAR_VALUE; GLint value_GL_BLEND_SRC_RGB; GLint value_GL_BLEND_SRC_ALPHA; GLint value_GL_BLEND_DST_RGB; GLint value_GL_BLEND_DST_ALPHA; GLint value_GL_BLEND_EQUATION_RGB; GLint value_GL_BLEND_EQUATION_ALPHA; GLfloat value_GL_BLEND_COLOR[4]; GLint value_GL_LOGIC_OP_MODE; GLint value_GL_CULL_FACE_MODE; GLint value_GL_FRONT_FACE; GLdouble value_GL_DEPTH_RANGE[2]; /* Clear color */ default_program.graphics_state.clear.color.enable = true; glGetFloatv(GL_COLOR_CLEAR_VALUE, &value_GL_COLOR_CLEAR_VALUE); default_program.graphics_state.clear.color.r = 0.0f; default_program.graphics_state.clear.color.g = 0.0f; default_program.graphics_state.clear.color.b = 0.0f; default_program.graphics_state.clear.color.a = 1.0f; /* Clear depth */ glGetDoublev(GL_DEPTH_CLEAR_VALUE, &value_GL_DEPTH_CLEAR_VALUE); default_program.graphics_state.clear.depth.enable = true; default_program.graphics_state.clear.depth.value = value_GL_DEPTH_CLEAR_VALUE; /* Blend */ glGetIntegerv(GL_BLEND_SRC_RGB, &value_GL_BLEND_SRC_RGB); glGetIntegerv(GL_BLEND_SRC_ALPHA, &value_GL_BLEND_SRC_ALPHA); glGetIntegerv(GL_BLEND_DST_RGB, &value_GL_BLEND_DST_RGB); glGetIntegerv(GL_BLEND_DST_ALPHA, &value_GL_BLEND_DST_ALPHA); glGetIntegerv(GL_BLEND_EQUATION_RGB, &value_GL_BLEND_EQUATION_RGB); glGetIntegerv(GL_BLEND_EQUATION_ALPHA, &value_GL_BLEND_EQUATION_ALPHA); glGetFloatv(GL_BLEND_COLOR, &value_GL_BLEND_COLOR); default_program.graphics_state.blend.enable = glIsEnabled(GL_BLEND); default_program.graphics_state.blend.function.source_rgb = value_GL_BLEND_SRC_RGB; default_program.graphics_state.blend.function.destination_rgb = value_GL_BLEND_SRC_ALPHA; default_program.graphics_state.blend.function.source_alpha = value_GL_BLEND_DST_RGB; default_program.graphics_state.blend.function.destination_alpha = value_GL_BLEND_DST_ALPHA; default_program.graphics_state.blend.equation.mode_rgb = value_GL_BLEND_EQUATION_RGB; default_program.graphics_state.blend.equation.mode_alpha = value_GL_BLEND_EQUATION_ALPHA; default_program.graphics_state.blend.color.r = value_GL_BLEND_COLOR[0]; default_program.graphics_state.blend.color.g = value_GL_BLEND_COLOR[1]; default_program.graphics_state.blend.color.b = value_GL_BLEND_COLOR[2]; default_program.graphics_state.blend.color.a = value_GL_BLEND_COLOR[3]; /* Color logic operation */ glGetIntegerv(GL_LOGIC_OP_MODE, &value_GL_LOGIC_OP_MODE); default_program.graphics_state.color_logic_operation.enable = glIsEnabled(GL_COLOR_LOGIC_OP); default_program.graphics_state.color_logic_operation.logic_operation = value_GL_LOGIC_OP_MODE; /* Face culling */ glGetIntegerv(GL_CULL_FACE_MODE, &value_GL_CULL_FACE_MODE); glGetIntegerv(GL_FRONT_FACE, &value_GL_FRONT_FACE); default_program.graphics_state.cull_face.enable = glIsEnabled(GL_CULL_FACE); default_program.graphics_state.cull_face.mode = value_GL_CULL_FACE_MODE; default_program.graphics_state.cull_face.front = value_GL_FRONT_FACE; /* Depth */ glGetDoublev(GL_DEPTH_RANGE, &value_GL_DEPTH_RANGE); default_program.graphics_state.depth.enable = glIsEnabled(GL_DEPTH_TEST); default_program.graphics_state.depth.function = TEST_FUNCTION_LESS; default_program.graphics_state.depth.near = value_GL_DEPTH_RANGE[0]; default_program.graphics_state.depth.far = value_GL_DEPTH_RANGE[1]; default_program.graphics_state.depth.clamp = glIsEnabled(GL_DEPTH_CLAMP); /* Dither */ default_program.graphics_state.dither.enable = glIsEnabled(GL_DITHER); }
It's just grabbing some OpenGL states, but it's just the kind of code that is annoying to write. Why not set the desired values for the default program state directly instead of querying them? You can check what they are in the spec and not be dependent on nobody changing state before you call that routine. Unless you want that ability specifically.
|
|
|
Logged
|
|
|
|
|