Jump to content

  • Log In with Google      Sign In   
  • Create Account

BitMaster

Member Since 08 Aug 2000
Offline Last Active Yesterday, 12:56 AM

#5276285 Game Dev.

Posted by BitMaster on 18 February 2016 - 03:52 AM

In a personal view point, i think that you need to know C/C++ is a good base to begin in videogames development, because there are other languages as java or c# with a sintax like C and that can help you to learn it quicly.


A professional game programmer who does not know C++ is probably at a disadvantage. Beginning game development in either C or C++ is in my experience a very bad idea. Neither language is in any way forgiving to a beginner in programming, especially because things easily 'appear to work' but are in fact horribly broken.

Saying languages like C# and Java can help you learn C++ or C quickly is simply an obscenity. First, you learn languages on their own terms. Knowing other languages certainly makes it easier up to a point but the biggest task in learning any language is learning it idiomatically. If a skilled C programmer writes C++ code largely like they write C code that usually ends in a 'worst of both worlds'-state. That is despite the fact that C++ and C share a very close relationship (some of the first C++ compilers even generated C code to do the actual compilation).
This does not get any better when looking at Java and C#. Some of the worst C++ code I have seen in my time was made by people who had some Java experience but were absolutely clueless about idiomatic C++. C# programmers are probably guilty of similar crimes but there were never that many around the code bases I have to deal with.

The other core complaint here is using 'quickly' in the context of 'learning C++'. C++ is not a language you learn quickly. And I'm saying that while loving the language (despite or because of all its rough edges).


#5276000 Pointers: "type* var" versus "type *var"

Posted by BitMaster on 16 February 2016 - 12:49 PM

If you're writing C++, I would suggest you lean towards the "std::string const& var" convention, it will make understanding templates and compiler error messages a little easier.


I have been playing around with that style (and some other changes from my usual routine) for a new code base at home. It took some time getting used to but it really has grown on me and I caught myself slipping into it at work several times.


#5275943 Pointers: "type* var" versus "type *var"

Posted by BitMaster on 16 February 2016 - 09:24 AM

I use 'type* name'. I find it easier to read and the * is a type modifier and should thus be closer to the type in my opinion.

On the other hand there is a significantly higher danger of accidentally going 'type* var1, var2;' and not declaring what you expect to declare. I am however strongly opposed to declaring multiple variables in one line like that so it's not an issue for me.


#5275929 Template Specialization

Posted by BitMaster on 16 February 2016 - 09:03 AM

No, static_assert won't trigger SFINAE, but that was kind of my point - as with the code example given, I don't see much points in him using SFINEA. What he shows and describes is a function that should fail to instantiate if a incompatible type is used - which is what static_assert does, but only with a better error output. I posted both my solution and the comment towards static_assert based on whether he really wants to use SFINEA here, or not smile.png


Yes, but the point of template specialization is in general that you don't want to just restrict it to specific types, you want radically different behavior for some types which you cannot do unless you provide a completely different implementation for those types.
Edit: Actually I think I see what you want to do now. Specialize for std::string as originally planned but insert the static_assert into the unspecialized template part. Yes, that would work. Although if I had the time I would try to investigate why the current scheme does not work. You don't always have such a workaround and there might be some easy skill points to get.

Ryan_001: that won't work in this scenario since the template parameter is only used for the return value and you have to call it function<myType>(...). If the template parameter was used as a function parameter, it could be done like that.


#5275305 [C++]Need help with a customer & salesman question.

Posted by BitMaster on 11 February 2016 - 12:12 PM

Editing a post appears to be broken today on the browsers I tried, so and addendum to the previous post:

Never even mind situations where you absolutely have to use the initializer list, for example because a type has no default constructor or you need to initialize references.


#5274191 Any portable/semi-portable way of forcing class field order in C++?

Posted by BitMaster on 04 February 2016 - 01:39 AM

I'm not aware of any compilers reordering data members. The standard does not promise much about member data, but I'm pretty sure it promises sequence. What it very specifically does not promise is padding (that is, how many 'dead bytes' are added between members to make them align nicely on the target platform).

If you have to serialize whole structures (what is in my opinion not a good idea), at least static_assert the size you expect to see. If a compiler tries anything cute regarding padding at least it will quickly and obviously blow up. Unless the compiler adds different padding but ends up at the same total size. In that case, have fun.


#5274190 [Debate] Using namespace should be avoided ?

Posted by BitMaster on 04 February 2016 - 01:30 AM

