Why wont this compile?

#include <ctime>
using namespace std;
int main()
{
    //Array processing
    int info[5][2];     //Array with 10 elements
    int amt, amto, amtt, amtr, amtv;
    int x=0;          //counter
    int y;            //number of elements in array
    int value=0;      //input value
    int total=0;      //total
    float average;    //average
    int stop=0;
   
    cout<<"\nThis program will calculate the average of up to 10 numbers\n";
    while(value!=-1)
    {
            cout<<"Enter sales ID number: ";
            cin>>value;
            if (value=1)
            {
              cout<<"Enter sales amount: ";
              cin>>amto;
            )
            else if (value=2)
            {
              cout<<"Enter sales amount: ";
              cin>>amtt;
            )
            else if (value=3)
            {
              cout<<"Enter sales amount: ";
              cin>>amtr;
            )
            else if (value=4)
            {
              cout<<"Enter sales amount: ";
              cin>>amtf;
            )
            else if (value=5)
            {
              cout<<"Enter sales amount: ";
              cin>>amtv;
            }
            }

There's more stuff after it, but this is what's important.

I keep getting these errors.
"27 expected primary-expression before ')' token "
"27 expected `;' before ')' token "

Can anyone help me!?

I have #include <iostream> included BTW.

It didn't get added in for some reason.

Because you need to learn how to program. PROTIP: learn the difference between the assignment operator and the comparison operator.

You have some closing parentheses instead of closing braces in the if/else if blocks. You also want to be using == instead of = in those conditionals.

You have a lexical error at character 1:1.

HTH.

Because you're a fucking idiot who can't solve his own compile-time problems in a drop dead simple application?

>>6
Is that even relevant to the topic, or is it just your way of saying "Ive read SICP"?

I AM AN EXPERT PROGRAMMER, AND THIS IS A SHITTY PROGRAM.

if/switch blocks like that usually mean you need to use an array instead.

yeah you have several ) where you need }

And as someone else mentioned using an array would greatly improve the speed of the program. 

Good luck learning how to program :)

I hear Comp Sci 100 has TAs now.

Here's a classic C++ nub programmer, he can't solve his shitty program.

1) Learn C before C++(It makes C++ programmers less retarded)
2) Learn to read
3) Learn how to program
4) Learn the difference between {} and ()
5) Learn the difference between assignement and comparison operator
6) Become a hero
7) Do a barrel roll
8) Learn Java
9) ????
10) Profit

Here you go.

>>12
Learn C before C++? Are you retarded? If he done that we'd have him not defining functions before invoking them, abusing the preprocessor, flooding the global namespace with identifiers and other such things.

Truth is if C programmers compiled their code with a C++ compiler they'd be better off anyways. They could even make use of several language constructs like enumerated constants, namespaces, constant variable declarations,  etc. to make their job easier on themselves. Note those are all abstract constructs that when compiled will not "slow down their code."

>>13
>Truth is if C programmers compiled their code with a C++ compiler they'd be better off anyways.
more like
Truth is if C programmers compiled their code with a C++ compiler they'd be WRITING C++.

and from the eyes of a C++ coder, thats obviously "Better"
if you had a less clouded judgement you would see that C and C++ are BOTH shit, and C++ is actually more bloated and awful than _even_ C!

Kernel hackers use PURE C motherfuckers.

>>13
I've never done C++, but I can tell you right now.  In C, you declare your functions first.  Failure to do so is an implicit definition, and if you're decent enough to use -Wall, you'd know this.

>>13
Tard!

Ok, forgive me, I don't code in C so I was mistaken. You DO have to declare a function before use, however you don't have to give your prototype a parameter list. This compiles perfectly:

void fourchan();

int main()
{
 int dickNipples;
 fourchan(dickNipples);
 return 0;
}

void fourchan(int pDickNipples)
{
}

And because of this feature alone C DOESN'T and CAN'T have function polymorphism.
void fourchan();
void fourchan(char shit);

int main()
{
 int dickNipples;
 fourchan(dickNipples);
 fourchan('&');
 return 0;
}

void fourchan(int pDickNipples)
{
}

void fourchan(char pShit)
{
}

This isn't even mentioning how you C fags reinvent the wheel everytime you pass a structure pointer to a function, forgetting that classes in C++ could easily do that job for you and take away the unnecessary micro-management.

