Posts by Tumlee

You're calling your Reverse() function over and over again, in a loop. This function doesn't have enough context to know exaclty what's going on and how to print things in the correct order.

What needs to be done, is you may have to generate the entire string, and then print it backwards after all the number crunching has been done.

Should I get ubuntu on my mac?

Is there a particular task that you want to accomplish on Ubuntu that you can't do on your current OS? It may not be worth the effort if you can do everything perfectly fine on your Mac as it is.

when you have a Mac you tend to have a wireless keyboard + mouse, which can be an issue.

I've used several different flavors of Ubuntu and all of my wireless keyboards and mice have worked completely out of the box with no issues.

Why not Linux Mint - it's much more user friendly and respect privacy better than Canonical's Ubuntu.

I've personally had many performance issues with Linux Mint. Specifically, turning the LCD brightness up and down causes the computer to completely freeze for a few seconds.

Because you're essentially looking at the least significant bit first, you're printing them first, and as a result, the number is being printed backwards.

A couple of notes here. The line rem = rem%10 more than likely does not do anything because the line rem=quotient%2 guarantees that rem will either be 1 or 0. The line quotient=quotient/2 may cause you to lose the first bit of your answer completely as well.

I'm not sure what the other answers looked like, but division and modulo may not be the best way to print this stuff out, especially in C where prepending to a string is not trivial. It may be a good idea to look into actual bitwise math operations.

To be perfectly honest, the main way I would improve that code is to completely get rid of the foo class. It only has one actually peice of data in it (input), and the only place that is used is in foo::mainPage(), so it could easily be made local to that function. If we were working in Java, we would be forced to put this sort of stuff in a class, but because we're working in C++, that's just extra code that serves no purpose.

Here's what I would probably do.

foo.cpp:

#include <iostream>
#include "foo.h"

//Use these parts of iostream so we don't have
//to litter the code with std::whatever.
using std::cout;
using std::endl;
using std::cin;

//Change the declarations of add() and minus() so they return
//an int, or whatever data type we want to work with.
int add() {
    //In a real program, this would have to take
    //some sort of input arguments, and then return
    //the addition of some values. In this example,
    //we'll just return 0 though.
    return 0;
}

int minus() {
    return 0;
}

void mainPage() {
    //Declare input here instead of in a class.
    int input = 0;

    //Loop this function until the user decides to exit, rather than
    //that wierd recursion thing we had going on before.
    while(input != 3) {
        cout << " " << endl;
        cout << "Welcome to main menu" << endl;
        cout << "1) Choice 1! ADD!" << endl;
        cout << "2) Choice 2! Minus" << endl; …

First code: You're calling mainPage() as if it belongs to the global scope. The way you've written your code, though, it actually belongs to your class foo. My best bet is, because of the context, it assumes you're declaring an implicitly-int function called mainPage() inside of both minus() and add(), and therefore complaining about multiple definitions.

You probably meant to have those functions be members for foo anyway, so try rewriting lines 5 and 11 as void foo::add() { and void foo::minus() { respectively.

Second code: When you have an inline function, it can't actually be linked like a normal function. As a result, any code that uses foo::mainPage() must be able to see its full source or you will get undefined refernece errors. In order to mitigate the errors, you would actually have to move your inline function to "foo.h".

On a side note, this code shows very bad flow. You're calling mainPage() from add() and you're calling add() from mainpage. You're basically causing your function to recurse, possibly indefinetely, based on user input. It may be a much better idea to use a real loop inside of mainPage() and just return normally from the other functions.

Given that the code uses the C++ standard library and c++ only features such as templates, I rather suspect that this is making use of the g++ extension that allows VLAs in C++. It certainly won't compile as C :)

You're right. I guess that's what I get for skimming over code instead of reading all of it!

Ancient Dragon: Are you sure you're compiling as C and not C++? There are no VLAs in C++.

You're erasing elements by position rather than by value. Once you start erasing values like that, you can't expect v[number] to be equal to number anymore. A better solution to this problem would be to have an array of bool keep track of which numbers can be prime, and which numbers can't. Instead of removing values from an array, you would just set them to false.

Does anyone know if ubuntu is good for programming?

It depends on what you're programming. For the most part, programming something in Linux is simpler than programming it in Windows, just because libraries are handled by a package manager rather than having to go through the tedious process of manually copy/pasting includes and libs directories.

That being said, if you're using a Windows-only library like DirectX, you may be SOL on Linux.

Is it good for game development?

If you don't want an audience to play your games, sure.

You would make the fuction virtual, which allows you to override the behavior of a function when defining the child class. It should be as simple as changing void set_dimensions() as virtual void set_dimensions() in your shape2D class, and then rewriting shape3D::set_dimensions() to accept all three dimensions.

There may also be a way to call overridden virtual functions in a child class, but it's been so long and I have so little use for it that I don't remember how to use that feature anymore.

When you pipe two programs together via the shell, it actually just pumps the stdout of the program on the left into the stdin of the program on the right. There is no real need for calling pipe() inside your program in this case.

For example, if I wrote the following program:

#include <stdio.h>
#include <ctype.h>

int main(void)
{
    int c;

    while((c = getchar()) != EOF)   //Gets a character from stdin, while there are some left.
        putchar(toupper(c));        //Make it uppercase, and then print it to stdout.

    return 0;
}

And then I named that program "MyUpper", I would just run it like so:

echo "testing" | ./MyUpper

And I would get the output "TESTING"

The for_each and lambda is clearly superior in the solution of this task. plain and simple ))

Why? for doesn't even require you to write a function.

Because that's not the syntax for range-based for loop. I can't imagine it would work with for_each either because you're iterating through strings, and your add() functions operates on and int.

Is there any particular reason you're using for_each when you already have C++11's range based for loops available? Is it part of an assignment that your add() function has to exist? The following would be easier.

for(auto& i : vec)
    i += 2;

for(auto i : vec)
    cout << i;

main.c:7:6: error: 'i' undeclared (first use in this function)
main.c:7:13: error: 'y' undeclared (first use in this function)
main.c:9:3: error: 'x' undeclared (first use in this function)
main.c:11:2: error: 't' undeclared (first use in this function)

Is this memory efficient to split things up for developer "ease-of-use"?

Even if it wasn't, it doesn't matter. Code maintainability and readability is a lot more important than shaving off a few bytes here and there. Your time as a developer is a worth more money than a few processor cycles.

Another way to print the values pointed to by the vector is to use C++11's new range-based for loops (if you have an up-to-date compiler). This way, you don't even have to declare your own iterator.

for(auto ptr : ptrList)
    cout << *ptr << endl;

That's quite a bit of difference, especially if there are thousands of nodes in the linked list.

But don't compilers typically like to pad structs so that they are aligned a certain way (Like making the size a multiple of four)? Assuming an environment where sizeof(int) == 4 and the size of a pointer is four, wouldn't the latter struct have three bytes of padding on the end, making them effectively the same size?

That being said, the one without the char* is more desirable. Having an extra pointer like that just means more to allocate, more to clean up, and more to dereference.

What exactly is Vvariant supposed to be? It's impossible to get the value of a void* (without typecasting it first), and it's dangerous to dereference a pointer that is NULL.

You would be right. Arrays decay into pointers when you use them in a name context.

He means this sounds like a homework assignment, and we don't do those for people. You actually have to show some sort of an effort towards solving the problem.

Because you're recursively calling printtree(), this means you're also calling fopen() over and over again. As a result, you're overwriting the file every time you print something to it. (The file handle is also not getting closed properly.

I would suggest opening the file outside of printtree(), and modifying the parameters of printtree() so it accepts a FILE* as its second argument, which will represent which file the contents get printed to.

You're using strlen() incorrectly. It doesn't take an int, it takes a const char*.

The way you have your code written, it might be easier to simply count, one by one, how many characters there are by counting them as you print them, using textLength as a counter.

if(file)
{
    while((c = getc(file)) != EOF)
    {
        textLength++;
        putchar(c);
    }
}

You're spoonfeeding the answer to what is clearly a homework assignment to somebody who doesn't want to do any of the programming themselves. This is the reason so many people can get CS degrees without even knowing how to do FizzBuzz. I hope his professor is at least smart enough to mark him down for void main() when he turns this one in.

NathanOliver: There is actually a getline() for std::string as well. istream& getline (istream& is, string& str);

Modern compilers should error out if you don't properly cast the literal:

I was under the impression that whether or not you had to cast the literal depended on whether you were using C or C++. Has something changed in C11 that I'm not aware of?

Are you doing this in an initialization context? Because if you do something like the following declaration:

int *ptr = 12;

It probably will not error, but instead make ptr point to the (probably invalid) memory location of 12. Otherwise, I'm absolutely baffled that no error occured.

jwenting: In India, schools have unfortunately standardized around Turbo C/C++.

As a general rule of thumb, if your program can be "optimized" by changing one little operator like that, then the compiler will likely do it for you.

That being said, the short-circuiting behavior mentioned by deceptikon is important to note. Using the && operator ensures that unnecessary checks are skipped if the left operand is false (because this automatically makes the entire expression false). This could potentially mean that bitwise & would be slower in some cases.

Your usage of one-letter variable names, which are all declared at the very top of your main() function, has your program nearly impossible to read, let alone debug. You need to provide descriptive variable names if you want your stuff to be self explanatory. Do you seriously think it's good practice to have a variable called count and another one called count1? How on earth do you expect not to get those confused? I'm not suprised at all that you have an untrackable bug in your program.

PS: I see that a lot of people are already familiar with C++11 to the point that they don't think about it when they use its features. Is it now considered 'best practice' to use the new features? I am mainly concerned due to the lack of universal support for it and the fact that some C++ programmers have yet to learn the changes so I fear that C++11 code may not be understood.

I would consider it 'best practice' in most circumstances. C++11 is practically two years old now and a lot of its feature set was known before it even officially became a standard. If people can't compile C++11 code now, it's because they're using some really old crap like Turbo C++ or dev-c++ or whatever. I can't think of a modern compiler that doesn't support a majority of its feature set.

At lines 33 and 38 your formal parameters are floats but you call the function using doubles - you can fix this by changing floats to doubles ( ex: 5.5 to 5.5f ) or simply change the parameter's type from the methods's header.

Doubles are automatically converted to floats when needed, and vice-versa. This is not necessary.

You've got the right idea, but overloading really isn't polymorphism at all.

The while statement is a loop that contininues to execute until some condition is met.

I think you meant to say a while statement is a loop that continues to execute while some condition is met.

The problem is on this line: LH = 0x0120DE13 + 1;
This should instead be: LH = 0x0120DE13 + i;

I personally use CMake myself for all of my projects. It's a really simple build system and it avoids all the boilerplate that you have to go through when writing a Makefile manually. If you're a FOSS purist, though, keep in mind that although CMake is open source software, it's technically not GNU. ;)

Let's start off with the obvious:

do {
    cout << "Player " << player << endl;
      do {
          cout << "Enter row: ";
          cin >> row;
          cout << "Enter column: ";
          cin >> col;
         } while (board[row][col] != ' ');

This piece of code is unreliable and may invoke undefined behavior. You are checking board[row][col] and you don't actually know if row or col are actually in the array's bounds. If the user enters -1 for both answers, it will check against board[-1][-1], and you're just reading junk data at that point so it could be anything. Make sure you validate the user's chosen coordinates before you start reading and writing against board[row][col].

One, I cant figure out how to tell if there is a diagonal win.

Think it out logically. There are only two ways to win diagonally. A corner, the middle, and the opposite corner have to be matching AND they have to not be empty spaces.

And second I want to make the output prettier. If there a O or X then i want an asterisk in the space,

If you want spaces to be printed as asterisks, modify your displayBoard() function so that when it detects a space, it prints an asterisk instead.

I would also like to include the lines like a regualr tic tac toe board has

You'll pretty much just have to ASCII-art that out simliar to what you did in the first post, and …

What you would do is
1) Prompt them for the row number via cin (in the range of 1-3 if you're going for easy human interface, or 0-2 if you're lazy :P )
2) Validate the input to make sure it's within the acceptable range, and repeat step 1 if the input is invalid.
3) Repeat steps 1 and 2 for column.
4) Change the symbol at the given row and column to either an X or an O, depending on whose turn it is.

From there, it's just turning your thought process into actual code. Is there some concept in C++ that you don't quite understand how to do, that's preventing you from doing this?

In the main, I try to print the the elements of sArray1 using sArray. It doesn't work.

I don't see you trying to print anything anywhere.

One is, is sizeof(char *) supposed to be size 8?

It should be, provided you're writing a 64-bit application.

And also, when I look at the elements of list, list[0] is empty, list[1] and list[2] have something in it, and list[3] is invalid.

We would have to actually take a look at where you're initializing the individual elements of list to be able to tell you why that is. Perhaps somewhere, you're accidentally initializing an element ahead of where you should be, and this might not immediately cause your program to terminate, suprisingly enough.

Out of all of the IDEs I've tried, I prefer Code::Blocks the most because it's the most minimalist of the modern IDEs while still giving me the features I need in order to develop larger projects (being able to quickly find the delcaration of a variable or definition of a function very useful).

MSVC feels far too bloated and slow for my needs. The GUI takes up too much space that could be used for actual coding. I will avoid any editor which tries to red-squiggly-underline my code before I'm finished writing it. Furthermore, I find the project options menus in MSVC insanely hard to navigate.

Generally, it's a good idea not to absolutely depend on an IDE, mostly because there's no guarantee you'll have access to it if you ever move to a different operating system. That's why I think at least a little bit of knowledge in CMake is nice.