Like others, I think "using namespace" is terrible in headers. However, there are exceptions to most rules, and I think an exception for this rule, depending on the project, might be std::placeholders. I wouldn't be opposed to "using namespace std::placeholders;" within a major header, but I'm glad that it's within a namespace by default.


Actually, placeholders are a bad example for that. First, you should not really need them nowadays since lambdas can do what they do while avoiding some pitfalls of std::bind (there was a thread recently with some surprising gotchas regarding std::bind). Even if you needed them you would most likely only need them at function scope as well.

A better example would be the string literals under std::literals though.

Still, namespaces like this are explicitly designed to be used somewhere (even global-ish) since they contain an extremely limited number of symbols. Unlike the whole std, which contains everything including several templated kitchen sinks.


#5274043 [Debate] Using namespace should be avoided ?

Posted by BitMaster on 03 February 2016 - 09:03 AM

Using any namespace at header level is a good way to make a not-friend out of me. I strongly discourage using any namespace at file scope. Using namespaces at function scope is occasionally useful or required (see Swappable).

In my own code it practically never happens (with the exception of things like using std::swap).


#5274039 Footware at work

Posted by BitMaster on 03 February 2016 - 08:57 AM

I doubt any company has explicit rules about it until someone actually starts slogging around without shoes.

While I personally would not care what you do at your own desk, when walking around in the office wear something. Perhaps something easy to get in/out of like simple sandals or slippers but wear something.


#5273813 Problems reading back values from a file

Posted by BitMaster on 02 February 2016 - 02:23 AM



		fs.open(filename, std::fstream::in, std::fstream::binary);


I'm not sure what function you are calling there since I could not find any documentation of a three argument open member function, but you want

fs.open(filename, std::fstream::in | std::fstream::binary);
Note the operator | instead of the ','. Also, while this does not matter, I would usually prefer to call the flags std::ios::in and std::ios::binary since they belong to streams in general and not just file streams.


#5271703 Responsive UI in compute-heavy games

Posted by BitMaster on 18 January 2016 - 09:14 AM

I'm pretty sure both Win32 and Qt are singlethreaded unless you (as the programmer) choose to spawn more threads, but I might be mistaken about that.


Well, modern QtQuick-based applications will be multithreaded by default because the update and render logic are divided between different threads. Of course that is only a limited help because any blocking update logic will still make the UI feel unresponsive. However, at least controls like for example the BusyIndicator will keep animating even with a blocked update-thread.


#5270827 Weird access violation when copying data

Posted by BitMaster on 13 January 2016 - 03:49 AM

It is a conscious decision of the forum not to have a delete button for threads. Even though you may feel there is little value sometimes it does sometimes help people. You would also be surprised at the number of people who ask a real question, get an answer and then try to remove their question and/or the whole thread. That goes very much against the spirit of a community like this and invalidates all use others have from it.

Nevertheless, if you truly feel a thread should be deleted you are free to petition the moderators to do so.

I would also like to point out that it is not a good idea to just lash out at people with the rating button. Bacterius was not the person who downvoted your post, he was just kind enough to post his reasons why you did get a minor slap on the wrist from someone else.


#5270567 Criticism of C++

Posted by BitMaster on 11 January 2016 - 01:04 PM

Honestly, as long as we can agree it's a bad idea for the compiler to just sneak them in I don't have strong feelings either way. I need something like that once in a blue moon, I could live with doing it by hand or falling back on the Boost way. Maybe one could even add a [[generate_operators]] attribute to the class, we have these nice shiny attributes for C++ and barely anything to do with so far.

I would however point out that in general it's a better idea to define operator += explicitly and generate operator + from that, otherwise you waste at least an extra copy.


#5270530 Criticism of C++

Posted by BitMaster on 11 January 2016 - 08:12 AM

Well, Mussi said that and I he did not actively advocate that point either. Instead he was just trying to home in on the core points made in that video...


#5270506 Criticism of C++

Posted by BitMaster on 11 January 2016 - 03:28 AM

I wish C++ generated more default operators (like I don't get why I need to define both += and +, < and > and >= and <= and so on). I wish I could just go operator+=(const SameClass&) = default; if I write the related classes.

 
[...]


I'm not sure I feel confident with that. That's a potentially very large number of automatically generated functions which you would have to '= delete' or specify directly if they are not doing what you want them to. Very easy to miss one of them too. I'd much rather have something like boost::operators as part of the standard instead of something automatic.

Personally I'm hardly ever giving anything a full set of operators. Sometimes things get an operator < if they need to be part of an ordered container but that's usually it.




PARTNERS