Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - VPellen

Pages: [1]
1
General / Re: Displaying a number with sf::string
« on: April 11, 2012, 03:46:29 am »
Ahh yes, converting a number to a string.

If you want to convert a number to an std::string (and you really should use std strings where possible, by the way), C++11 has a std::to_string function. If your particular implementation doesn't support std::to_string, or you don't like to use C++11, and you're not too concerned about speed, the following function works, and when std::to_string is implemented in the standard library, you can just delete the function definition and carry on as normal and everything should just work.

Code: [Select]
#include <string>
#include <sstream>

namespace std
{
    template <typename T>
    string to_string(const T & value)
    {
        stringstream stream;
        stream << value;
        return stream.str();
    }
}

2
General discussions / New naming convention
« on: March 21, 2012, 01:15:58 am »
Downloaded the latest source today, and my compiler spat out about a few dozen no-such-member errors.

A pain in the ass to rename, but this is a good thing, right?

3
General / Help understanding the tutorials?
« on: March 14, 2012, 11:20:10 pm »
If I had to guess, I'd say that somewhere along the way some settings got misplaced or fiddled with and then at some point you did multiple steps at once and one of them happened to inadvertently clear up the issue. Either way, good to hear you got things running.

4
General / Help understanding the tutorials?
« on: March 14, 2012, 01:23:08 pm »
I'll happily write you up a clean tutorial if you want, but it'd fundamentally be a language/computer science intuition tutorial rather than a "how to get things running" tutorial. Also, if I were to explain the intuition, I'd probably make a completely separate tutorial on codeblocks because it's very, very separate from the intuition.

Unless you mean I should make my own website. In which case.. well, hell, I could, but I don't know.

You know, really, your tutorial on how to compile SFML shouldn't even be necessary. It should be enough to say "Here's where the libs are, here's where the includes are, off you go son". Compiling the libs from source should be a process even a beginning programmer is capable of. But people come here and they want to understand how to make a program with SFML, and they're confused, and so they nag you and ask you to make a tutorial.

But this isn't their fault, really. Beginner tutorials on how to program in C++ are really, really fundamentally stupid. The first thing they teach is always "okay, here's a preamble on how to set up a compiler so that you can start fiddling with hello world". That's not a good attitude. We're afraid of scaring them off, that if we talk about linkers and compilers that they'll run screaming for the hills, but I'm not sure I believe that. I think everybody who's ever made a computer program has had some fundamental interest in how things work. I also don't think that the compilation and linking process is actually pretty bloody simple when you break it down.

You know it wasn't until a couple of years ago that I actually grasped linking - It wasn't that it was some hard to understand process, it's that I fundamentally didn't understand how building programs worked. I assumed the compilation process was some arcane witchery that I could never grasp or understand without a ton of hardcore reading. I wish somebody had taught me how bloody simple it was sooner. It might've saved me hours of grief with linker errors.

5
General / Help understanding the tutorials?
« on: March 14, 2012, 12:36:26 pm »
Your problem is not really with SFML, in this case, your problem is that you don't seem to have a solid grasp of the compilation and linking process, so you don't know how to set things up.

This isn't really your fault. Compilation and linking is something I've never in my life seen a really good explanation of, and I think it's something that we don't learn early enough. So I'll attempt to do so here. I'll also try and explain the bugs you're encountering.

Enjoy.

----------------------------------------------------

Let's start abstract. What is a computer program?

A computer program is a file like any other. It's a string of data. Fundamentally, all computer files are exactly the same - There's no real difference between a text file and a music file and an executable file. Zeroes and ones are zeroes and ones. The distinction is in how that data is interpreted. Computer programs are strings of data designed to be interpreted as machine instructions. Data commands. Really raw instructions that your computer can follow. But it's not the code you write. The code you write is far, far different. If you've ever tried to open an executable in a text editor, this is something you can probably understand.

So, question. How does C++ code get converted into that raw binary machine code? How does hello_world.cpp become hello_world.exe?

