As far as I'm concerned, your code has a much more serious issue... the following:

[CODE] if (pixel[0] == 255)
{
if (pixel[1] == 255)
{
if (pixel[2] == 255)
{
return false;
} else {
return true;
}
} else {
return true;
}
} else {
return true;
}[/CODE]

can be written as:

[CODE]return pixel[0]!=255 || pixel[1]!=255 || pixel[2]!=255;[/CODE]
or if you prefer:
[CODE]return !(pixel[0]==255 && pixel[1]==255 && pixel[2]==255);[/CODE]

I'd like to point out that the OP is a troll who is just repeating the same procedure that he already went through on other forums using various names.
He's just testing how far he can push people before he finally gets banned.
If you look at his other threads, you'll see they follow the same pattern: he is "extremely confused" about something or another that requires an in-depth explanation, effectively aiming to waste people's time. It's likely that he is actually already a more or less accomplished programmer with a lot of time on his hands.

@spoonlicker: This might be a shot in the dark, but: you wouldn't have used the name "Avast" for extended periods of time a few years back, would you? This would totally make my day.

[QUOTE="nbaztec"]I mean if we can just use const in C, then why use #define, off the top of my head, is it due to this?[/QUOTE]
Not at all, both variants are perfectly legal in C. In fact, you can even use non-constants as the array size since C99.
That #define is still used is probably because bad habits die slowly - const was added to C in 1990, but the language had been existing for quite a while until then.

nbaztec commented: Informative. +1

The relevant part of the C standard is in 5.1.2.2.1:
[QUOTE]The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int
[/QUOTE]

C does not have inheritance, so obviously there is no dynamic_cast either.

There are references in C++, but not in C.

Yes, constants are indeed often realized through macros in C, although const exists just like in C++.

Yes, C does not support default arguments or any other function overloading for that matter. C++ does.

You definitely need to rethink your usage of classes - that's not how they were meant to be used. They are supposed to represent (conceptual) object classes and thus the instances should represent certain objects.

But: what is a "dead"? And what is an "alive"?

Hm, sure doesn't look much like selection sort...
I particularly don't get what the checks for -1 are supposed to do and what ptrinput is for.

Selection sort can be done simpler and in-place (i.e. without an extra array):

[CODE]#include <iostream>

include <vector>

using namespace std;

int main()
{
int numberCount;
cout << "How many numbers to sort? ";
cin >> numberCount;

vector<int> input(numberCount);
for (int i=0;i<numberCount;i++)
{
cout << "Enter number #" << i+1 << ": ";
cin >> input[i];
}

for (int i=0;i<numberCount;i++)
{
int bestIndex=i;
for (int j=i+1;j<numberCount;j++)
{
if (input[j]<input[bestIndex])bestIndex=j;
}
swap(input[i],input[bestIndex]);
}

cout << endl << endl << "Final result:" << endl << "----------------------" << endl;
for (int i=0;i<numberCount;i++)cout << input[i] << endl;
}[/CODE]

tundra010 commented: +1 +2

[QUOTE]And yes, it can be greater than the sum of the two other sides, that's the only way it can be a triangle. [/QUOTE]
Since you seem to know it better, I guess you shouldn't need any help on this...
but I'll give you three points to think about:
A(0|0|0) B(0|1|0) C(1|0|0)
a) do they form a triangle?
b) if so, what are the lengths of its sides and the ratio to the sum of the other sides?

Try to do it when compiling with -pedantic-errors.
As for the corresponding part of the C++ standard:
QUOTE Recursive calls are permitted, except to the function named main (3.6.1).[/QUOTE]

You can have more than one loop per program, you know.
You don't need goto.

[code]int main()
{
for (;;)
{ //main loop
for (;;)
{ //user input loop
[...]
switch (userinput)
{
[...]
}
}
[...]
}
}[/code]

Calling main results in undefined behaviour, so not really.

jonsca commented: Agreed +4

