You are invited to Log in or Register a free Frihost Account!

# A little help on C++

seanooi
How do I do like lets say it's

cout << "how many lines should there be";
cin >> x;

when a user inputs X, (assume X = 6), then 6 lines will appear?

What i was thinking is something like
int count
count[x]

If you're not sure of what I'm asking, this is my assignment title
 Quote: Write a program that will output a jagged edge triangle based on numbers inputted by the user. The first thing the program should do is read in the height of the triangle. Then it should read in height number of integers that represent how much wider the jagged egde triangle should be at a particular point than it was just above it(starting from 1, but the first line will be wider than 1 if you put in a non-zero number for the first width increase). Then it should output the jagged egde triangle onto the screen using '*' characters. Also, insist on non-negative numbers for input, if they input a negative number, ask for the number again, this time emphasizing that it should be non-negative, and keep doing that until a non-negative number is entered. For example, consider the following to be the result of the program when run(note, bold text represents what the user typed in). What should the triangle's height be? 6 Width increase at 0: 0 Width increase at 1: 2 Width increase at 2: -5 Width increase at 2(non-negative please): 3 Width increase at 3: 2 Width increase at 4: 4 Width increase at 5: 1 * *** ****** ******** ************ *************
Nyizsa
It's simple. Use an array. Do a loop for data entry, like
 Code: for (i=0; i<=x; i++)                  //x: user's input {   printf('width increase at ' + x + ":");   getc(triangle[x]);                          //triangle[]: your array you store the increases in }

Then do a pair of nested loops for outputting the triangle:
 Code: for (i=0; i<=x; i++) {   for (j=0; j<=triangle[x]; j++)   {     printf('*');   }   printf('\n'); }

Sorry if there are syntax errors - I didn't actually test it, but you may catch the idea. Also I didn't bother with verifying input.
Good luck!
darth_revan
you can make a function that makes it easier.
for example:
 Code: //include files// int line(int a) { for(int j = 0; j < a; j++) { cout << endl; // cout << "\n"; is also possible } } int main() { int a; char b; here: cout << "enter sth: "; cin >> a; line(a); cout << "Wanna do it again? y or n" cin >> b; if(b == 'y' || b == 'Y') { goto here; } cout << "have a nice day"; getche(); }
Qweertyy
Do NOT use goto, I really recommend using while or for instead.
Gieter
 Qweertyy wrote: Do NOT use goto, I really recommend using while or for instead.

That's very true: goto is a statement that comes from the assembly-languages. There it's used all the time. But goto-statements have become obsolete in modern languages (C++, Java, PHP, almost all known languages except assembly and raw binary code and Basic I think), because there are more powerful statements in those modern languages.

In C++ I never experienced a situation in which I had to use a goto-statement. Use while, for, or do-while loops instead.
deathrabbit
Gieter wrote:
 Qweertyy wrote: Do NOT use goto, I really recommend using while or for instead.

That's very true: goto is a statement that comes from the assembly-languages. There it's used all the time. But goto-statements have become obsolete in modern languages (C++, Java, PHP, almost all known languages except assembly and raw binary code and Basic I think), because there are more powerful statements in those modern languages.

In C++ I never experienced a situation in which I had to use a goto-statement. Use while, for, or do-while loops instead.

More powerful just means less efficient. I'm not sure what you have against efficiency.
Gieter
deathrabbit wrote:
Gieter wrote:
 Qweertyy wrote: Do NOT use goto, I really recommend using while or for instead.

That's very true: goto is a statement that comes from the assembly-languages. There it's used all the time. But goto-statements have become obsolete in modern languages (C++, Java, PHP, almost all known languages except assembly and raw binary code and Basic I think), because there are more powerful statements in those modern languages.

In C++ I never experienced a situation in which I had to use a goto-statement. Use while, for, or do-while loops instead.

More powerful just means less efficient. I'm not sure what you have against efficiency.

