How to Deal with Multiple Return Values in C++ 

TheChernoProject In newer versions of C++ we would use emplace_back not push_back as the second creates unnecessary copys.

Just for completions sake. For std::tuple you can return the value like a struct as well: return { vs, fs }; And with C++17 there is the option of structured bindings for tuples: const auto& [vs, fs] = ParseShader("res/shaders/Basic.shader"); std::cout

In this case it doesn't matter if you use emplace_back or push_back since the string has already been created. You can check out my video on this for more details: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-HcESuwmlHEY.html

really??

Just wanted to stop by and say thanks. I realized I watch a bunch of your stuff and need to start saying thanks more often!

Much nicer, thank you

Why not use a class?

That's a nice syntax 👌

This is actually better than struct actually because with structs there are some issues with initialization and you need to maintain few things in certain scenarios. For example, try reading a csv file with header and try to put them in a struct so that they have different types for each of the column. structs are horrible to deal with.

@@slayer5171 Structs are simpler by a syntax pov. Class has some extra features that's not necessary here (constructors, etc...). Comparing if this solution, you have a cleaner code since you are removing a struct that's only used as a method response. I'm not sure about this, but I think you have a gain (not much I guess) in performance since you don't have to instantiate the struct itself. At the end of the day, I think it's only a syntax alternative.

+1 to this!

Tbh, if one actually writes a c++ program, then one should ALWAYS optimize. Why else would one go to such lengths as learning a huge multi leveled language like c++ instead of using for example c#? And for me personally that is actually the part of c++ which I love most.

totally agree with you bro..

@@k-tech2937 I agree with you, Why use C++ when you don't want optimization.

Well, auto [vs, fs] = ParseShader("directory...") syntax not sound like a C++ at all. Adding a nail here and there just makes this already complicated language more complicated. ... C++ committee should just leave C++ alone 🥲

I agree with you. I think for something with 2 return values I would use pass by reference but anything more than 2 I would probably make struct.

Structs are obviously the best, but it can get a bit cluttered, so it should only be done if it's gonig to be used a number of times. Can't keep making new structs for every single thing. However, structured bindings are decent, aswell, even though it seems this video skipped over that...? At least, if you're doing this for member functions, you can declare the struct a member of the class, to avoid cluttering the namespaces. In such case, structs are definitely the best, no competition. It really is a shame that you can't declare the struct inside the function, and use the function name as a namespace...! That would be awesome.

Actually, there's a way to do what I was talking about, using "auto" type deduction...

What if you’re dealing with recursion?

That’s what I do too.

Cries in ue4 c++, cause no such elegant thing is available for ue4s internal data types

How is time complexity related to C++?

yesss templates!

Coming Soon! (TM)

Shayan Shajarian Look in cs 162. Best OS course!

If Im returning a big complicated class I’ve built inside a function, I always define a new type that wraps the class in std::unique_ptr and return that created type. Writing move constructor/assignment functions does almost the same thing but its more tedious. The only downside is you might get better performance writing the constructors/assignments assuming the compiler will optimize away any copying/moving. I assume moving and dereferencing a unique_ptr isn’t much overhead though, since when you’re returning something big it usually isn’t in the inner-most loop where it would matter.

Thanks for sharing, I definitely need to read up on C++20

the built in library functions come with the tuple

You can't conceive of an instance where one of the tuple library functions might be useful? Of course I like the struct semantics better and if I wanted to use the built in tuple functions I'd probably wrap it in a struct for semantic reasons. But, for drive-by programming, the enumerated tuple could work (as could the unenuerated tuple as used in the video).

You can, but this is not what the video is about: it's about returning multiple values of a *different type* .

It's extremely new and not really supported everywhere yet, so I tend to avoid it.

I can't tell you how sad this makes me to hear. Tuple is such a powerful tool but so many people shy away from it simply because it's so unnecessarily messy to use.

if you have to write a list of types your function will return, why not just write a struct definition instead? A tuple template probably compiles down to the same thing in the end.

"Make" is its own utility. It can actually be used for a whole host of other things, as well as other languages, besides C / C++. "Make" reads a file - often named "makefile" - that essentially contains a recipe for building software. Then you just type "make" and the Make utility will run through the recipe. In the makefile, you specify a target, then a colon, then specify that target's dependencies. Then, on the next line, you hit tab - yeah, in makefiles, the whitespace is important and it's needs to be a tab character, not just many spaces - you enter a command for creating that target from those dependencies. For example: main.o: main.cpp gcc -c main.cpp -o main.o Here, "main.o" is the target - the thing we want built - then, after the colon, are the dependencies. In this case, to build "main.o", we need the "main.cpp" source file. Then, on the next line, after a tab character (although, above, I had to use spaces, as you can't hit tab in a RU-vid comment), I supply a command that compiles "main.cpp" into an object file and outputs it as "main.o". Now, here's where the Make utility comes in handy. When it reads the "main.o: main.cpp" line, it sees that "main.o" is dependent on "main.cpp". So it checks the timestamps of these files. If the "last modified" timestamp of "main.cpp" is newer than "main.o", then "main.o" is out of date. So the Make utility will run the command line underneath, which compiles "main.cpp" into the "main.o" object file. But if the timestamp of "main.o" is newer than "main.cpp", then "main.o" is up to date and the Make utility will not run the associated command. The beauty of this conditional execution of the associated commands - checking the timestamps of the target and its dependencies, to see if it's out of date - is that it'll only compile what needs to be compiled to bring things up to date. On a large project, with many files and inter-dependencies, where you might also have multiple stages (source -> assembly listing -> object code -> linking final executable), then using "make" means you're not re-compiling the whole project every single time. The "Make" utility will check those timestamps and just compile what's out of date to bring it into date, and that's all. So, if you only modify one source file, then "make" will only re-compile the targets that have that source file as a dependency. Everything else is up to date, so it won't touch it. Now, there's all kinds of features and syntax to makefiles - it's kind of like a mini-programming language of its own (and, if I recall correctly, it is technically Turing complete) - to make recipes easier, to use variables, to cache a file's "#include" files to do auto-dependencies for you and a whole host of other things. For example: %.o: %.cpp $(CC) $(CCFLAGS) -c $< -o $@ This is a generic "compile .cpp files to .o files" command. The "%" is a wildcard, matching any filename (so, "%.o" is all ".o" files, and "%.cpp" is all corresponding ".cpp" files). I'm using variables with "$(CC)" and "$(CCFLAGS)" - which is a common thing in makefiles to define the compiler as "CC" and the flags as "CCFLAGS" at the top of the file, so you can switch to using another compiler or add an extra flag to all compilations by just changing the variables - and the macros "$

@Peterolen thx

If you need to use pointers, consider using shared_ptr or unique_ptr at this case

@Peterolen A little late to comment here, but I'm guessing Z3roFPS is referring to activation of the copy constructor of the struct as it gets returned by value vs passing two pointers or references to std::string. Modern compilers can deal with the potential copy overhead in the former case through return value optimization.