Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Jul 2012
Offline Last Active Today, 05:08 AM

#5314945 Running into some octree problem

Posted by on 13 October 2016 - 12:16 AM

Or ignore the problem. The empty nodes at the bottom probably don't take up a whole lot of space. Deal with it when you run into any problems with it (likely never).

#5313188 When should I use int32_t rather than int

Posted by on 29 September 2016 - 02:22 AM

Also, be aware that all uint*_t and int*_t are optional in the standard and don't necessarily exist. Only those types exist, that your compiler and CPU support. int_fast*_t, uint_fast*_t, int_least*_t and uint_least*_t exist on all conforming compilers.


The reason is that not all CPUs have integer types of all sizes, though I only know of DSPs that are very special. AFAIK all mainstream consumer CPUs have all the fixed-width types.

#5307968 Style preferences in for loop structure

Posted by on 25 August 2016 - 11:52 PM

i --> 0


I've never seen anyone write it like this, and in fact, without my morning coffee, it took me a few seconds to realize this is actually valid code and I had to put in extra effort to understand that it iterates over the same range. It's a neat trick, but I'm not sure it's really worth confusing other people who may read the code.

#5285255 Is it bad to use macros such as __LINE__ or __DATE__?

Posted by on 05 April 2016 - 08:31 AM

__DATE__ and __TIME__ can make trouble if you need bit-by-bit reproducable builds. I would assume that is not true for games, but I've been working on projects where that was a hard requirement.

#5269576 Criticism of C++

Posted by on 06 January 2016 - 02:34 AM

C++ has different goals and try to keep them by forcing backward compability, what if C++ had to be designed nowdays from scratch? It will result in much more clean, simple and performant language with less maintenance burden both on client and compiler side.


And it would never have gained the popularity it has today. Without backwards compatibility, you don't get this huge code base that already compiles as C++ and can start using C++ features where you see them fit. If it had broken with backwards compatibility early on, it would be in a similar position that D is in today: People know about it, many think it's even a good language and still very few people (in comparison) use it.

#5269392 Criticism of C++

Posted by on 05 January 2016 - 06:16 AM

Yeah, a few breaking changes for a future release would not hurt too much, as long as it doesn't go the Python way where 99% of Python 2 programs don't work with Python 3 and still a significant amount still don't work after running 2to3.


But as long as compilers keep clean support for the old standards, carefully removing clutter might be a good option. I have not seen a lot of C++98 code being reused without any change in modern C++. All projects I worked on either kept everything in the old standard or updated at least parts of the code (usually because C++ compilers were bad back in the day and people had to rely on or workaround compiler extensions or quirks which are no longer valid for most modern compilers). So requiring to update parts of a very old code base (in this case up to 18 years) doesn't seem like too much of a problem.


But I have the feeling that the things that would be changed would not be the things opponents of C++ have in mind when they speak about "breaking backward compatibility". Lots of the undefined and implementation defined behaviour would (have to) remain for various reasons.