That's your opinion; fact is, in every C++-book you'll read, they'll say to avoid GOTO-statements. Goto-statements make the code harder to read (for yourself and someone else), thus making it harder to debug. C++ is a language in which you'll have to spend lots of time in debugging (except for if you're writing small programs), and if you're using goto-statements all over the place, the time needed to debug will only increase. So in that perspective goto-statements will decrease the efficiency. It's not only the execution time of a program that counts, the time needed to construct the program is an important factor too.
Second, using for,while, or do-while-loops isn't less effective than using goto-statements. This is because the C++-code will be compiled, this is translating to machine code. In machine code, there is no such thing like while,for or do-while loops. The loops get translated in goto-statements. Result: the program has (almost) the same speed as you programmed with goto-statements, and your code is cleaner!

PS: if you really want some efficiency, stop using any high-level language and start programming in assembly language. That's efficient!
AftershockVibe
The problem with GOTOs is that they have no structure, this is what makes them bad because they make it so hard to keep track of program flow.

Iwoudln't say While and For are more "powerful" as they end up being compiled to the same thing anyway (as Geiter said). They do make programming simpler though.

The argument against GOTOs is simply:
"Why make programming harder for yourself?"

That said, GOTOs (or equivalent) can be pretty much the only useful way in some langauges without intergrated error handlers to jump to error trap routines.
Kaneda
ASV, as per usual, hits the nail on the head. Avoiding GOTO is not about the power inherent in a language structure, it's about GOTO not having any structure to begin with.

Jumping here and there in your code is not the way to make it easily maintainable, not only because it's harder to track where a goto jumps to than where a for/while/switch/do structure ends (with proper indentation), but also because using goto is so arbitrary that the lack of structure tends to spread to other parts of your programming - it simply infects your mindset .

In 99% of cases, a for, while, switch or do will do the same thing and be easier to read. The remaining 1% are in languages lacking exception handling or similar (as ASV mentioned), or more generally, when you need to escape out of several loops, like:

 Code: bool done = false; while (something && !done) {   ...   do {     ...     ...     while (somethingElse && !done) {       ...       if (checkForSuccess()) {         // I wanna get out of here fast...         done = true;       }       ...     }     ...   } while (somethingThird && !done);   ... } // This is where I want to go to when I get the result I need. ...

Obsessive avoidance of GOTO in such a case will often lead to even more obscure code... setting some "done" variable, and checking it in every containing loop, like above - or alternatively, lots of "if (done) break;"'s - or sometimes both in combination.

In such a case, it's often preferable to use GOTO for readability. But alas, such a case is rare - and whenever it occurs, it's often a good sign that you should refactor your code.

Anyway, the alternative with goto would be:

 Code: while (something) {   ...   do {     ...     ...     while (somethingElse) {       ...       if (checkForSuccess()) {         // I wanna get out of here fast...         goto done;       }       ...     }     ...   } while (somethingThird);   ... } // This is where I want to go to when I get the result I need. done: ...
BruceTheDauber
It's a mistake to suppose that goto is always more efficient than structured statements like while and for. It would often be true if the compiler didn't do any optimizations, but since nearly all modern compilers do optimize your code, it is actually often more efficient to write well-structured code (which the compiler knows how to optimize), than unstructured code, which the compiler often can't optimize, because it doesn't know your intentions.
woja
Kaneda wrote:
...or more generally, when you need to escape out of several loops, like:
 Code: bool done = false; while (something && !done) {   ...   do {     ...     ...     while (somethingElse && !done) {       ...       if (checkForSuccess()) {         // I wanna get out of here fast...         done = true;       }       ...     }     ...   } while (somethingThird && !done);   ... } // This is where I want to go to when I get the result I need. ...

Hmmm....

1. Change the ordering in the conditions to put !done first. Why? Because C (and C++ and Java and Modula-2) uses "short-circuit" evaluation for Boolean operations such as &&. This means that if, say, something is an expresion, it will not be evaluated if done is true.
2. Use notDone instead of done, because it makes it more readable;
3. C++ does have exceptions;
4. If I ever get more than two nested while loops I usually decide to use another function;

The last is the most important, which means I would use (and this gets rid of the necessity for any done variable at all:
 Code: bool innerTwo() {    while (somethingThird) {       ...       if (checkForSuccess()) return true;       ...    }    return false; } bool innerOne() {    do {       ...       if (!innerTwo()) return true;       ...    } while (somethingElse);    return false; } void doIt() {    while (something) {       ...       if (innerOne()) break;       ...    }    ...    return; }

Of course, you probaly want to know what caused the loops to terminate, so you might need:
 Code: void doIt() {    bool doneOK = false;    while (something) {       ...       if (innerOne()) {          doneOK = true;           break;       }       ...    }    if (doneOK) {       ...    } else {       ...    }    return; }
Kaneda
 woja wrote: - Change the ordering in the conditions to put !done first. Why? Because C (and C++ and Java and Modula-2) uses "short-circuit" evaluation for Boolean operations such as &&. This means that if, say, something is an expresion, it will not be evaluated if done is true. - Use notDone instead of done, because it makes it more readable; - C++ does have exceptions;

Noone ever said that code was C++. I certainly didn't Call it pseudo code. It's there to provide a point, not to show best practices in C++ - or any other language for that matter. And exceptions should be used for... exceptions. Not for things you expect your code to do all the time.

In the case where a massive amount of loops can be "done" at various points, doing "notDone = false;" at several places in your code isn't exactly more readable than a more intuitive "done = true;". Hence, "!done" in a single place.

As for the ordering of conditions, yes, that was a mistake, but again, this code wasn't written to be copied, it was a hypothetical example in a hypothetical language using the basic syntax of the most well known programming languages.

 Quote: - If I ever get more than two nested while loops I usually decide to use another function;

 Kaneda wrote: But alas, such a case is rare - and whenever it occurs, it's often a good sign that you should refactor your code.

Point being, yes, you should refactor. An important point, which is why I mentioned it in the first place. Unless you're optimizing for performance in a language which doesn't feature inline functions. (Which is where you'll mostly see such loops in the first place).
woja
 Kaneda wrote: Noone ever said that code was C++. I certainly didn't
OK, I withdraw that bit. It was just that this thread started off about C++, but got expanded to goto and other stuff. I assumed we were still in C++.
 Kaneda wrote: And exceptions should be used for... exceptions
I agree.
Anyway, I think the most important thing is probably the refactoring, even if this sort of construct is rare (and, I agree, it is).