Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411564 Posts in 69385 Topics- by 58444 Members - Latest Member: darkcitien

May 04, 2024, 03:01:27 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)The grumpy old programmer room
Pages: 1 ... 271 272 [273] 274 275 ... 295
Print
Author Topic: The grumpy old programmer room  (Read 739291 times)
Crimsontide
Level 5
*****


View Profile
« Reply #5440 on: August 26, 2017, 04:24:00 PM »

Quote
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
Level 6
*


View Profile WWW
« Reply #5441 on: August 27, 2017, 02:14:42 PM »

I haven't done much language design study.  Shrug

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
Level 5
*****


View Profile
« Reply #5442 on: August 27, 2017, 04:43:49 PM »

I haven't done much language design study.  Shrug

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
InfiniteStateMachine
Level 10
*****



View Profile
« Reply #5443 on: August 28, 2017, 06:27:21 AM »

This might be relevant although this bring a lot of power and I rue the day I have 2 third party libraries each with their own implementation of the keyword "interface".

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf
Logged

Tycho Brahe
Level 10
*****

λx.x


View Profile
« 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_Page

You 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
Level 4
****


View Profile
« 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_Page

You 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
Level 9
****


Quack, verily


View Profile WWW
« 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
Level 10
*****



View Profile
« 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_Page

You 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
Level 10
*****



View Profile
« 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
Level 9
****


Quack, verily


View Profile WWW
« 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
Level 10
*****



View Profile
« 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
Level 10
*****



View Profile WWW
« 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
Level 9
****

C++ professional, game dev sparetime


View Profile WWW
« 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
Level 4
****


View Profile
« 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
Level 10
*****



View Profile
« Reply #5454 on: September 01, 2017, 05:59:38 AM »

That sounds about right, FBX is so wonky.
Logged

JWki
Level 4
****


View Profile
« 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
Level 9
****


Quack, verily


View Profile WWW
« 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
Level 4
****


View Profile
« 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
Level 3
***



View Profile
« Reply #5458 on: September 09, 2017, 05:49:16 PM »

I hate to write this kind of code:
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
Level 4
****


View Profile
« Reply #5459 on: September 10, 2017, 02:33:57 AM »

I hate to write this kind of code:
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
Pages: 1 ... 271 272 [273] 274 275 ... 295
Print
Jump to:  

Theme orange-lt created by panic