Those things have already happened (e.g. std::auto_ptr in C++, gets in C) should continue happening, but with sound judgement and not break relatively recent code (I'm looking at you again, Python).

#5269198 Criticism of C++

Posted by on 04 January 2016 - 09:13 AM


If that is something that makes the language unviable for you, use a different one.

Can we not have a civil discourse on the pros/cons of a language without resorting to this?



It was an honest suggestion. If, after evaluating your needs, you find that C or C++ are not the right languages, then I hope you will use something else. If you find that C++ is the right language for the problem you are trying to solve, then it's often because all this implementation defined stuff makes it a very efficient language (if used right). Without these implementation defined features, you would lose many of the benefits of C++ and could just as well switch to C#.


I guess what I'm trying to say is that things like the unspecified size of basic data types (or any other of the things flagged as implementation defined) are an advantage of the language, rather than a disadvantage. Sure, it causes problems of its own, but the alternative solutions cause other problems. You have to decide which of the problems are more acceptable for your project and chose the appropriate language.


You defined something as "broken" what in fact is not. If you still think it's a defect in the language, it means you need to use a different language. You complain to me about reiterating the same arguments, while you are doing the same.

#5269152 Criticism of C++

Posted by on 04 January 2016 - 02:41 AM

but somewhere around the 1980s it should have been corrected


You just cannot do that. It would break tons and tons of code. Even code written for current processors. Especially DSPs sometimes provide basically only a single size of integer type (the one we are working with, for example, only has 32 bit types. For everything. char is 32 bit on this CPU, so are short, int and long. And that's just because the people who adapted the compiler for the CPU, the CPU actually used 40 bit registers. Btw, it doesn't even provide a int16_t and similar small than 32-bit types).


What are you going to do in such cases? It's something you have to deal with. Sure, for the desktop you can almost universally assume sizeof(int) == 4 and sizeof(short) == 2. But it's just not true on every platform C and C++ must work on. Also, there are types like uint_least16_t or uint_fast32_t.


If that is something that makes the language unviable for you, use a different one. Part of the work of a software engineer is to find the right language for the problem at hand. If C or C++ are not the answer to that question, then use the right tool for it, be it C# or Python or whatever.


It has to be designed by committee. It literally could not be designed any other way.


Too bad I can only upvote your post once. Sums it up perfectly.

#5263535 Preventing players leaving the play area where an obvious geographic obstacle...

Posted by on 25 November 2015 - 03:58 AM

I like the idea of just letting them run infinitely in the same direction and once they turn around, the border is just one clip distance away. So you could run for an hour into the void but return within 30 seconds.

#5260472 C++ calling a class constructor in a function argument

Posted by on 04 November 2015 - 03:40 AM

Are you saying the code was compiling that way? That sounds unlikely to me...


First of all you have a syntax error in your main function (the one I showed you). If SecondClass had a default constructor (which it doesn't have, because you declared a non-default constructor manually), then the constructor of MainClass would have implicitly called the default constructor of SecondClass (which would have left x and y uninitialized because they are not objects), then it would just have forgotten about the SecondClass reference you passed to the constructor and do nothing with it.


But as I said, I don't think you have ever compiled that code.

#5260467 C++ calling a class constructor in a function argument

Posted by on 04 November 2015 - 03:03 AM

There will always be the default constructor called for member objects. You could do it by declaring your secondClass member as a (smart-) pointer and allocating it at a later point in time, but unless you have a good reason to do it, you should stay with a direct member. Also, your code in main is not quite right:

  MainClass mainClass(SecondClass(1,4));

The way to directly call the (copy-) constructor for your member is to use the initializer-list of the constructor:

  MainClass(SecondClass &secondClass)
    : secondClass(secondClass) {
    // stuff

#5259567 Sign safer on this way ?

Posted by on 29 October 2015 - 08:08 AM

I'll remeber to call my function sign_bit if I ever write that "optimized" version



#5259563 How to resolve typedef conflict in APIs?

Posted by on 29 October 2015 - 07:54 AM

Both ways are legal in the context of the C and C++ standards. That's precisely the reason why using your own typedefs (unless they point to standard fixed width types like uint32_t) is a really bad idea. The compiler of the OP detected that problem (long and int are distinct types, just as they should be!) and made the code more portable in the process.

#5259547 How to resolve typedef conflict in APIs?

Posted by on 29 October 2015 - 06:31 AM

The answer is that the engine's typedef is plain wrong (long is no way guaranteed to be 32 bit). Do you have any way of influencing that part? Is it your own engine or thrid party.

#5253951 Is there a market for 2d/ low end 3d games?

Posted by on 25 September 2015 - 12:28 AM

Some of the most noticed indie games of the last years were 2D or Lo-Fi 3D: Braid, Thomas was Alone, Limbo, Bastion, Transistor, pid, Hotline Miami, FTL,  to name a few. Each of those had a rather unique style and great gameplay though. I don't know about their sales, but given the popularity they gained, I'd think they did at least okay.