What Do You Need Help With? V6

[Dreyzie]

Hey, guys. I'm having trouble with this simple C++ assignment for school. We have to "Type the program exactly as instructed."

I'm new, so I have absolutely no idea what I'm doing.

I'm getting this error...

[quote]'feePayment' was not declared in this scope.[/quote]

// system defined header file that declares the input/output operations (cin/cout)
#include <iostream>

// Programmer defined header file containing declaration of StudentAccount class
#include "studacct.h"

using namespace std;

int main ( )
{
    // constructor for student Bob Lee has starting balance of $250
    StudentAccount student ("23-9812", "Lee, Bob", 250.99);

    // keyboard input for charge to the bookstore
    double bookCharge;

    cout << "Enter a bookstore charge: ";
    cin >> bookCharge;
    student.charge(bookCharge);
    cout << "After charge, balance is "
         << student.getBalance ( ) << endl;

         cout << "Enter a fee payment: ";
         cin >> feePayment;
         student.payment(feePayment);

         cout << "Current account information: " << endl;
         student.writeAccount( );

         return 0;
}

I've searched everywhere for that error message, but I still don't know what it means.

Do I need to include any more information? I was intimidated to post here because I'm new to this stuff.

[Cyberuben]

[QUOTE=simzboy;45921119]Hey, guys. I'm having trouble with this simple C++ assignment for school. We have to "Type the program exactly as instructed."

I'm new, so I have absolutely no idea what I'm doing.

I'm getting this error...

// system defined header file that declares the input/output operations (cin/cout)
#include <iostream>

// Programmer defined header file containing declaration of StudentAccount class
#include "studacct.h"

using namespace std;

int main ( )
{
    // constructor for student Bob Lee has starting balance of $250
    StudentAccount student ("23-9812", "Lee, Bob", 250.99);

    // keyboard input for charge to the bookstore
    double bookCharge;

    cout << "Enter a bookstore charge: ";
    cin >> bookCharge;
    student.charge(bookCharge);
    cout << "After charge, balance is "
         << student.getBalance ( ) << endl;

         cout << "Enter a fee payment: ";
         cin >> feePayment;
         student.payment(feePayment);

         cout << "Current account information: " << endl;
         student.writeAccount( );

         return 0;
}

I've searched everywhere for that error message, but I still don't know what it means.

Do I need to include any more information? I was intimidated to post here because I'm new to this stuff.[/QUOTE]

Above your "cin >> feePayment;" add a line saying "double feePayment;"

Edit:
Would still love for someone to help me with my physics issue further up.

[cartman300]

You didn't define feePayment that's used in "cin >> feePayment;"
Just add "double feePayment;" after "double bookCharge;"

Edit:

Ninja's everywere.

[Dreyzie]

[QUOTE=Cyberuben;45921154]Above your "cin >> feePayment;" add a line saying "double feePayment;"

Edit:
Would still love for someone to help me with my physics issue further up.[/QUOTE]Yep, that fixed it.

Thank you so much.

[proboardslol]

Beginning C. Never had to be conscious of memory usage. Why would someone need to use malloc()?

[Dienes]

[QUOTE=proboardslol;45924420]Beginning C. Never had to be conscious of memory usage. Why would someone need to use malloc()?[/QUOTE]

Whenever the exact amount of memory you need to allocate is not statically known at compile-time. For example when you want to load a file of arbitrary size into memory. You either tell the compiler to reserve a certain maximum limit of bytes (which might or might not be enough) or you determine the file size at runtime and use heap allocation (malloc, calloc, ...) to request the exact amount of memory then.

[proboardslol]

[QUOTE=Dienes;45925161]Whenever the exact amount of memory you need to allocate is not statically known at compile-time. For example when you want to load a file of arbitrary size into memory. You either tell the compiler to reserve a certain maximum limit of bytes (which might or might not be enough) or you determine the file size at runtime and use heap allocation (malloc, calloc, ...) to request the exact amount of memory then.[/QUOTE]

Can you think of a small example of using it in a situation where it would be needed? I understand the syntax, I just am not sure on any of its possible applications

[Dienes]

[QUOTE=proboardslol;45925186]Can you think of a small example?[/QUOTE]

[cpp]char buffer[256]; // The buffer to load the file into. The file cannot be bigger than 256 bytes.
int fileSize = ... // Determine file size at runtime
// char buffer2[fileSize]; // This does not work, because the compiler needs to know the value
char* buffer2 = calloc(fileSize, sizeof(char)); // This works[/cpp]

[proboardslol]