[QUOTE]or do I have to, in this kind of situation? Does the function free the memory automatically when the return statement is met?[/QUOTE]
No delete - no deletion. It would be pretty bad if the memory was freed anyway - then you'd return a pointer to a destroyed object.

But yes, it does leak - you have no delete anywhere. You need to delete paramTime after you're done with it.

Besides, returning a pointer to an object created inside the function is very bad style due to the high risk of memory leaks if you forget to delete the returned object. There are some possible solutions to this (for all it is implied that you don't return a pointer, but an object):

1) If the object can have an invalid state, return an invalid object on failure. A time class could - the invalid state could be zero for each member. An isValid() member function can be used to check for validity.
2) throw an exception if the function fails.
3) assign the time to an object passed by reference and return whether the function was successful.
4) keep using new but return a smart pointer such as auto_ptr, unique_ptr or shared_ptr.

This is far and well beyond your abilities. But if you're willing to learn, you can start here:
[url]http://wiki.osdev.org/Main_Page[/url]

Some suggestions for improvement:

  1. No point importing every element manually from the std namespace. An "using namespace std;" does the trick. While you shouldn't just go and import every namespace you find (that would defeat the purpose of namespaces), it's fine for the std namespace. Library designers can generally be expected to avoid clashes with the C++ standard library and this works well in practice - you'll rarely (if ever) encounter problems with other libraries.

  2. Where are all the headers? Are you including them in stdafx.h?

  3. No atoi! stringstream can be used here for conversion as well - but that is not even necessary. You can read an int directly from cin.

  4. Instead of incrementing loopLimit, you can just use x<=loopLimit as the condition in the for loop.

  5. There's no point in passing simple types like int/float/pointers etc. by reference. This is just more typing work and does not improve performance (or can hurt it, when no inlining can be performed). Constant references should be used for types that are rather expensive to copy in comparison (e.g. string) and for uncopyable types.

You shouldn't use malloc at all. This is how you do it properly:
[CODE]s_cell* cell=new s_cell[MAP_X];
for (int x=0;x<MAP_X;x++)cell[x]=new s_cell[MAP_Y];[/CODE]

Even better is the following:
[CODE]vector<vector<s_cell> > cell(MAP_X,vector<s_cell>(MAP_Y));[/CODE]

Here's a good tip to fix your range problem:
[url]http://www.cplusplus.com/reference/clibrary/cmath/fmod/[/url]

That'll work reliably even with a low limit.

empror9 commented: big thanks +1

The taylor series just gets you an [i]approximation[/i] of the real value when doing 20 iterations. The result -0.00000361132 is very close to zero, though. The result I'm getting is even closer.
If you want more precision, use double instead of float.
Then the function will give you exactly the same result as the "real" cos function (0.000000026795).

I do:
[url]http://www.boost.org/doc/libs/1_43_0/[/url]

boost is essentially an inofficial extension to the C++ standard library and contains many things that were not included in the standard library, but that you will need sooner or later in your programs.

Lusiphur commented: Thanks for the reference link :) +1

@tajendra
Note that the coin counting must work for arbitrary coin ranges, not just the entire range.
Also, you need to reduce nFalseCoinCount when appropriate.

If vijayan121's solution is not fast enough (you're already compiling with -O3, right?), you can implement vector<bool>'s shifting logic yourself and then flip 32/64/128 coins at a time (for 32/64 bit and SSE2 targets, respectively).

For fast population count (=tails up counting), see:
[url]http://gurmeetsingh.wordpress.com/2008/08/05/fast-bit-counting-routines/[/url]
[url]http://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetNaive[/url]
[url]http://cage.ugent.be/~klein/popcnt.web[/url]

and the POPCNT SSE4(a) instruction for CPU targets that support it.

There is a predefined operator "ranking" which determines the order operators are evaluated in:
[url]http://www.cppreference.com/wiki/operator_precedence[/url]

It's basically just like in maths, e.g. products and fractions are evaluated before sums. To change that order, you can use brackets.

In your above example, the brackets are superfluous. This will have the same effect:
[CODE]num = i*5 + var;[/CODE]