It depends on the operating system you're using. In Windows, the _mkdir() command does what you need. For Unix, see http://linux.die.net/man/2/mkdir .

You can't just make your thunderball animation a while loop. When you have that loop going, no other code outside of that loop will execute, and this is likely the reason your character freezes on screen every time you shoot a bullet.

If you want these things to happen simultaneously, you need one, gigantic loop that will encompass both the code for your character, and the code for the projectile. Basically, it will end up looking something like this:

while(1) //Or whatever condition you want the loop to have.
{
    //Code to make your character move little bit...
    //Code to make your projectile move a little bit, if it exists...
    //Code to draw your stuff onto the screen...
    //Code to have a little delay, so your program doesn't run insanely fast.
}

Essentially what you will have written at this point is your standard game loop.

Years ago I picked up the habit, I don't know where from, of always using

#define NUL char(0)

for 0 terminators in ASCII strings, and NULL for pointers.

I wouldn't recommend that at all, and to be honest I don't see the point of using macros for such things anymore in C++. If you want an int to be zero, use 0. If you want a char to be a terminator, use '\0'. If you want a null pointer, use nullptr (or use NULL if you're using C or have to compile for something older than C++11). To me, it only makes sense to write exactly what you mean when writing code.

For some reason, I am able to run the first program without any issues whatsoever, which absolutely baffles me because looking at it, it probably should crash. You create a pointer called pr1 which is supposed to point to a linkedlistchain, but you never initialize it nor set it to point to anything. Your insert() function calls the isEmpty() function, which in turn reads memory that doesn't belong to your program, crashing it. That's my best guess.

The reason your second program runs without any issues if obvious. You can read the value of ptr no matter what it is, whether it's NULL or pointing to valid memory. If you try to write to that address or dereference it, that's when you start to get problems if it doesn't point somewhere valid. Adding the following line to your second program will probably cause it to crash:

cout << "The value of *ptr is" << *ptr << endl;

Wouldn't specifying what "belongs to" the namespace also be considered "defining" the namespace?

I was more trying to clarify that there isn't one single place where a namespace is "defined" like there is for a variable declaration or a function definition. Using the word "define" could stir up a little bit of confusion here because let's say instead of <iostream>, we only included <string>. Suddenly the std namespace has a different "definition"! That's why I think using the term "belongs to" is much more clear.

Namespaces have to be defined somewhere, and once again it's splitting hairs to say that "resides in" doesn't equate closely enough to "defined in" to have identical meaning.

I'm not making a distinction between "defined in" and "resides in" in this case, I was simply stating that it's not required that a namespace has to be in a header, which is true. You can put namespaces in your cpp files if you want.

std namespace is defined inside the header

Nope, that's not how it works. The std namespace isn't "defined" anywhere. All the namespace std {...} stuff is saying is that the stuff contained in the brackets belongs to the std namespace.

"deceptikon" I thought that header files are reside in the namespaces and not vice versa.

Header files and namespaces are two completely seperate concepts. One doesn't "reside" in another. Header files are for including certain information that is required to compile whatever you are compiling. Usually things like type definitions, functions prototypes, and extern declarations go inside of header files. Namespaces are mostly just there to prevent naming conflicts.

Are struct names supposed to be defined somewhere else?

Yes. When you declare a variable that is an instance of usb_device_id, you must first tell the compiler somewhere else what a usb_device_id is. If you have already written a declaration of this struct, we might have to see it so we can further identify the problem.

You're accessing your arrays incorrectly. When you have an array declared as int num[2], num[0] is your first element and num[1] is your second element. You're passing values of &num[1] and &num[2] to the scanf() function.

As a result, when you think you're entering your first number, you're actually entering the second number. When you think you're entering your second number, you're writing to something beyond the edges of the array and are probably overwritting opcode as a result. If this gets overwritten to something outside of the range of 1 through 4, no answer will be displayed on your screen.

The problem is that by declaring a function in Derived that is the same name as the virtual function you declared in Base, you are actually hiding the original function that you declared in Base. These are little-known rules but they are rules nevertheless. When you have a function that takes two ints instead of one, as far as the compiler is concerned, the virtual function that only takes one argument no longer exists.

You can actually circumvent this behavior by adding using Base::SomeFunction; in the declaration of Derived.