• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
forsandifs

Why are most standard code files so confusing? And what is the type of std::vector::size?

8 posts in this topic

People on gamedev.net, which tbh is my main reference where coding is concerned, are always harping on, and I think rightly so, about writing code that is easy to read.

And yet today when I recieved a warning from VisualC++ telling me that there was a sign mismatch between my int type comparison with a std::vector::size call something that to me seemed contradictory to that came to my attention.

I first cast the result from the size call into an int to get rid of the warnings. Then I thought, hang on, what is the actual return type of std::vector::size?

So opened up the vector code file, and ermm, was presented with an enormous wall of WTF. Certainly not easy to read as far as I can tell. And I remembered that this is actually the case for most standard code files I've ever looked into.

Why do they almost always blatantly contradict the "easy to read" principle? Or is it just me having a very different idea of what is easy to read?

And also, what is the return type for std::vector::size? EDIT: Is it UINT, or UINT32, or unsigned int? Are they all equivalent?

Thank you.
0

Share this post


Link to post
Share on other sites
Well, I guess these functions/stuff in standard libraries are meant to be used as black boxes, and not for somebody to read/modify them.

Ahh, beaten...
2

Share this post


Link to post
Share on other sites
The type of std::vector::size() is std::vector::size_type which will usually be the same as std::size_t (but does not have to be). In general I would advice against looking into standard header files. The place to check is the documentation (for example msdn or cplusplus.com which is the first result for googling "std::vector").

Actually, when using any kind of library, regardless of how readable it is, I would advice against looking into the code to check something out. If possible, use the library's documentation whenever at all possible. Only if that is insufficient or you suspect a bug or inconsistency would I consider looking at the code.

That said, it is well known that the C++ standard library headers are horrible to read. On the other hand, it should never really be your problem. The only line you usually have to read is the one where the assert just failed (and even that seldom because the last line in your code before entering the standard library is usually self-explanatory enough).
Edit: Memo to self: type faster.


1

Share this post


Link to post
Share on other sites
[edit]Quadruple ninja'd! [img]http://public.gamedev.net/public/style_emoticons/default/unsure.gif[/img][quote name='forsandifs' timestamp='1304598437' post='4806870']
Why do they almost always blatantly contradict the "easy to read" principle? Or is it just me having a very different idea of what is easy to read?[/quote]The standard library just has a very destinct ...*ahem*... style... Once you're used to that style it's somewhat easy to read.
The standard library isn't really "standard" code though - and template-meta programming tends to be ugly in general - don't look to it for inspiration.[quote]And also, what is the return type for std::vector::size? Is it UINT, or UINT32, or unsigned int? Are they all equivalent?[/quote]It's a std::vector<T>::size_type, which if using the standard allocator is a typedef for the std::allocator<T>::size_type, which is a typedef for size_t, which is a typedef for unsigned int.
UINT and UINT32 are also usually the same as unsigned int.
2

Share this post


Link to post
Share on other sites
[quote name='sheep19' timestamp='1304598939' post='4806874']
It couldn't be int or unsigned it because those are different among different platforms.

It is an unsigned type for sure, though I;m not sure for its bits.

Use std::vector<yourTypeHere>::size_type and not int, because if the length of the vector exceeds INT_MAX, the size you will get will be negative.That's why there's a warning.
[/quote]

[quote name='jbadams' timestamp='1304599031' post='4806875']Rather than trying to look at the code, you might find it easier to check documentation when you have a question about the standard library, such as the [url="http://msdn.microsoft.com/en-us/library/3y41k4hb%28v=vs.80%29.aspx"]MSDN page for vector::size[/url] or a reference such as [url="http://www.cplusplus.com/reference/stl/vector/size/"]this page on vector::size at cplusplus.com[/url].[/quote]

Ah thanks. I did find the size_type return value but I was confused by it, due to having been looking for an intrinsic type.

[quote name='jbadams' timestamp='1304599031' post='4806875']
Your code should be easy to read and maintain because you will be working with and maintaining it. The same is not true of the standard library -- you as an end-user simply need it to work as expected, there isn't an expectation that you will want to modify or update those files. The writers of your standard library implementation have had to produce code that is safe, performs as expected, is efficient in a wide variety of potentially very different situations, and in some cases it has to be very flexible, and have had to resort to code that is less readable than might be desired in other situations in order to do so.[/quote]

[quote name='szecs' timestamp='1304599131' post='4806876']Well, I guess these functions/stuff in standard libraries are meant to be used as black boxes, and not for somebody to read/modify them.[/quote]

Ah right, OK. That's interesting. Thank you.

[quote name='jbadams' timestamp='1304599031' post='4806875']
Does that help/answer your question? [img]http://public.gamedev.net/public/style_emoticons/default/smile.gif[/img]
[/quote]

Indeed it does. :)

EDIT:

Also thanks to the other two responses that came in before I posted this one. :P

EDIT:

[quote name='Hodgman' timestamp='1304599423' post='4806882']]It's a std::vector<T>::size_type, which if using the standard allocator is a typedef for the std::allocator<T>::size_type, which is a typedef for size_t, which is a typedef for unsigned int.
UINT and UINT32 are also usually the same as unsigned int.
[/quote]

Ah I see, so it boils down to an unsigned int. Sweet. Cheers.
1

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1304599423' post='4806882'][quote]And also, what is the return type for std::vector::size? Is it UINT, or UINT32, or unsigned int? Are they all equivalent?[/quote]It's a std::vector<T>::size_type, which if using the standard allocator is a typedef for the std::allocator<T>::size_type, which is a typedef for size_t, which is a typedef for unsigned int.
UINT and UINT32 are also usually the same as unsigned int.
[/quote]
On 64 bit systems std::size_t is often an unsigned 64 bit integer, so it is better to use std::size_t than unsigned int.



The code itself is not standard. Each compiler use its own implementation of the standard library.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0