[QUOTE=Dienes;45925243][cpp]char buffer[256]; // The buffer to load the file into. The file cannot be bigger than 256 bytes.
int fileSize = ... // Determine file size at runtime
// char buffer2[fileSize]; // This does not work, because the compiler needs to know the value
char* buffer2 = calloc(fileSize, sizeof(char)); // This works[/cpp][/QUOTE]

When you say "at run time", does that mean that the moment the program opens in memory, it allocates this memory, or could the program open, get some sort of input, and THEN allocate the memory?

[Dienes]

[QUOTE=proboardslol;45925296]When you say "at run time", does that mean that the moment the program opens in memory, it allocates this memory, or could the program open, get some sort of input, and THEN allocate the memory?[/QUOTE]

The latter. The amount of memory can be fully dynamic. It is requested from the system the moment when the calloc call is being executed, not at compile-time and not at startup-time.

[Cyberuben]

I guess this isn't the place for complicated physics problems then :v:

[proboardslol]

[QUOTE=Dienes;45925310]The latter. The amount of memory can be fully dynamic. It is requested from the system the moment when the calloc call is being executed, not at compile-time and not at startup-time.[/QUOTE]

So this is for memory optimization? instead of having to, for example, create a 100x100 integer array for data that might only be 50x100, you can use, like:

int numOfFiles;
int (*p)[100];

scanf("Number of files, please: %d", *numOfFiles);

p = malloc(numOfFiles*sizeof(int));

//do some shit//

Would this be a situation where malloc would be useful? and to what extent can you use malloc to allocate memory to arrays, since I understand that arrays must be defined at compile time. I believe only the right-most dimension (or the left-most dimension) MUST be defined at compile time, while the others are variable

[Cold]

For example if you have a program that shows an image file on the screen.

You don't know beforehand how big the image is, you can do 2 things:

- Have a maximum image size, and just define the array using:
[cpp]
char buffer[MAX_SIZE];
[/cpp]
- Dynamically allocate memory using malloc and do
[cpp]
char * buffer = (char *)malloc(imageSize);
[/cpp]

[proboardslol]

Also, I was just playing around, and I noticed that the output of sizeof(int); and sizeof(long int); are the same (4). Why is this?

[Cold]

[QUOTE=proboardslol;45925356]So this is for memory optimization? instead of having to, for example, create a 100x100 integer array for data that might only be 50x100, you can use, like:

int numOfFiles;
int (*p)[100];

scanf("Number of files, please: %d", *numOfFiles);

p = malloc(numOfFiles*sizeof(int));

//do some shit//

Would this be a situation where malloc would be useful? and to what extent can you use malloc to allocate memory to arrays, since I understand that arrays must be defined at compile time. I believe only the right-most dimension (or the left-most dimension) MUST be defined at compile time, while the others are variable[/QUOTE]

Any time you don't know how big a buffer is going to be, malloc/realloc/free is useful.

[proboardslol]

[QUOTE=Cold;45925454]Any time you don't know how big a buffer is going to be, malloc/realloc/free is useful.[/QUOTE]

does using malloc and free constantly hurt performance at all?

[Cold]

[QUOTE=proboardslol;45925439]Also, I was just playing around, and I noticed that the output of sizeof(int); and sizeof(long int); are the same (4). Why is this?[/QUOTE]

The C++ standard only defines a minimum size, 4 bytes is enough to hold an "long int".
In visual studio its 4 bytes, in G++/Clang its 8 bytes i think.

The reason why sizeof(int) and sizeof(long int) is the same in visual studio, is because its a leftover from 16 bit systems.

Back then ints where 16 bits and long ints 32 bits, at some point in time ints where changed to 32 bits because processors where faster when working with machine-word sized integers.
And according to the C++ standard thats a valid change to make because it only defined a minimum size.

[BL00DB4TH]

[QUOTE=BL00DB4TH;45893198]Hey, does anyone here have any experience making a networked player controller in LOVE2D? I have no idea how to approach this. I don't want to be spoonfed code, just some theory as to what I should be doing.[/QUOTE]

No one? It doesn't have to be specific to love, any player controller networking theory would be helpful.

[Cold]

[QUOTE=proboardslol;45925485]does using malloc and free constantly hurt performance at all?[/QUOTE]

Yes it does, requesting memory from the OS takes quite some time.
Freeing is much less expensive.

Dynamically allocating memory is generally something you want to avoid as much as possible for real-time code.
Although its hard to avoid.

[proboardslol]

[QUOTE=Cold;45925503]The C++ standard only defines a minimum size, 4 bytes is enough to hold an "long int".
In visual studio its 4 bytes, in G++/Clang its 8 bytes i think.

