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

#5270104 What happens with 32bit overflow?

Posted by on 08 January 2016 - 11:41 AM

  • Apps using C++'s new operator will throw an exception when it runs out of memory; so it will crash immediately. However the app can catch this exception and try to recover, like in the malloc case. Poorly written C++ code may catch all exceptions and not notice it's catching an out of memory exception; in which case they'll continue to execute except now they have an uninitialized pointer (which worse than a null pointer). Uninitialized pointers normally crash immediately when they're used, or may corrupt the process' memory and continue to run until it's so broken it can't work anymore or crashes (think Gameboy's Pokemon glitches)

Basically true, although you can specifically override that behavior with std::nothrow. However while it should be mentioned for completeness sake I have never actually seen it in the wild.

#5270045 Handling string literals

Posted by on 08 January 2016 - 07:43 AM


char tempBuffer[255];
strcpy(tempBuffer, "This is not a literal anymore");

#5270036 Criticism of C++

Posted by on 08 January 2016 - 06:31 AM

I know 'C++' as well as 'C' and I can't assure you the problems I've stated above are all still valid in 'C++'.

I spend admittedly very little time in C but my job requires a lot of work and knowledge in C++. What I see in your examples screams "C++ = C plus the 'class' keyword". That's always something I don't enjoy because I have to suffer through a lot of needlessly annoying legacy code caused by this. Someone versed in C++ would not write code like that.

And although optimization can take place for the return value - the things are not the same for the function parameters.

const references were pretty invented to make the optimization decisions for the compiler easier in this regard...

I highly doubt that the compiler will optimize the code I have written above. Or maybe it'll who know?

Maybe before trying to shoehorn a new syntax into a language you should really investigate this issue. A lot of compilers (especially with the right IDE support) allow you to inspect the generated assembler code.

But in every case I find it a flaw that things which could be very easily handled by the programmers itself are left to the compiler which could or could not optimize certain thing.

There is still the option of writing specialized portions in assembler.

After all wasn't the power of 'C' that is closest to the low-level languages?

It is sometimes described as having been intended as a "portable assembler". In general it is accepted that once things become portable, you lose a bit of the nitty gritty details and fine-tuning.

And in certain cases even the compiler can't help.

Well, you admitted yourself you do not really know about that because you rather start writing how to change a language than investigating in detail what state-of-the-art compilers currently can and cannot do.

How could you return a VLA for example using the current syntax?

In all my years of working in the field, I have never needed to do that myself nor read it in code I work with. If I had to return a VLA I would probably do it using std::array<> and trusting in RVO. Of course I would not do that because I'd say returning it is not a good idea and I'd rather pass a pointer to the memory block to the function.

Delete my post. I don't care.

That is a rather childish attitude and not really helpful to convince anyone. Aside from the two of us, there have been 3355 other users active on this forum during the last hour. And with a behavior like that you pretty much invalidated any chance you had to convince any of them. Because one person happened to disagree with you.

#5270027 Criticism of C++

Posted by on 08 January 2016 - 05:44 AM

That is a long post which mostly says to me "I don't really know modern C++".

Someone with more time on their hands can surely do a better job but two things stand out to me: I would expect a modern compiler to auto-inline both the function call and parameter passing away, especially when using a const reference instead of a const pointer. That whole paragraph about return values appear to be a complicated way to manually do something RVO gives you for free in a modern compiler.

#5269406 Criticism of C++

Posted by on 05 January 2016 - 07:11 AM

(btw, STL is not just a random library)

The STL is a random and extremely old library. Granted, it had a large influence on the C++ standard library (most, but not all, which was contained in the STL became part of the C++ standard library after all) but it has not been really relevant for well over a decade (which is kinda a long time in this field).

Granted, a lot of people (even otherwise very knowledgeable people) make the error of calling the C++ standard library just 'the STL' (often just because of laziness) but perhaps in a thread like this a bit more concern should be taken not to conflate these concepts.

#5268451 C++ Class Constructor

Posted by on 30 December 2015 - 05:22 AM

Sorry, mligor, but that is pretty much nonsense from start to finish. The return value of setPhoneBookName() is a temporary but that can bind fine to a 'const std::string&' (to copy-construct the std::string parameter) or directly to a 'const std::string&' parameter (which would have been a good idea to do). Most compilers will not even need to do that because they can just RVO a copy away.

Storing the return value in a local variable first is not needed. Not pre-C++11, not after. If that helps in your scenario you are just changing the symptoms of a more severe underlying problem.

#5268142 C++ Class Constructor

Posted by on 27 December 2015 - 04:06 PM

It might be a bit late in my timezone bust have you considered you are falling victim to the most vexing parse?

Also, you should never get into the habit of any 'using namespace' in general and std in particular in a header. Typing an extra std:: is not bad, adds a lot of clarity and the first time your polluted global namespace gives you hell you will understand the remaining point.

#5267649 Lua, collecting garbage on exception?

Posted by on 23 December 2015 - 08:43 AM

But Bacterius does not necessarily want them to release 'that instant'. He simply wants to avoid releasing them at an arbitrary point in time (up to 'never', depending on how much Lua memory his event loop actually allocates during normal runs).

That said I do not find releasing resources at the point of an error to be unreasonable. After all, RAII in C++ does exactly that. That behavior is just not free out of the box in Lua, though what Bacterius plans should emulate it closely enough.

