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

#5285221 Project is missing SDL_mixer.h; I add it and the compiler gives 77 errors

Posted by on 05 April 2016 - 03:26 AM

Well, SDL 2.0 has been out for a long while now and although I have never used it from what I have heard it's much better than its predecessor. You cannot really expect deprecated stuff to remain around indefinitely.


Also, I now have the strong suspicion your unresolved externals have a very different source than linking or not linking SDL mixer. Most likely it depends on some Windows multimedia functions which you have to link as well. Of course that would have been immediately obvious had you posted the actual error messages. Which you unfortunately did not.


On a personal note, this is the second time you go towards blaming the tool in this thread. A decent programmer does not blame the tool until he has understood the whole problem and exhausted all options. Placing the blame on the tool early and often is a good way to tick people off and receive less and less help in the future.

#5285006 Project is missing SDL_mixer.h; I add it and the compiler gives 77 errors

Posted by on 04 April 2016 - 05:41 AM

I've had mixer.dll in the project folder the whole time. I added SDL_mixer.lib to sdl's LIB directory and I tell Visual Studio to include it as an additional dependency and it still gives 76 errors.

Are you telling MSVC to actually link it or have you just specified it as a dependency?

It tells me to use /nodefaultlib:library but what the heck is that? Do I replace the words "library" or do I input that parameter verbatim? I don't understand how the compiler complains about one thing, then I add what it wants, and it gives 77 warnings. It's so stupid! I have sympathy for people who try programming and give up. The errors make no sense. Before anybody asks, yes I can reproduce this problem over-and-over again. I want to know how to fix it.

I guess this error has something to do with Microsoft's stupidity in making Visual Studio. I think maybe I can kill off msvcrt.lib and there will be no conflict. Should I do it?

A library you are trying to link was compiled with a different MSVC runtime than the one the rest of your project is using. This could be a different version or a conflict between dynamic/static or debug/release runtimes. You need to download a version which matches your build system or build it yourself using the adequate compile time options.

#5284629 text file -> object file -> link ?

Posted by on 01 April 2016 - 11:19 AM

Unless you absolutely know you will only ever be using MSVC I would not do something like that. Both at work and at home I'm using CMake for that. The tool which does these transformations is a simple command line application inside the project. CMake tracks the dependencies, builds the tool before anything needing the transformations and executes it as part of the build process. It's CMake's job to put that into a form your build environment understands, whether that is MSVC project files, a bunch of make files or soemthing else.

#5284626 SpriteFont render Umlaute

Posted by on 01 April 2016 - 11:00 AM

In my opinion the console is irrelevant. Check the content of your strings with the debugger, not by printing them to the console. The console expects some encoding, perhaps Latin-1 (which works fine the range 1-127 but not beyond) or ANSI and whatever encoding your compiler generates is probably not the same.

For example when I print "Test 'ü'" to the console in a source written in stock QtCreator and compiled with MinGW I get "Test 'ü'" printed out. The debugger says the same and the values of the relevant bytes are a 195 followed by a 188. Now, I could take a look at how UTF-8 was encoded again and do the check myself. However, it's been a long day and I'd rather use this cheat sheet but it confirms I'm dealing with UTF-8.

Now, we are not even sure what the encoding of the string is in your source file. If you wrote it with MSVC it does something, but not the sensible. Open your source with a decent text editor (like Notepad++) and convert it to UTF-8 (with the BOM - the BOM is not recommended but MSVC does not recognize UTF-8 properly without it).

Now, dealing with UTF-8 is not the simplest thing since multiple bytes can be used for a single character. Still, I strongly recommend it for sanity, and I say that as someone who has written applications which translate freely between German, English and Italian (sometimes other languages).
For a simple game with extremely limited text output it might not be worth the battle but the battle is won and lost at string encodings no matter how exactly you solve the issue. You absolutely need to know in which way your input strings are encoded and which mapping the font uses.

#5284616 Actor object understanding

Posted by on 01 April 2016 - 09:35 AM

Of course. Unfortunately you do not post anything that would allow anyone to help you. You know, simple things. Like the code you are having problems with together with the error message. Crystalball-based forum posts usually do not work out well.

#5284486 Actor object understanding

Posted by on 31 March 2016 - 07:52 AM

Initializer list

#5283102 How can I locate a memory leak?

Posted by on 24 March 2016 - 04:59 AM

I'm inclined to agree with Khatharr. RAII is in my experience the way to go (and again to reinforce, if you think RAII means std::shared_ptr/std::unique_ptr then you have completely missed the point of RAII). Sometimes getting a good RAII concept (including some potentially backing infrastructure) for a problem going takes a bit of time and work. But in my experience the time, work and most especially nerves you save by that are well worth the price.

There are of course reasons not to use RAII. For example "This is one large, horrible mess of a legacy system and adding RAII to it would require rewriting/modifying large parts of it. If we invest that work we really should fix this list of other atrocities it commits as well. So basically rewrite the system from scratch. We don't have the time and resources for that now." Been there, done that. Paid the price. Cried.

