What Do You Need Help With? V6

[Tamschi]

My two cents: Offer both device independent units (e.g. meters) and pixels, but the latter only for 2D. When you output, have the DIU units scale accordingly but keep device dependend ones absolute.

While working with a physics engine, it could make sense to include a configurable conversion factor, the recommended size is usually something that works with normal gravity acceleration when set to 9,81 m/s², but that doesn't mean you can't scale the whole system and still have it work reasonable. (Unless there's something really weird about the physics engine, like a spatial hashing algorithm that has a constant, not configurable grid size.)
Afaik it's a trade-off between object accuracy and level size, i.e. small object too far out or moving too fast will become inaccurate.

Always radians, not degrees, due to them making much more sense mathematically. Afaik the hardware accelerated functions only take radians too, so it's probably somewhat faster if you do a lot of calculations in that vein.

If the vector layout is guaranteed to be the same and the cast is just a reinterpret one I'd probably go with the implicit conversion. If it's not and you pass them around a lot you could unwittingly introduce bottlenecks, so in that case I'd offer global method overloads (ToSFML, ToBox2D...) that handle the conversion.

[nixnax123]

#include <iostream>

using namespace std;

int main() {

	int input, sum(0);

	for (short int i = 0; i <= 9; i += (isdigit(input))) {

		cout << "Enter an integer: ";
		cin >> input;
		sum += input;
		cout << i << "\n";

	}

	cout << sum << "\n";
	return 0;

}

Why does i never increment, even if (isdigit(input)) is 1?

[Jookia]

You don't initialize i.

Edit: Oops. Tired.

[jalb]

[QUOTE=NixNax123;43287522]Why does i never increment, even if (isdigit(input)) is 1?[/QUOTE]

According to [url=http://www.cplusplus.com/reference/cctype/isdigit/]this[/url], isdigit returns "A value different from zero (i.e., true) if indeed c is a decimal digit." I'd be cautious assuming isdigit returns a 1 or 0.

Also, you're reading in input as an integer, not a character. isdigit() works off a characters.

isdigit('5') = true
isdigit(5) = false

You could change your code so that input is a "char" type instead, but then the line "sum += input" would not work. You would have to convert the character to an integer.

[marvincmarvin]

How well is c++11 supported in linux and osx? Don't I need to install another c++ run-time as well?

[Joseph Clover]

[QUOTE=NixNax123;43287522]

#include <iostream>

using namespace std;

int main() {

	int input, sum(0);

	for (short int i = 0; i <= 9; i += (isdigit(input))) {

		cout << "Enter an integer: ";
		cin >> input;
		sum += input;
		cout << i << "\n";

	}

	cout << sum << "\n";
	return 0;

}

Why does i never increment, even if (isdigit(input)) is 1?[/QUOTE]

May I recommend some code I wrote as an alternative? It should do as proposed in your code:

#include <iostream>

using namespace std;

int main() {
	
	int i = 0;
	int input;
    	int sum = 0;

	do {
		cout << "Enter an integer: ";
		while( !(cin >> input) ){
			cin.clear();
			cin.ignore( 256, '\n' );
			cout << "Invalid input, try again: ";
		}
		sum += input;
		i++;
	}while( i <= 9 );

	cout << sum << "\n";
	return 0;

}

[jalb]

[QUOTE=marvincmarvin;43287788]How well is c++11 supported in linux and osx? Don't I need to install another c++ run-time as well?[/QUOTE]
I'm not sure about the runtime. C++11 is supported really well in GCC and Clang compilers. Better than VS anyway...

[Joseph Clover]

Yeah, the G++ Compiler supports C++11 Standard very well.

[cra0kalo]

Hey need help with something.

-snip- solved :D TY wincat

[Gmod4ever]

Okay, I have no idea what I am doing. Never really used classes in C++ before.

I am using SFML, and long story short, I want to make the game window (of class sf::RenderWindow) be accessible program-wide, through the means of accessors, so that I have to explicitly use a setter to change it.

I looked around, and it seems that a class of static methods would be what I want. However, I am getting a problem.

Please keep in mind I have never really created classes in C++ before:

[b]GameGlobals.h[/b]

#include <SFML/Graphics.hpp>

class GameGlobals {
private:
    static sf::RenderWindow gameWindow;
    GameGlobals() { } // Uninstantiable.

public:
    static sf::RenderWindow getGameWindow();
    static void setGameWindow(sf::RenderWindow);
} ;

[b]GameGlobals.cpp[/b]

#include <SFML/Graphics.hpp>
#include "GameGlobals.h"
// class GameGlobals

// Declare private attributes
sf::RenderWindow GameGlobals::gameWindow;

// Declare methods
sf::RenderWindow GameGlobals::getGameWindow() {
    return GameGlobals::gameWindow;
}

void GameGlobals::setGameWindow(sf::RenderWindow window) {
    GameGlobals::gameWindow = window;
}

When I compile, in CodeBlocks using GNU G++, I get an error stating that sf::NonCopyable is private, and get redirected to the "NonCopyable.hpp" showing that it is, indeed, private.

I do not know what I am doing. If someone can help me out, that'd be great. :v:

[WTF Nuke]

[QUOTE=Gmod4ever;43300526]Okay, I have no idea what I am doing. Never really used classes in C++ before.

I am using SFML, and long story short, I want to make the game window (of class sf::RenderWindow) be accessible program-wide, through the means of accessors, so that I have to explicitly use a setter to change it.

I looked around, and it seems that a class of static methods would be what I want. However, I am getting a problem.

Please keep in mind I have never really created classes in C++ before:

[b]GameGlobals.h[/b]

#include <SFML/Graphics.hpp>

class GameGlobals {
private:
    static sf::RenderWindow gameWindow;
    GameGlobals() { } // Uninstantiable.

public:
    static sf::RenderWindow getGameWindow();
    static void setGameWindow(sf::RenderWindow);
} ;

[b]GameGlobals.cpp[/b]

#include <SFML/Graphics.hpp>
#include "GameGlobals.h"
// class GameGlobals

// Declare private attributes
sf::RenderWindow GameGlobals::gameWindow;

// Declare methods
sf::RenderWindow GameGlobals::getGameWindow() {
    return GameGlobals::gameWindow;
}

void GameGlobals::setGameWindow(sf::RenderWindow window) {
    GameGlobals::gameWindow = window;
}

When I compile, in CodeBlocks using GNU G++, I get an error stating that sf::NonCopyable is private, and get redirected to the "NonCopyable.hpp" showing that it is, indeed, private.

I do not know what I am doing. If someone can help me out, that'd be great. :v:[/QUOTE]

I understand what you are trying to do, and that is create a singleton. Before we continue, you have to ask yourself why you really need a singleton. I've worked a lot before with SFML and never have I needed to use a global RenderWindow. An easy solution is to just pass it as a parameter to wherever it is needed. The error arises from this line:
[cpp]GameGlobals::gameWindow = window;[/cpp]
You are trying to copy the data from one RenderWindow to another. That is impossible as the creator of SFML has made RenderWindow uncopyable. This makes sense, as then you would have duplicate RenderWindows, and there would be a lot of other memory mismanagement and errors. What you would want to do is have a pointer to a RenderWindow. However, the fact that this method exists makes me question if you understand what you are doing. I assume you are migrating from C#. In C++, variables are passed by value, not by reference. That means that whenever you have a parameter such as the one for this method, you are copying the value of whatever you are passing rather than passing the object itself. Therefore, you would want to pass either a reference or a pointer, whichever one would work better.

The issue is that your class doesn't make sense. I assume you want to write a wrapper of sorts for a global RenderWindow. However, the fact that you are setting the RenderWindow means that it is not global. If you are setting a RenderWindow rather than letting the class manage it's own, you will cause leaks and issues down the road. Instead you would simply just want a global RenderWindow. Why not do that instead? Have a global RenderWindow variable. This will solve all your issues. However, this is also bad design and before you go down this path I want you to think carefully if you really need a global or if passing it by parameters will do.

[robmaister12]

So I just started working on a LINQ-esque system of generating AreaFlags (with only two options at the moment - walkable and null) for all the triangles in a mesh. A lot of it was hacked together and there's basically no documentation yet, I just got it to work with the public API I wanted:

AreaFlags[] areas = AreaFlagsGenerator.From(levelTris, levelInds).Where(tri => tri.A.Y > 0 && tri.B.Y > 0 && tri.C.Y > 0).IsWalkable().Create();

I'm not directly using LINQ because I don't want to directly add to or modify the source data, I simply want to iterate over the source data and modify the resulting array. Here's what I have so far:

[url]https://github.com/Robmaister/SharpNav/blob/master/SharpNav/AreaFlagsGenerator.cs[/url]

I know that I can at the very least remove the whole *Query inheritance thing and just modify the IEnumerable and I could probably find a fancy way of doing indexing that avoids the whole Tuple thing, but is there an overall better way of doing this? Maybe something with an expression tree or (if it's as fast/faster) building an IEnumerable<AreaFlags> and at the end converting that to an array?

[Party Boy]

Anybody able to help with this

[url]http://stackoverflow.com/questions/20771444/refilling-a-blockedqueue-in-java[/url]

[ZeekyHBomb]

[QUOTE=Over-Run;43303627]Anybody able to help with this

[url]http://stackoverflow.com/questions/20771444/refilling-a-blockedqueue-in-java[/url][/QUOTE]

Refill it with what?
Surely you don't just want random data?

[nixnax123]

int main() {

	int input[10], smallest(0);

	for (short int i = 0; i <= 9; i++) {
		cout << "Enter an integer: ";
		cin >> input[i];
		if (i = 0 || input[i] < smallest) smallest = input[i];
	}

	cout << "The smallest of these integers is: " << smallest << "\n";
	return 0;

}

why isn't i incrementing

[mobrockers]

[QUOTE=NixNax123;43305907]

int main() {

	int input[10], smallest(0);

	for (short int i = 0; i <= 9; i++) {
		cout << "Enter an integer: ";
		cin >> input[i];
		if (i = 0 || input[i] < smallest) smallest = input[i];
	}

	cout << "The smallest of these integers is: " << smallest << "\n";
	return 0;

}

why isn't i incrementing[/QUOTE]

if (i = 0 || input[i] < smallest) smallest = input[i];

i is always set to 0 there.

[nixnax123]

OH GOD DAMN YOU DOUBLE EQUAL SIGNS

[mobrockers]

Also why do you use a short int?

[editline]25th December 2013[/editline]

Seems rather pointless unless you're working on extremely limited systems, no?

[nixnax123]

Just trying to work on optimizing in practice so its ingrained in my mind

Also someone tell me something to program really I have no ideas

[mobrockers]

[QUOTE=NixNax123;43306207]Just trying to work on optimizing in practice so its ingrained in my mind

Also someone tell me something to program really I have no ideas[/QUOTE]

Wouldn't the compiler optimize for you???

I don't have much understanding of (what looks like) c++ but I thought it did that.

[ZeekyHBomb]

A short is going to stay short and an int is going to stay int.
Otherwise you could easily break interfaces and it would be harder to specify data structures with fixed fields (but for this you should use stdint.h or inttypes.h anyways).

And though while a short can take up less memory than an int, in general a register is of size int, which is bigger than a short, meaning that the binary can become less efficient because it will have to mask out the more significant bits for the short when operating on it, while it needs no extra instructions for the int.

[backwardspy]

[QUOTE=NixNax123;43306207]Just trying to work on optimizing in practice so its ingrained in my mind[/QUOTE]
This is exactly what you [I]don't[/I] want to be concerning yourself with at this stage.

[nixnax123]

[QUOTE=Chris220;43306971]This is exactly what you [I]don't[/I] want to be concerning yourself with at this stage.[/QUOTE]

can i ask why
keep in mind i always get a program working first and then optimize it

[mobrockers]

[QUOTE=NixNax123;43307222]can i ask why
keep in mind i always get a program working first and then optimize it[/QUOTE]

Write good code first, then optimize if necessary.

[Tamschi]

[QUOTE=NixNax123;43307222]can i ask why
keep in mind i always get a program working first and then optimize it[/QUOTE]

It's usually unnecessary or has negative benefit (more complications than what you gain through the speed-up). Sometimes (like when using a number type smaller than the native one while there's no memory issue) it even slows down the program.

If you do optimization, always check the performance before and after, or it's likely you make it slower instead.
That way you can also just get the exact points that take too long and optimize them with a fraction of the effort.

[Jookia]

Changing data types from int to short isn't going to optimize your program. Changing algorithms will.

[Tamschi]

[QUOTE=NixNax123;43305907]

int main() {

	int input[10], smallest(0);

	for (short int i = 0; i <= 9; i++) {
		cout << "Enter an integer: ";
		cin >> input[i];
		if (i == 0 || input[i] < smallest) smallest = input[i];
	}

	cout << "The smallest of these integers is: " << smallest << "\n";
	return 0;

}

[note: fixed][/QUOTE]

In this case I'd probably even move the first iteration out of the loop, so that you only loop from [I]i = 1[/I] to [I]9[/I]. It really makes no sense to get the smallest value if there is no first and you avoid a nonsensical initialization of [I]smallest[/I] that way. ([I]i == 0[/I] is not necessarily good design here, or in most places it shows up.)

Using [I]< 10[/I] instead of [I]<= 9[/I] is more clear. Excluding equality also prevents an infinite loop that can occur if the upper limit is the max value of that number type. (If it's dynamic more example.)
If I really needed to include the max value I'd probably loop with [I]do {...} while (...);[/I] instead and keep the absolute [I]<[/I].

I'm also fairly sure you can use the array size in the loop condition here (because the array is a fixed size local one), writing 10 (or 10 and 9) in two places is duplicated configuration and should be avoided because the program can break if one changes without the other.

[nixnax123]

[QUOTE=Tamschi;43307502]In this case I'd probably even move the first iteration out of the loop, so that you only loop from [I]i = 1[/I] to [I]9[/I]. It really makes no sense to get the smallest value if there is no first and you avoid a nonsensical initialization of [I]smallest[/I] that way. ([I]i == 0[/I] is not necessarily good design here, or in most places it shows up.)

Using [I]< 10[/I] instead of [I]<= 9[/I] is more clear. Excluding equality also prevents an infinite loop that can occur if the upper limit is the max value of that number type. (If it's dynamic more example.)
If I really needed to include the max value I'd probably loop with [I]do {...} while (...);[/I] instead and keep the absolute [I]<[/I].

I'm also fairly sure you can use the array size in the loop condition here (because the array is a fixed size local one), writing 10 (or 10 and 9) in two places is duplicated configuration and should be avoided because the program can break if one changes without the other.[/QUOTE]

thank you for clearing up a lot of confusion I had about whether to use equality or not.

how does this code look?

#include <iostream>
#include <array>

using namespace std;

int main() {

	array<int, 10> input;
	int smallest;

	cout << "Enter an integer: ";
	cin >> input[0];
	smallest = input[0];

	for (int i = 1; i < input.size(); i++) {
		cout << "Enter an integer: ";
		cin >> input[i];
		if (input[i] < smallest) smallest = input[i];
	}

	cout << "The smallest of these integers is: " << smallest << "\n";
	return 0;

}

[Tamschi]

[QUOTE=NixNax123;43307825]how does this code look?

[/QUOTE]
 
In my opinion it's clearer, I just don't like the separation of 

int smallest;
[...]
smallest = input[0];

 that much (personally) because the variable's value is undefined between the statements (if I'm not entirely wrong about C/C++).

I usually introduce variables only at the first assignment if possible, but the compiler should raise an error if you try to read it in that state.

[nixnax123]

[QUOTE=Tamschi;43309303]In my opinion it's clearer, I just don't like the separation of

int smallest;
[...]
smallest = input[0];

that much (personally) because the variable's value is undefined between the statements (if I'm not entirely wrong about C/C++).

I usually introduce variables only at the first assignment if possible, but the compiler should raise an error if you try to read it in that state.[/QUOTE]
Good point!
I love learning how to write code better. Thank you SO MUCH. C: