Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Aug 2000
Offline Last Active Aug 17 2016 04:05 AM

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

Posted by 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 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 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 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 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 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 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 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 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 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 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 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 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.

#5270396 Criticism of C++

Posted by on 10 January 2016 - 09:07 AM

To be fair, even before C++11 you write very reasonable, modern (well, modernish) C++ especially using some parts of Boost (or implementing those bits yourself) as band-aid. The core problem of C++ in this regard has always been the apparent similarity with C: a lot of people think they understand C++ and believe they can write reasonable tutorials.

That means a lot of people never learned much more about C++ than C with classes tacked on (I know I keep harping on that fact but that really bugs me) and classes are there for polymorphism, nothing else. That always makes me a cry a little in my head.

#5270236 why does visual studio do this?

Posted by on 09 January 2016 - 02:55 AM

Release builds are not meant for debugging on any compiler. Debug information gets stripped and several optimizations make stepping through a program difficult or impossible (sequence might change, function calls do not even exist anymore, ...). Even if you can step through the program the values you see when inspecting the contents of variables are often unreliable.
CMake will by default generate a RelWithDbg configuration for you (basically settings normally used in Release builds but with debug information added back in) for example, but even that is not pleasant debug experience.