The most common answer is "A program called a compiler turns your code into an executable". It's also, sadly, a misleading answer. It's not really a lie, it just leaves out a lot of important details. In some languages, you don't need to really know the details. C++, you do need to know the details.

First, I want to draw a distinction between an IDE and a Compiler Suite. An IDE is something like Code Blocks; Effectively little more than a glorified text editor. It has useful features like code highlighting and project management and all that jazz, but it doesn't make programs.

A Compiler Suite is something different. The keyword there is suite. Most people understand a compiler to be a single indivisible entity: A sort of black box where you put code in one end and executables pop out the other end. This is not how it actually works. Turning your source into a working binary is a multi-step process. The "correct" term for this is called the Build Process.

I'll try and break down the Build Process into its relevant steps.

The first step is called preprocessing. You know those #include lines? Those are preprocessor directives. An #include directive effectively copy-pastes code from one file into another. When you #include <iostream>, you could effectively take out that line and copy-paste the entire contents of the iostream header into your file, and it'd work exactly the same. The preprocessor is dumb. It's essentially a text filtering stage. But it's the first major step in the process.

The second major step is the actual compilation. This is where your preprocessed code actually gets converted into binary code. But that binary code, and this is the important part, is not actually your exe. What you get instead are object files, little packages of binary code. You generally get one for every source code file you have, every cpp file. But not header files. Header files exist purely to be copy-pasted into other files. They don't get compiled in and of themselves. Most of the errors you get when you build a program are in the compile stage. If you leave out a semicolon somewhere, it's the compiler that bitches at you.

Now, the final step is the most critical. It's called linking.

When you write a computer program, in 99.999% of cases, you're using code written by other people at some point. When you use cout, or vectors, or strings, or all of the other functions that "Come with" C++, you're making use of the "Standard Library". When you want to use SFML's functions for creating a window or drawing an image or (my personal favourite) sending data over a network, you're using the "Simple Fast Media Library". The key repeating word there is Library.

The binary code that your compiler outputs when it builds your program, that's the binary for the code you wrote. But what about the binary code for the stuff everybody else wrote?

The purpose of the linker is to gather up various bits of machine code, various object files and libraries, and stick them all together. This process is called linking, and the result is an executable file that you can actually run.

So you already know where your machine code is. It's the object file your compiler produces. So where is everybody else's machine code?

Well, that depends. Let me draw a distinction here between Dynamic Libraries and Static Libraries. A static library is object code (binary code) that's directly linked into your executable. When you link your program with a Static Library, all of that library's machine code is right there in the executable. SFML's static lib files are called lib-sfml-library.a, with "library" being replaced with "graphics" or "network" or "audio" or some such.

Dynamic Linking is different. See, programmers are smart. Once upon a time, somebody realized that, really, there's some machine code that's going to be used by a lot of people. When you print text on the screen, you're probably not the only program that needs that functionality. When you draw images on the screen, you're not the only program that needs that functionality. Indeed, there's a whole ton of functionality that's used by a lot of programs! A Dynamic Library is effectively this. It's a file which is actually a lot like an executable - It's binary code which is run when needed, and many programs can use it.

So where ARE these files? These are Dynamically Linked Library files. The acronym for that is DLL, and you're probably familiar with them. They're all over the place. The place you see them most is probably in your windows/system32 folder. That makes sense - There's certain binary code that a lot of windows programs use! It makes sense to put them all in one place. SFML's library files are sfml-library.dll, with, again, library usually being graphics or network or audio or system or what have you.

So now, let's steer back to your particular issue. Let's take your questions one by one.

The reason it says "your executable's directory" is because, if you link your program with dynamic libraries.. your program needs to know where those dynamic libraries are! It can't just go over your entire computer and look in every folder for sfml-system.dll. So it looks in a few key places. The first place it looks is in the folder with your executable. Actually, when you run the program from codeblocks, you're usually running the executable from your PROJECT'S folder, so that's where it'll look first. Incidentally, codeblocks has a special name for the location of your Project's folder - They call it your PATH variable. A path is another name for a string representing a folder on your computer. C:\ is a path. C:\Windows\system32 is a path. C:\Documents and Settings\VPellen\My Documents\Project Dream is a path. If that's confusing, let me know, I'll try and reiterate.

