next »

[oahda]

Oh, I thought compilers basically ignore those these days and inline even without a specifier when they can and don't even with the keyword when they can't. But maybe MVSC respects that custom one? o:

[JWki]

The standard inline keyword doesn't give you any guarantees but __forceinline in MSVC is supposed to actually force the inlining.
I'm not sure when it comes to Clang and GCC - in theory there's __attribute__((always_inline)). That should achieve the same.

I'd be VERY surprised if compilers would ignore the built in specifiers because those are supposed to give the user the ability to say "trust me on this, compiler, I want it to be inlined", because there's cases where you really really want that.
Like in my case where I just want some syntactic sugar basically. In this specific case the compiler is very likely to inline the call anyways though.

[oahda]

If the built-in keyword is more or less deprecated anyway, yet compilers have attributes to force inline, they should just use the actual keyword to do it so that the language is more consistent and doesn't need all those ugly macros, then.

[JWki]

That would break a lot of backwards compatibility though. Imagine all the codebases that uses the inline keyword compiling with a compiler that has that keyword set to actually force inlining, that would cause a lot of trouble potentially.

[oahda]

I guess.

[Garthy]

Whilst 'inline' (in C++ at least) serves only as a compiler hint nowadays for inlining, it also carries additional significance in the language. One is essentially that multiple declarations of the same function are acceptable (this is a simplification). Of course, compiler hinting is still a very useful thing to be able to do.

The conflict comes in when a compiler has determined that inlining something will actually make things worse. So, many compilers treat "inline" as a hint that it can ignore. This is of course a problem if you've examined a bit of code in detail and you know that it absolutely *must* be inlined (eg. for specific timing or race-avoidance reasons). Then, "inline" is no longer sufficient. This is where the various compiler extensions come in- ways to tell the compiler that yes, you really do want this function to be inline. As the language hasn't kept up, you get various solutions layered on top of that to plug in the required compiler-specific code to force inlining.

Personally, I'd go for an extension like "dammit" after "inline" which is mandated by the standard to force inlining no matter what. Then, if a compiler decides it is too clever for you and that you really meant something else, you can turn around and say that it is a non-conforming compiler.

[JWki]

I'm a happy programmer because I've written my first working piece of low level audio code!
It loads and decodes a .ogg file and streams it through the default output device in a loop!

Unfortunately my quick and dirty try to play with steam audio and apply some effects to my sound doesn't seem to work too well.

[oahda]

Standardised inline dammit would be neat!

Ah, low-level audio. Still something I haven't dared touch yet, but I suspect it opens up for creative freedom with audio the way shaders and custom rendering pipelines open up creative freedom with graphics, so perhaps I should dare investigate...

[JWki]

Standardised inline dammit would be neat!

Ah, low-level audio. Still something I haven't dared touch yet, but I suspect it opens up for creative freedom with audio the way shaders and custom rendering pipelines open up creative freedom with graphics, so perhaps I should dare investigate...

Also opens up for permanently damaging your hearing when not being careful while testing. But yeah I think it's quite interesting. Looking forward to doing my own mixer with dsp/fx support.

[oahda]

True, a graphical bug won't damage one's sight as monitors only get so bright, but an auditory one on sound equipment that can reach very loud volumes...

[Sik]

Graphics can hurt you by flashing (which in turn can both tire your eyes and outright give you seizures, which themselves are really dangerous).

Anyway, isn't one of the side effects of inline that you can't take the address of the function? Forgot if that's the case, but if so it can be a good way to ensure certain functions can't be used as callbacks. These days I normally use inline where I'd use a macro (unless it's for messing with the code structure itself).

[Schrompf]

If you take the address of a function, the compiler makes sure to include a callable version in the executable. This doesn't affect inlining in any way.

Seriously: trust the compiler. Chances are it's way smarter than you. Most of the time.

[JWki]

If you take the address of a function, the compiler makes sure to include a callable version in the executable. This doesn't affect inlining in any way.

Seriously: trust the compiler. Chances are it's way smarter than you. Most of the time.

Except for sometimes

[pelle]

Speaking of that, has this c++ game on c64 video been posted here (in the unlikely event that not everyone here saw it already anyway)? Really amazing what the compilers can do these days yes.

[JWki]

Max width is 885, so this does the trick:

Code:

[img width=885]…[/img]

Looks cool! Emscripten is a lot of fun. Bit of a Frankenstein creation with some of the interface in HTML and some in cross-compiled C(++)! p: Are you doing that in order to be able to tie it into your thesis somehow, or is it just for fun any way? Going to be using it for anything particular?


My interface is coming along too! I've implemented full docking functionality into ImGuiDock, but I then noticed resizing views was buggy, and trying to fix it wasn't so simple based on the weird way the views and subviews have been implemented by the original author, so I'm going to rewrite the entire foundation of it as well, really leaving nothing of the original library's code in the end, so I guess it'll be my own work from scratch after all, heh.

...did that gif have the platform windows when you first posted it? Oo
I just went back to quote this to ask how this was coming along :D

[oahda]

Yep, it did!

Here's the last update on the progress since I started reprogramming my own from scratch as it was too much work trying to hack someone else's code:
https://twitter.com/avaskoog/status/825444287454265349

It's basically done, but I believe there are a few issues left that I need to fix that I just don't remember right now since it's been a while since I last worked on it. Not seen in the GIF is that it also undocks to separate windows. Currently, and by default, only to ImGui windows, but I've written the code so that it's easy to override with a custom implementation, so I'll be adding SDL windows again at some point.

One thing I thought I'd like to have that's missing... Views that look like they might be aligned don't always actually resize together with the same bar since they're in fact subviews of different ones, that only happen to have been resized to align exactly. But then I looked into other programs with docks, like Unity, and it seems they don't deal with this either, so maybe I don't need to fix that? Is that usually fixed? I hadn't really thought about it before I started making my own...

[JWki]

Ah I see.
I'm curious as to how you're handling ImGui contexts - I assume there's a context per platform window?
I'm in the process of designing my own version atm and the core problem that I don't know yet how I want to solve it is how to associate a view with the corresponding content calls - using std::function would be a quick solution but I'm trying to look into different approaches.

[oahda]

Yeah, one context per window. They all share the same OpenGL context, however.

My views currently support both std::function callbacks for quick things (mostly for testing, I guess) and inheritance for more complex views where I'd like to group data and so on.

[JWki]

Yeah that sounds like a good working approach.

I was thinking about having command lists per view that would map to the corresponding imgui calls to get rid of any virtual dispatch but that would limit the expressiveness of the imgui API and for tool UI virtual dispatch won't be that much of an issue.

[oahda]

Yeah, I feel like this is one of the main applications where the traditional OOP approach is perfectly fine.