No... forget about graphics.h and especially about Turbo C++. It doesn't just "look" DOS-like, it is a DOS IDE. Its time has run out twenty years ago.

Ancient Dragon commented: Good answer :) +31
jonsca commented: Amen +4

You're pushing char pointers into the vector that become invalid when temp is changed.
You need to make a vector of strings or you need allocate memory for each char array and copy the string into it.

Sarkahn commented: Quick reply telling me exactly what I needed +0

The block does no longer belong to the for loop, because you have a ; after the for.

Or
[CODE] std::string reversestring(test.rbegin(),test.rend());
std::cout << reversestring;[/CODE]
for that matter.

Nick Evan commented: Yes indeed +15

[QUOTE=Supriyo;1263133]I have a very large program in C++ that is running without any errors from the compiler. But how can I know whether the code is well formed and mantaining coding standards?[/QUOTE]
By looking at it. Seriously though, there is no such thing as [i]the[/i] coding standards. Quality of code isn't something that can be determined by a computer program on a scale of 100 or something.

Some things that [i]might[/i] be indicators for bad code are the following:

  • lots of manual memory and resource management
  • heavy use of C strings
  • nondescript variable and function names
  • no logical class structure
  • little or no error checking and input validation
  • unnecessary use of platform-dependant solutions
  • hard to read and badly structured code
  • ...

But in the end only a moderately experienced C++ programmer can truly give a well-founded opinion on the quality of the code.

Ancient Dragon commented: agree +28

If you need a compiler and an IDE, see here (make sure to get codeblocks-10.05mingw-setup.exe):
[url]http://www.codeblocks.org/downloads/26[/url]

Free online book:
[url]http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html[/url]

How about explaining what you're trying to do exactly?
A web crawler and a program to searcb your hard disk are two different things.

See
[url]http://www.cplusplus.com/reference/clibrary/csignal/signal/[/url]

Note that in the case of a segmentation fault or division by zero all you can do in the signal handlers is to terminate the program in a controlled way, because when the signal handler exits, execution will be continued at the point where the problem occurred, which will most likely result in disaster.

However, under Windows there is structured exception handling, which throws a real exception in the case of segfaults or div by zero. In that case, you could continue execution if you wish. Still, that could be dangerous since things were left unfinished.

I fixed up the code a bit. It's still not perfect... normally you would use iterators in the loops and a proper check whether a word is actually a valid hex string would be in order as well (edit: now taken care of).
Still, I'm pretty sure that the code cannot cause any segmentation faults anymore. I left the Verilated related code commented out and didn't touch it. If you still get segfaults, the problem is in there.

Some problems I saw when I went through the code:

  1. You used InstructionMemory's elements, even though they were uninitialized. Elements of int vectors will be initialized to 0, but that does not apply to arrays.
  2. You used various global variables without any reason. They didn't have any helpful names either. This severely limits readability. Variables should be defined as locally as possible for the same reason.
  3. You used "z", a non-constant for your array sizes. This is not legal C++, even though it works with gcc.
  4. You filtered out words with f0 at position 1, thus filtering some valid hex strings.

Edit: 5. ...and you included some stray strings on the right side of the file. Since there were a few spaces, some words there happened to have the length 8.
I now included a proper check and eliminated the now somewhat obsolete tempInstructionMemory.
Still, in theory valid hex strings could appear on the right side.

[CODE]//#include "VMIPS.h"
//#include "VMIPS_MIPS.h"//required to explicitly access signals from submodules
//#include <verilated.h> ...

I see two problems:

  1. You're using delete (instead of delete[]) on buf, even though the array was created with new[].

  2. In FileSystemDataStream::open you're returning an object created with new as a regular pointer (instead of auto_ptr) which opens the gates to the realm of potential double deletes and memory/resource leaks. For example, where are you deleting the stream passed to the FileSystemDataStream constructor? The most logical place for that (the destructor) doesn't contain any code.

It would also help if you told us which line causes the segmentation fault.

You seriously need to indent your code, then mistakes with extra or missing braces couldn't happen.