Oh, and, incidentally, there are certain folders which all the executables on your computer look in for DLLs, like your windows folder and your system32 and a few others. Those folders are defined in the Path environment variable on your computer - NOT to be confused with the Path environment variable in codeblocks, although they're called "path" for the same reason. You can modify your computer's Path environment variable in your computer's system properties, but DON'T DO THAT UNLESS YOU KNOW WHAT YOU'RE DOING - imagine what would happen if suddenly none of your programs could access all the DLLs in your system32 folder. It wouldn't be pretty.

Now, you're getting undefined reference errors. Those are linker errors. Effectively, your linker is saying "Hey, I was told to expect to find binary code for the function sf::Clock::GetElapsedTime() and a few other things, but I can't find them! That's not cool." So it spits out an error and tells you it can't link your program together.

My guess is that your search directories aren't defined properly.

When you list search directories, there are multiple tabs, for your compiler and your linker. Your compiler search directories should be the include directories for the libraries you want, because it's your compiler that uses the #include directive and such. Your linker search directories should be the lib directory, because that's where the libraries are contained.

Now there's another gotcha - Codeblocks has different "build targets". often, you want multiple "builds" of your program - a normal super fast build for when you publish your program, and a slower build called a "debug build" that lets you use debugging tools to help get rid of bugs in your program. When you're defining your include and lib directories, make sure you do it right for ALL THE BUILD TARGETS YOU NEED, not just one.

The only other thing that could be biting you in the ass is the -lsfml-system-s command - That SHOULD link your libraries, but again, make sure that it's in A: The linker options, and B: That it's set for the right target.

Tutorials are a lovely thing, but the problem is that they're often more concerned with results than education. I hope my rambling rant has been educational. If not, let me know and I'll try and clarify some things.

I'll probably go over this a few times and correct some typos, but I'll put it up now in case it's useful.

Good luck.

6
General discussions / Do you use C++11?
« on: March 13, 2012, 11:55:19 am »
I've spent the last few days cramming C++11 stuff into my brain. Very exciting. For those who want to get a better understanding of C++11, the following links have been extremely helpful for me:

http://www2.research.att.com/~bs/C++0xFAQ.html
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012
http://en.cppreference.com/w/cpp
http://code.google.com/p/mingw-builds/

In order, they are:

1) The C++11 FAQ written by Stroustrup himself
2) A recent event regarding C++11, lots of videos, VERY informative, if nothing else watch the keynote by Stroustrup on C++11 style
3) A C++ reference which contains some details on the newer C++11 libraries
4) Links to more up-to-date MinGW builds, for windows developers who aren't so fond of VC++. Look for 4.7, it's precompiled and should basically work as-is.

7
General discussions / Do you use C++11?
« on: March 11, 2012, 11:56:10 am »
Up until ten minutes ago, I'd been feeling kind of lukewarm towards C++11. I'd been curious, and I expected to take it up sooner or later, but nothing really forced my hand.

Ten minutes ago, I learned that C++11 supports member initialization in the class declaration, ie:

Code: [Select]
class C
{
    public:
        int x = 10;
};


I'm turning that compiler flag on, and I'm never going back.

8
Feature requests / TcpSocket::Avail()?
« on: March 10, 2012, 08:09:31 pm »
Because as far as I can tell, 99% of the security issues that sf::Packets have could be solved by allowing the server to dictate a max packet size.

As far as I can tell, all Receive(Packet) does is serve as a useful method of buffering network input so you can grab it all in one go. Its only(?) security flaw is the potential for memory leaks.

The exploit itself is simple, and you probably know it - Send a packet size of N, and then send N-1 bytes of garbage. The data gets stored in the temporary packet buffer, but because the server never receives a complete packet, the temporary packet just sits there taking up space. And this isn't really a problem with SFML's packets, it's a problem with any kind of buffered network input.