#5267623 Lua, collecting garbage on exception?

Posted by on 23 December 2015 - 04:43 AM

vstrakh, I don't think you are getting Bacterius completely. It is entirely possible that a Lua object consumes only a tiny amount of Lua memory while consuming lots of application resources (for examples because it represents a large texture living on the GPU or a database). These resources can remain in garbage collector limbo for a long time if no extra action is taken.

Bacterius: it certainly sounds reasonable to me. In a game-centric situation I would consider not doing it with every pcall and just setting an error flag. A garbage collection could then be triggered at a convenient time (the next level loads, the user just paused the game, ...) but maybe profiling shows it's not even necessary.

#5267559 Effects11 DirectX11 for GCC Compiler

Posted by on 22 December 2015 - 04:58 PM

I'd like to strongly disagree with Sean's opinion. While my professional life revolves around various flavors of MSVC, I have moved towards a gcc-based approach for my hobby projects and I'm certainly enjoying the ride as well as realizing it has made me a better programmer. The only thing I usually miss from MSVC are the debugging features (although newer QtCreators have certainly improved a lot in that regard since I first started using them).
That said, for a beginner in the language I would still strongly recommend starting with MSVC (at least when on Windows). It is pretty much the standard compiler and using another compiler usually forces you to get every library you want compiled yourself. That is in itself not a bad thing which will force you to learn a lot. Just not when you are starting out.

#5265745 Getting a variable inside a loop

Posted by on 10 December 2015 - 10:04 AM

It does not call your function because you never try to call it.

When you say
Character moveBy();
that means you declare a function local to _tmain called moveBy which returns a Character. That, however, is mostly an artifact rooted in C++'s ancient history (see also Most vexing parse). Had you said
Character moveBy(2, 3);
that would have caused you to create a new instance of character called moveBy. None of these make any attempt to call Character::moveBy. What you want for a first test is:
Character character(2, 3);

#5265740 Getting a variable inside a loop

Posted by on 10 December 2015 - 09:38 AM

But the problem i'm having now is when i'm trying to call my moveBy() function which is also in the character class, it gives me this error

'Character' : no appropriate default constructor available.

Character character;
I've called other functions from classes before so i'm not sure why this is.

You are trying to create a new instance of Character. That is not possible because the only available constructor requires two parameters (for initializing the starting position).

However, the core problem appears to be that you are unintentionally creating a new instance when that is not your intention and not useful to your cause. You really need to post more code for anyone to really help you though.

#5265728 Getting a variable inside a loop

Posted by on 10 December 2015 - 08:28 AM

The variable is destroyed when the scope in which it was declared is exited. If you do not want it to be destroyed when the loop is exited, don't declare it inside the loop but in a suitable enclosing scope.

I do however believe that will not help you. I suspect you want to try and modify x and y at some later point in the hope that will move your Character. That will not be the case (unless you try to do weird things which are also rather unhealthy).

You will need to do something like
clist[suitableIndex]->moveBy(+1, -1);
which will probably require you to implement a suitable Character::moveBy member function as well.

#5265695 Vector mock to catch bad accesses

Posted by on 10 December 2015 - 02:45 AM

Further, please refrain from insulting and otherwise disparaging anyone who does post such opinions.

I was pondering how to respond to this. But since this is not For Beginners and the core topic of the thread has been successfully solved I'm going with 'spinning off a tangent from the tangent'.

I'm going to assume that is directed at me and I would like to object to it. The statement I was referring to was extremely unhelpful. Especially in the context of the thread, but even in a thread where a discussion of the standard library was intended it failed on all relevant levels.
The core problem started with the choice of 'hate'. 'Hate' strongly implies a purely emotive reaction instead of a rational one which really has no place in a technical discussion. What else was I supposed to do? Just downvote him? I can respect the decision of the people who did by now but I considered it unhelpful.
So instead I decided to challenge the statement directly. While I admit what I said could be construed as a bit disparaging I also don't see how to avoid that. Sure, you can wrap up the statement into so many layers of cotton that it becomes less noticeable but then you also start losing important signal about what you are objecting to.
I can honestly say the only times I have encountered statements like "I hate std::vector" was people either (a) trolling or (b) having run into a problem with them because they were unaware of its semantics. People who are dealing in scenarios where using std::vector is legitimately a less optimal solution express themselves in completely different ways (and usually have the wisdom not to inject such a discussion into places where it is not warranted).

I realize that was not a formal reprimand but if it was, I would be appealing to another moderator now.

#5265693 std::thread arguments and copies

Posted by on 10 December 2015 - 01:56 AM

I highly doubt it has something to do with the standard, MSVC has been rather bad at dealing with C++11/C++14. Their standard library just had so many holes and workarounds.

One of the core reasons I switched my hobby work over to non-MSVC compilers was to gain access to reasonably complete implementations of C++11 (and later C++14). In the process I noticed myself gaining a lot of skill points in related areas and I have also come to enjoy the experience. Even if MSVC 2015 should be a decent implementation of C++14 I would not consider switching back for the foreseeable future.

Edit: @jbb: I would be happy to discuss whatever you are objecting to but I see a commentless downvote in this scenario as extremely unhelpful.