Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Jul 2012
Offline Last Active Today, 02:30 AM

#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.

#5247581 Pointer Clarification

Posted by on 19 August 2015 - 12:56 AM

As you already know, pointers are just addresses of stuff in memory (plus some type information). It's okay that you don't understand what they are good for, it was the same for me when I started. But you will stumble upon a use case sooner or later and then it will probably be like "whoa, it's not that complicated actually".


There are several cases, where pointers (or in modern idiomatic C++ increasingly often smart pointers, but that's a somewhat more complicated concept) play an important role:


  • You use dynamically allocated memory, say with new or malloc. These things return the address of the memory they allocated, which you have to store somehow in order to use the memory. That "somehow" would be a pointer of some kind. Again, in C++ you usually use a container class instead of that.
  • You want to pass around a piece of memory to be used in other parts of your program. Either you want this other part to directly manipulate a piece of data you have in the local part or the data is just to big to pass it as a function argument by value. In both cases you would pass a pointer (or a reference, which is a related concept).

There are more use cases, but these may be the most common ones. For your Goblin class, there is nothing I would see where you could use a pointer to your advantage. But using a pointer usually results from the interaction of different code parts (and you show only a declaration of a class, no actual code).

#5237415 Disk Area Light

Posted by on 28 June 2015 - 11:15 PM

Here's what I would do: First project your point onto the plane of the disk. Then check if the distance from the projected point to the center of the disk is less than the disk's radius. If if is, voila, closest point. If it is not, scale this distance to the radius of the disk, which will give you the point on it's perimeter that is closest to your original point.


Actually, I think this should be pretty close to what you have do with your rectangle light.