The reason why sizeof(int) and sizeof(long int) is the same in visual studio, is because its a leftover from 16 bit systems.

Back then ints where 16 bits and long ints 32 bits, at some point in time ints where changed to 32 bits because processors where faster when working with machine-word sized integers.[/QUOTE]

So I should use a different compiler if I'm looking for maximum optimization, then

[DrTaxi]

[QUOTE=proboardslol;45925485]does using malloc and free constantly hurt performance at all?[/QUOTE]

Someone did a little [url=http://voices.canonical.com/jussi.pakkanen/2011/09/27/is-malloc-slow/]benchmark[/url] on that.

In any case, don't optimise your programs prematurely. It's easy to get lost in details of how to solve problems the fastest or most efficient, when often enough it just doesn't matter.

[proboardslol]

[QUOTE=DrTaxi;45925555]Someone did a little [url=http://voices.canonical.com/jussi.pakkanen/2011/09/27/is-malloc-slow/]benchmark[/url] on that.

In any case, don't optimise your programs prematurely. It's easy to get lost in details of how to solve problems the fastest or most efficient, when often enough it just doesn't matter.[/QUOTE]

Sorry, I'm just fascinated with memory usage and optimization. Low-level programming is amazing to me.

[DrTaxi]

[QUOTE=proboardslol;45925565]Sorry, I'm just fascinated with memory usage and optimization. Low-level programming is amazing to me.[/QUOTE]

Very well. Still, it's a good idea to get your programs [I]working[/I] first, then figure out whether they're too slow/big, what's making them that way and how to fix it.

[Cold]

[QUOTE=proboardslol;45925553]So I should use a different compiler if I'm looking for maximum optimization, then[/QUOTE]

No, just be aware how big "int" and "long int" etc is in your compiler.
Visual studio also defines __int8 __int16 __int32 __int64 if you want to be a 100% sure what you're actually working with.

Also the size of what you choose your variable to be is only important when you allocate memory/arrays.

Any variable sized smaller then machine-word will generally be optimized to be the size of a machine-word.
So inline bools/chars/shorts will pretty much always be optimized to 32 or 64 bit depending on your target.

[proboardslol]

[QUOTE=DrTaxi;45925577]Very well. Still, it's a good idea to get your programs [I]working[/I] first, then figure out whether they're too slow/big, what's making them that way and how to fix it.[/QUOTE]

What field require anal-retentive amounts of optimization? I wanna do that for a living

[DrTaxi]

High-frequency trading might be for you. People write their own TCP/IP stacks that only actually cover 10% of what a TCP/IP stack should do only to shave a few nanoseconds off their latency.

In general, anywhere where getting the most out of your silicon is really important, so high-performance low-level systems.

My point wasn't that optimisation isn't important. Just that it's among the last steps of development. After you're done with everything else, go and find the slowest parts of your application, and the code that is executed the most.
You can go anal-retentive all you want there, just not your entire application.

[Cold]

[QUOTE=proboardslol;45925613]What field require anal-retentive amounts of optimization? I wanna do that for a living[/QUOTE]

Working with supercomputers or certain servers.

Potentially working on the internal implementation of DirectX/OpenGL for GPU producers is even more suitable.

[DrTaxi]

[QUOTE=Cold;45925736]Working with supercomputers[/QUOTE]

Not a safe bet. If you write programs to run for a couple hours, the extra work hours that go into optimisation are probably still gonna be more expensive than the CPU hours you'd save.

Now, if you're writing software to run on other people's supercomputers, and you're in direct competition based on performance...

[quote]Potentially working on the internal implementation of DirectX/OpenGL for GPU producers is even more suitable.[/quote]
Or processors in general. Someone in WAYWO was talking about their work at ARM a while back.
Code that runs on GPUs is also good - though you'll always be at C level, no higher, no lower (unless you work for the card manufacturer).

[proboardslol]

[QUOTE=DrTaxi;45925824]though you'll always be at C level, no higher, no lower (unless you work for the card manufacturer).[/QUOTE]

I love C. I wouldn't really say I'm "beginning" C as much as I'm Re-beginning C.

I tried learning it when I was in 7th grade, but not knowing anything about computer architecture and memory, there was no way I could have appreciated what it means in the way of optimization. Then they taught me Java in highschool, and memory usage was disgusting and stack overflows were constant.

People call C elegant. I wouldn't call it that as much as I would call it a cultic obsession.

[DrTaxi]

Well, assembly language for GPUs is also going to be largely unavailable to GPU application developers.