Unless you're in driver or kernel development you have no fucking reason to code in C.

>>14
You're a dumbass but I'll bite. No, you're not coding in C++ unless you use C++ constructs. C++ was made to be [largely] backwards compatible with C, blah blah blah, buy more ram. Forced indentation of code, thread over.

And bloated? I dare you look into how classes actually look once compiled. Many contructs in C++ are just meant to be a concept for abstraction, meaning they don't actually "become" code. I'm just saying that many C developers would find it easier if they ran their code through a C++ compiler and -maybe- use a few of the features provided since C++'s tighter restrictions will undoubtedly fix many of the bugs before they happen.

>>18
Also forgot to say that, alas, all that is rendered null and void once once you compare C# to C++.

In C an empty parameter list means that the parameters are unknown, in C++ an empty parameter list is the same as void; no parameters. Regardless, not properly prototyping your functions before use is really bad practice and I've never seen anyone doing it. Use of void main () and casting malloc() is a lot more frequent.

function prototype declarations are optional.

>>21
int main()
{
 int dickNipples;
 fourchan(dickNipples);
 return 0;
}

void fourchan(int pDickNipples)
{
}

Try to compile that, I dare you. Your compiler will divide by zero and time will stop.

Why is it bad practice to not prototype functions?

>>23
For starters if someone were to read your code later on the parameter lists wouldn't be explicitly known.


void fourchan(int pDickNipples)
{
}

int main()
{
 int dickNipples;
 fourchan(dickNipples);
 return 0;
}

now compile

>>22
oh, and you might want to learn hugarian, that should be
void fourchan(int p_nDickNipples)

>>23
Readability, and for things like the above code won't compile unless the function in declared before the main

And if you're separating your shit into .h and .cpp classes, which you should be, the .h has the class structure, members, and prototypes. The .cpp has the function implementations.

If you don't prototype a function the compiler will construct one based on the first call it find to it. Why is that bad? Say you have a function which takes an int and you pass it a short as an argument. This is perfectly ok, the short will be promoted to an int. However, if you don't have it prototyped the compiler will assume that the function takes a short as an argument and then when it find the definition of the function which says it takes an int an error will be generated, since the arguments don't match.

>>18
The reason that C accepts empty parameter lists in function declarators is to maintain compatibility with legacy code. This is how functions were written in K&R C. If you are writing C code with empty parameter lists, then you are following a convention that has been obsolete since 1989.

Polymorphic behaviour can be achieved in C, although it may not appear to be what you think polymorphism is. Here is a simple example.

#include <stdio.h>

int add(int a, int b) {
    return a + b;
}

int multiply(int a, int b) {
    return a * b;
}

int main(void) {
    int (*op)(int, int);

    op = add;
    printf("op(3, 5) = %d\n", op(3, 5));

    op = multiply;
    printf("op(3, 5) = %d\n", op(3, 5));

    return 0;
}

There is no objective reason to use one language over the other. A choice between them is nothing but a personal preference.

>>28
thats not polymorphism.

>>28
You fail at trolling. Try to be a bit more subtle.

>>28
main = mapM_ (\ f -> putStrLn $ show $ f 3 5) [(+), (*)]

>>31
main = mapM_ (\f -> print (f 3 5)) [(+), (*)]

>>32
let main = mapM_ (\f -> print $ f 3 5) [(+), (*)]

In before pointless.

>>33
In after ghci.

>>31,32 are only joking

here's the real equivalent code:

module Main where

import Data.IORef

add :: Int -> Int -> Int
add a b = a + b;

multiply :: Int -> Int -> Int
multiply a b = a * b;

main :: IO ()
main = do
    f <- newIORef undefined;
    writeIORef f add;
    readIORef f >>=
        print . flip ($ 3) 5;
    writeIORef f multiply;
    readIORef f >>=
        print . flip ($ 3) 5;

mapM_ (print . flip uncurry (3, 5)) [(+), (*)]

Pointless code FTW.

>>35
add a b = a + b;
multiply a b = a * b;
I have two questions:
1. What's with the semicolons?
2. Why did you even bother writing those functions?

>>37
YHBT. Think really hard: where are your side effects?

>>38
WHERE IS SARAH CONNOR

>>25
Hey dumbass, what happens when you need to compile the function across several implementation files?