next »

[JWki]

So I brought over some shaders from an older project of mine and got PBR and image based lighting going pretty quickly:



There's physics in there as well and some minor post processing - only tonemapping for the HDR image really - so I'm pretty happy about that but then again I'm ripping it all apart again because I have to compress the rendering code into an usable API to be able to add features again (and also because I wanna be able to hot reload rendering code). So that's what I'm doing now.

[JWK5]

JWki, I imagine we're going to confuse the hell out of a lot of people.



Also, that looks pretty interesting.

[oahda]

Heh. Yeah. It confused me already, because it said the last post was by JWK5, and then I looked, and I thought for a moment JWK5 was the one who'd posted the image.

Nice, anyhow! Can't wait to get back to work on my similar stuff now, becaaaaause...

I ordered and got the book Effective modern C++

... I finished reading this just now! Really useful book. Great read. Highly recommended. I learned or got reminded about stuff with every chapter, and told myself I should read everything before I got back to programming again, and indeed even the last few pages held some information that I definitely needed before I went and did something bad in my code again.

I also watched this talk by Bjarne himself, which contained some extra information absent from the book, such as the existence of the GSL, which contains candidate stuff for the STL but exists to make these things available now already, such as owner<T*> and not_null<T*>, which are recommended for clarity (the former has no overhead at all because it's just an alias for T*, and the latter is minimal while offering some safety).

There's also a talk by Herb Sutter I plan on watching before I throw myself back into my code.

My personal biggest takeaways (stuff I didn't know, didn't know enough about, or had forgotten) from all of this so far has been the following:

• Well-written C++14 can potentially be basically automatically faster than well-written C++98 thanks to new language mechanisms that offer greater control without sacrificing read- or managability (to name a few features: move semantics, constexpr, noexcept, "perfect" forwarding and generally greater possibilities to do things at compile-time; lambdas can also provide less overhead than traditional techniques in many contexts).
  
  
• Templates and auto are basically the same thing, and even variadic auto is possible. Also decltype(auto).
  
  
• Since C++11 the STL finally offers fixed width integer types (e.g. int32_t) and every project ever doesn't have to define its own.
  
  
• Already since C exists a syntax for defining how many bits to use, which I never knew about.
  
  
• The wonky world of move semantics, universal references and whatnot is almost making sense now, and offers some great optimisation opportunities.
  
  
• C++ is messier than ever since stuff can only be added and old stuff can't be removed. It's hideous and beautiful at the same time.

Overall: happy programmer!

[InfiniteStateMachine]

• Well-written C++14 can potentially be basically automatically faster than well-written C++98 thanks to new language mechanisms that offer greater control without sacrificing read- or managability (to name a few features: move semantics, constexpr, noexcept, "perfect" forwarding and generally greater possibilities to do things at compile-time; lambdas can also provide less overhead than traditional techniques in many contexts).
  
  

This is one thing I don't understand. How can move semantics be faster than out parameters? With out params you never even introduce the chance for a copy to occur.

constexpr I imagine you probably could have done with some template/macro ugliness as well (of course you wouldn't want to).

Noexcept though. I can't think of how you would implement that in 98.

[oahda]

Well, it's the overall combination of new features, rather than move semantics alone, that can make the potential difference. But... Out parameters may offer the same thing depending on what you're doing, but move semantics often go in the other direction; moving data onwards (emplacing stuff in a container, or moving rather than copying an rvalue argument, or forwarding arguments to a function). I'm not sure out parameters are suitable or even possible for that, at least without being a lot clunkier.

[powly]

Could you give an example on how move semantics and out parameters are even related? Not sure if I misunderstand or my C++ is really bad.

[InfiniteStateMachine]

Yeah that's a good point. I was referring to move returns when I wrote that.

I can see how trying to replicate emplace could be clunky and error prone. Same with assignments.

Could you give an example on how move semantics and out parameters are even related? Not sure if I misunderstand or my C++ is really bad.

When you build up and return a collection in a function vs creating the collection outside then passing it in by ref and populating it in the body of the function. (It's entirely possible I'm the one who is misunderstanding. At home I typically stick to C+. Modern only really comes up at work for me.).

[oahda]

That may be unnecessary and not actually an optimisation, however, if I've understood the book's advice correctly. Its exact example is this:

Code:

Widget makeWidget()
{
	Widget w;

	// … Do stuff.

	return w;
}

which the programmer may be tempted to try and optimise like so:

Code:

Widget makeWidget()
{
	Widget w;

	// … Do stuff.

	return std::move(w);
}

However, this is unnecessary and might even make the code less optimised since apparently compilers will generally make sure that the returned object, if the same as the return type and returned from the function, is constructed directly in the returned object and not copied into it. This is known as RVO (return value optimisation).

Tho of course the widget is probably stored somewhere, and that would invoke a copy or move construction on that variable if I understand correctly, so this...

Code:

auto w(makeWidget());

... would still copy or move construct w with the rvalue returned from makeWidget(), I believe, but maybe compilers optimise even that. Otherwise it's a good idea to have a move constructor that can move the rvalue into w rather than copy it.

But according to this error/warning message from clang, it looks like RVO applies even there, at least in clang?

More info: http://en.cppreference.com/w/cpp/language/copy_elision

Woop, learning even more stuff!

Don't know if this applies to a collection with heap data in it, tho... Read that page. I'm trying to right now.

[powly]

Ah yes, I was under the impression that the return values were optimized before move semantics as a special case, but that's probably not the case. I should probably pick up a copy of that Effective modern C++ myself, I haven't really read anything comprehensive on C++.. ever? At least not after C++11 was brand new.

[InfiniteStateMachine]

That may be unnecessary and not actually an optimisation, however, if I've understood the book's advice correctly. Its exact example is this:

Code:

Widget makeWidget()
{
	Widget w;

	// … Do stuff.

	return w;
}

which the programmer may be tempted to try and optimise like so:

Code:

Widget makeWidget()
{
	Widget w;

	// … Do stuff.

	return std::move(w);
}

However, this is unnecessary and might even make the code less optimised since apparently compilers will generally make sure that the returned object, if the same as the return type and returned from the function, is constructed directly in the returned object and not copied into it. This is known as RVO (return value optimisation).

Tho of course the widget is probably stored somewhere, and that would invoke a copy or move construction on that variable if I understand correctly, so this...

Code:

auto w(makeWidget());

... would still copy or move construct w with the rvalue returned from makeWidget(), I believe, but maybe compilers optimise even that. Otherwise it's a good idea to have a move constructor that can move the rvalue into w rather than copy it.

But according to this error/warning message from clang, it looks like RVO applies even there, at least in clang?

More info: http://en.cppreference.com/w/cpp/language/copy_elision

Woop, learning even more stuff!

Don't know if this applies to a collection with heap data in it, tho... Read that page. I'm trying to right now.

I was going to metion the RVO stuff but I didn't want to muddy the waters too much. I haven't done a whole lot of tests but I remember a hacker news discussion about this where the results varied a lot by compiler.

If you had a non-trivial type that didn't have a move ctor and you wanted to avoid a copy. Can you assume that the compiler will always be smart enough or do you need to coerce the move by casting to an rvalue?

I'll take a look at that copy elision stuff while my compiler is running :D

[oahda]

My general impression after reading the page is that RVO at least could apply to w here, but whether compilers will actually make sure of that might not be guaranteed, at least depending on the version of the standard (it seems like there's more and more RVO enforced officially in C++14 through C++17)?

[oahda]

Oooh, I forgot one of the coolest things.

constexpr is a bit basic in C++11, but in C++14 it's incredibly powerful, and even something like this (modifed example from the book) actually works:

Code:

class Point
{
	public:
		constexpr Point(int x, int y) noexcept
		:
		m_x(x), m_y(y)
		{
		}

		constexpr int x() const noexcept { return x; }
		constexpr int y() const noexcept { return y; }

		constexpr void x(int val) noexcept { m_x = val; }
		constexpr void y(int val) noexcept { m_y = val; }

	private:
		int m_x, m_y;
};

constexpr Point reflect(const Point &p) noexcept
{
	Point result;

	result.x(-p.x());
	result.y(-p.y());

	return result;
}

constexpr Point midpoint(const Point &p1, const Point &p2) noexcept
{
	return
	{
		(p1.x() + p2.x()) / 2,
		(p1.y() + p2.y()) / 2
	};
}

constexpr Point p1(9, 20), p2(28, 5);
constexpr auto mid(midpoint(p1, p2));
constexpr auto reflected(reflect(mid));

All at compile-time! So cool!

[InfiniteStateMachine]

Haha crazy. So I assume that once you pass a non-compiletime value into the point ctor it does it at runtime?


I just did a quick scan on the type elision stuff. I think I understand what's going on even less now haha. I have to go lookup prvalues now. Are those the same as what Scott M refers to as xvalues? (I dont have effective c++ at my work).

[oahda]

Haha crazy. So I assume that once you pass a non-compiletime value into the point ctor it does it at runtime?

Yeah, constexpr always works, it just stops being constexpr when you start passing runtime values to it, basically.

I have to go lookup prvalues now. Are those the same as what Scott M refers to as xvalues?

On the contrary, they're apparently "rvalues that are not xvalues" (stands for pure rvalues), and xvalues are expiring values.

Here's some info (don't just read the top answer; some of those below have some good complementary information or express things in different ways, with images and code examples and so on): http://stackoverflow.com/questions/3601602/what-are-rvalues-lvalues-xvalues-glvalues-and-prvalues

This answer in particular explained it well IMO: http://stackoverflow.com/a/9552880

[JWki]

JWki, I imagine we're going to confuse the hell out of a lot of people.

Also, that looks pretty interesting.

Haha yeah I'm just having trouble with my nickname lately - in CS:GO people think I derived it from the professional player JW which is unfortunate because I don't really like him. It's derived from my real name though, and I got so used to it I don't really wanna change it anywhere. xD
Luckily you got a nice number in there that should help with the confusion.

Also, thanks. :D

[oahda]

Watched Herb's talk yesterday too. Primary additional info I got from that was std::variant, which is meant as a safer replacement for unions. C++17, but might be available already. Thought I'd find it in the GSL, but it doesn't seem to be there.

And of course the static analysis tool of which I don't know the name that's shown throughout the talk. I'd like to have that built into my compiler, tho, and not as an external tool (tho it's integrated well enough into VS the way it is, but I don't use VS so)...

He also mentioned a byte type, which is apparently in the GSL, implemented as an enum class of chars with all the necessary arithmetic operators overloaded. Don't know if this is intended to actually become a built-in type in later C++.

Kind of funny how such an old language isn't getting such an "old" type (as in it was definitely more relevant in the past than it is now) properly (i.e. not represented as a character but as a number) until now...

Also watched this talk by Eric Niebler on a potential implementation of ranges in a future TS/STL.

[JWki]

Be careful with all of these talks though. Not everything in there applies to game programming and some things are actually harmful if you have to write low level code. You'll notice that often in these talks the speaker will say something like "this is something only library writers should worry about", for example when addressing raw pointers - everytime they say something like that, it's definitely something a game programmer SHOULD worry about unless they only work on the highest of levels of code maybe.
As a game engine programmer, you ARE a library writer AND an application writer and that should be kept in mind.
Also keep in mind that some of the speakers at cpp con and similiar occasions don't actually write production code, ever - Bjarne is a good example, I think I recently looked into his history and he never really worked on anything shipped. Most of the committee members are pure academics and don't work on actual products, thus the language features they release and the guidelines they give should be considered with EXTREME care because they might not actually be practical.

I can recommend talks given by Chandler Carruth and Sean Parent, both of these actively work on well known software and while Sean Parents stuff can get a bit theoretical as well they both have a more practical approach on using C++ as a production language than the committee members might have.

Also of course I'll have to recommend

infamous talk given by Mike Acton at cpp con 2014, which gives a good impression of how C++ is used in a game studio concerned with the kind of performance that games need, and as a side dish

talk by Nick Fleury which gives a bit of an insight on how Ubisoft uses C++ in really really big AAA games.

EDIT: I hate how forums and hyperlinks work. Just pretend I didn't embed these videos in the middle of a sentence.

[oahda]

example when addressing raw pointers - everytime they say something like that, it's definitely something a game programmer SHOULD worry about unless they only work on the highest of levels of code maybe.

Don't worry, these people are not saying things like this. They recommend raw pointers for basically anything that's not related to ownership (i.e. passing pointers around without taking over ownership or trying to reässign or delete them). That seems like a good rule of thumb to me.

Note also that unique_ptr has zero overhead and that owner<T*> is just a template alias for T*, so it doesn't actually do anything, but is simply there to make code clearer and to help tools analyse it, so using these in the right contexts is not a big problem so long as you don't start passing your unique pointers around because that's not how they're intended to be used. Just pass the raw pointers to other parts of the code, and make sure those sections don't modify it.

Do use shared and weak pointers sparingly, however, since those actually come with both overhead and bigger problems if you mess up your reference count (I'm horrible at dealing with reference counts, so I have avoided these completely so far).

As a game engine programmer, you ARE a library writer AND an application writer and that should be kept in mind.

Definitely! Rings especially true for me, since I enjoy doing engine work from scratch.

I'm mostly watching these to make sure I stay as updated as I can on the latest version of C++ and the STL so that I don't miss out on any useful tools lying around. I'm not treating any of it like gospel.

It's well worth noting that many of these little wrappers are meant to introduce higher safety while introducing zero overhead, so things like smart pointers and so on aren't as dirty as they might feel (unique_ptr is the only smart pointer without overhead, however, but the philosophy applies to much of the new STL stuff). The safety mostly comes thanks to RAII, which is a great technique anyway.

I do (rarely) do things in C++ that's not games too, however, so knowing about stuff in a more general sense is always useful. Even if something might be a bad idea in game programming, it might be useful elsewhere (tools, for example).

I can recommend talks given by Chandler Carruth and Sean Parent

Also of course I'll have to recommend this infamous talk given by Mike Acton at cpp con 2014, which gives a good impression of how C++ is used in a game studio concerned with the kind of performance that games need, and as a side dish this talk by Nick Fleury which gives a bit of an insight on how Ubisoft uses C++ in really really big AAA games.

Will check those out! c:

EDIT: I hate how forums and hyperlinks work. Just pretend I didn't embed these videos in the middle of a sentence.

Yeah, this bit me yesterday too, but I figured it out: to make your URL tags to YT links work without embedding ruining everything, remove the www. from it.

[InfiniteStateMachine]

I'm at work and can't watch the video now but I assume this was a discussion about never using raw pointers? I think even Bjarne at some point said they were fine to use and last I checked there was a proposal for pointer attributes so you can mark a raw pointer to indicate its ownership type.

In my head I've thought about applying a broad rule that if a function returns a raw pointer you aren't required to manage it (barring third party libraries of course). I'm sure I'm over-generalizing and missing a ton of edge cases though.

By the way Mike Acton has a webpage again : http://www.macton.ninja/

[oahda]

I'd oversimplify the general advice as "eliminate new* and delete, but not pointers themselves". So basically scope your ownership and depend on RAII (or on legacy/C libraries deleting in the background for you) for the deletion, but pass regular pointers around. Only mess with direct allocation if you have to (it's not forbidden, of course, and nothing is a rule, it's just advice for writing safer software).

And if there is indeed no overhead to a unique_ptr, I see absolutely no reason not to do this. It makes perfect sense and I personally find the RAII style very elegant. c:

I mean, everything is relative and advice doesn't always apply. If you're advanced enough a C++ programmer to realise when the advice isn't suitable for your needs, you're advanced enough to make these decisions yourself anyway. But I do find a lot of the advice very sound for many use cases, and I really like knowing the standard stuff well so that I can write consistent code and be on common ground with other programmers using the same tools. Of course, for example, the advice to eliminate new or delete might not apply when you need placement new or a custom deleter or something, and nobody is stopping you from making the sensible decision in those cases. c;

* by using make_unique and make_shared