The real problem comes from the question of how much space the temporary packet can take up.

In practice, that's going to be the largest possible packet size, minus one. In the case of sf::Packets, the largest possible packet size on the server end is 2^32 (I think), or 4 gigs of data. That's a hell of a memory leak.

But if it were possible to dictate a maximum packet size, you'd be able to limit the size of the potential memory leak. If you set a maximum packet size of, say, 100 bytes, and the client tries to send a packet size of more than that, you can just cut him off. He can still cause a memory leak - It's just limited to 99 bytes. (Well, probably more like 128 if my knowledge of std::vectors is correct).

If you feel it's unnecessary or otherwise too much trouble to implement, that's fine - Honestly, I'll probably implement my own data handling anyway to maximize performance. But the ability to set a limit on incoming packet size would probably solve the single biggest security issue that sf::Packets have.

So, that's my sales pitch. Either way, I'm immensely appreciative of SFML. Makes my life far, far easier. Cheers.

9
Feature requests / TcpSocket::Avail()?
« on: March 09, 2012, 03:12:07 pm »
I skimmed the source, and apparently the answer to:
Quote
Does it just keep reading in data until the heap bursts?

.. is a resounding "Yes".

New feature request:

TcpSocket::SetMaxPacketSize()

10
Network / Can not connect TCP socket (to server)
« on: March 09, 2012, 02:21:36 pm »
Hmm.

Try running your client app and the server app on the same computer with the server IP being localhost. If that works, then the problem isn't SFML, but rather a router or network issue.

11
Feature requests / TcpSocket::Avail()?
« on: March 09, 2012, 02:16:16 pm »
Mainly premature optimization woes (I know, I know), but also for convenience. If you're expecting a specific number of bytes on a socket read, it's easier to do it in one go when you know all the bytes are going to be there. Thumbing through the network documentation, I noticed you keep a "Pending Packet" struct in the TCP Socket. It's that kind of thing: You wouldn't have to hold that data if you knew how much to expect.

The first solution, (internally reading everything into a buffer) is, from what I gather, what you already do for packets, which is a nice convenience, but doesn't offer the optimization benefits of not having to do a read unless you know the data's there.

If the only way the functionality could be implemented is with OS-specific calls, don't bother - I just wondered if there was a quick-and-easy solution, but apparently not.

Oh, and while we're on the subject - That pending packet in the TCP library. What happens if it receives a packet size of 0xFFFFFFFF? Does it just keep reading in data until the heap bursts? Or does it try to preallocate a gig of data in one sweep and then crash instantly? Or is there a third option?

If none of the above makes sense, assume that I'm not as educated as I think I am.

12
Network / Can not connect TCP socket (to server)
« on: March 09, 2012, 01:47:20 pm »
Are you running the server and client on the same computer?
Or on the same network?

13
Feature requests / TcpSocket::Avail()?
« on: March 09, 2012, 01:32:50 pm »
A method to check how many bytes of data are sitting in a TCP stream, waiting to be read.

My knowledge of TCP is a bit rusty: Is this one of those things that TCP "natively" supports? Are you able to, at any time, poll a TCP socket and find out how much data is sitting there, waiting to be read? Or is it one of those things that's dealt with on a far lower OS/hardware layer, and so the only way to implement it would be to create some kind of mid-layer buffer hodgepodge which would defeat the purpose of having the function in the first place?

14
Network / Can not connect TCP socket (to server)
« on: March 09, 2012, 01:15:48 pm »
Assuming that's directly copy-pasted:

Code: [Select]
ServerIP=sf::IPAddress(123, 456, 123, 456);// for example

Should probably be

Code: [Select]
ServerIP=sf::IPAddress(127, 0, 0, 1);// Connect to the local host

If you don't know what an IP Address is, it's basically your computer's location on the internet. "127.0.0.1" means "local host" or "this computer".

Pages: [1]