There might even be problems where you honestly cannot apply RAII in a reasonable manner. I cannot think of one out of the top of my head nor have I ever encountered one. But seriously, Khatharr never promised that it will always work in the post which sparked all that.

Also note that using RAII or not is completely orthogonal to things like for example implementing your own memory manager (although in case of some implementation like scoped linear allocators you often end up with memory manager and RAII being properties of the same system).

#5281831 casting double* to float*

Posted by on 18 March 2016 - 04:48 AM

I'm with L. Spiro on this. I don't feel there is a place for any C-style cast in C++. It's far too easy to do something really bad (like casting a float* to a double*) by accident. If a static_cast does not do and that is in any way unexpected for you can think that issue through thoroughly if the whole thing is really a good idea (in most cases, it is not). A C cast will just do its thing.

I also find it significantly easier to detect C++ casts (and their intention) in code I'm reading.

#5281074 no good way to prevent these errors?

Posted by on 13 March 2016 - 01:08 PM

That's a horrible way to deal with that. At best you are doing what the compiler would do anyway by doing a proper assignment. At worst you screw something up because the structure is not trivially copyable.

#5278239 "Modern C++" auto and lambda

Posted by on 26 February 2016 - 02:04 AM

foreach( auto x : m_foos ) {}
Looks ok, right? Well turns out m_foos is std::vector<Foo> m_foos; The loop will perform a hard copy Foo in every iteration. [...snip...]

foreach( auto &x : m_foos ) { }
And now x is a reference, rather than a hardcopy.

But that's not an auto issue. That's a misuse of variables in-general issue.
If you did:

for( Foo x : m_foos )
...the exact same flaw would occur.
Further, I would suggest by default one should use const-reference, and only go to non-const reference or value (or r-value) is the code needs it (for example, if it's just integers).
If you use good coding practices, then "auto x : m_foos" stands out just as badly as "Foo x : m_foos".

I'd like to take a moment to strongly agree with Servant of the Lord here. The usage of auto here is extremely intuitive for me (same semantics as writing the real type).

And while I usually prefer to have the real types in ranged for loops, I also strongly prefer
for (auto& : container)
for (really::verbose::type_name::which_is_not_even::a_template& : container)
Apart from general readability issues, detecting missing/extra const and/or references in the auto version is extremely easy with just a glance. Not so much with the full type.

I freely admit there are corners of C++ which are difficult and not everyone can be expected to know all the details but I honestly think someone who gets easily confused with auto in the context of ranged for-loops has absolutely no place being anywhere near a C++ code base, hobbyist or professional.
Excessive overuse of auto (as others have said, C++ is already full of features which could be misused like that) is something I have never seen in the wild so far. Neither with people I have been working with nor with libraries I considered to use.

#5278179 "Modern C++" auto and lambda

Posted by on 25 February 2016 - 03:55 PM

Randy Gaul, I have no clue why you spent that whole post in the context of Microsoft. The features talked about have nothing to do with them (except they, like quiet a few other people, have a C++ compiler). They are C++11 features. Pretty old ones by now, we already have C++14 and C++17 around the corner. Just because the OP stumbled on them in something written by Microsoft does not mean it's reasonable to look at all the angles Microsoft might have with them. You could as well ask what Microsoft wants with for-loops because they mentioned them in an introductory article about C++ somewhere.

As a matter of fact Microsoft's own compilers have been hanging behind on C++11 features for a long time when others like gcc or clang already had complete or near-complete implementations. I hear they have recently managed to catch up but I could not yet try out the newer compilers in a realistic setting. An evil person might even say that Microsoft only talks about those features now-ish because only very recently they have compilers implementing them properly (although that would be a bit unfair because even though a lot of things were broken/incomplete for a long time, both lambdas and auto worked decently even back in 2012).

Now, discarding that wholly unnecessary Microsoft talk: both features are pretty much core for me. Sure, lambdas could be implemented using a simple class functor. But for small stuff they are much less verbose, for slightly more complicated stuff (needing to capture things) they completely eliminate unnecessary and error-prone boilerplate.

auto is mostly useful in the context of templates (and if you do not use them I seriously question why you even bother with C++) but they are something useful/less verbose in other situations (quickest example: storing a lambda).

Edit: and I have never seen someone do everything with autos the way Matias Goldberg exaggerates, nor seriously suggest that would be a good idea. I'd want some actual quotes on that.

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

Posted by on 20 February 2016 - 05:05 AM

Strangely, nobody has yet mentioned "declare on first use" yet

Because the OP asked a specific, well-defined question which is completely orthogonal to topics likes that.

#5276976 c++ copy all data from parent class?

Posted by on 19 February 2016 - 10:52 AM

It should work because I have done something similar in the past to bring sanity to a class' horribly broken copy semantics. You don't need the cast in backupB though, object slicing works in your favor there.

#5276285 Game Dev.

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