Bitset array

[Dragon257]

I'm tring to use a array of bitmaps, so i have a 50 X 50 field of much more compact boolean varibles then if i just used a 50 X 50 array of booleans.

The bitset array is declared as so:
static bitset <50> Bitset [50];

And at the top of the file is:

include <bitset>

using namespace std;

(If it matters) the varible is inside a class as public.

The bitset array is only used inside a member of the class that the bitset is in :
Bitset [0].set (0, true);

And i get the following compiler errors:
290:22 C:\Dev-Cpp\include\c++\3.4.2\limits macro "min" requires 2 arguments, but only 1 given

Then this about 50 or so times (though the numbers on the left side increases):
290 C:\Dev-Cpp\include\c++\3.4.2\limits expected ;' before "throw" 292 C:\Dev-Cpp\include\c++\3.4.2\limits expected;' before "static"
292:22 C:\Dev-Cpp\include\c++\3.4.2\limits macro "max" requires 2 arguments, but only 1 given
292 C:\Dev-Cpp\include\c++\3.4.2\limits expected ;' before "throw" 295 C:\Dev-Cpp\include\c++\3.4.2\limits expected;' before "static"
318:22 C:\Dev-Cpp\include\c++\3.4.2\limits macro "max" requires 2 arguments, but only 1 given

Then this (sepperated for your convinence - its not actully seperated:
C:\Dev-Cpp\include\c++\3.4.2\bits\istream.tcc In member function std::basic_istream<_CharT, _Traits>& std::basic_istream<_CharT, _Traits>::operator>>(short int&)': 146 C:\Dev-Cpp\include\c++\3.4.2\bits\istream.tccmin' is not a member of std::numeric_limits<short int>' 147 C:\Dev-Cpp\include\c++\3.4.2\bits\istream.tccmax' is not a member of `std::numeric_limits<short int>'

C:\Dev-Cpp\include\c++\3.4.2\bits\istream.tcc In member function std::basic_istream<_CharT, _Traits>& std::basic_istream<_CharT, _Traits>::operator>>(int&)': 146 C:\Dev-Cpp\include\c++\3.4.2\bits\istream.tccmin' is not a member of std::numeric_limits<int>' 147 C:\Dev-Cpp\include\c++\3.4.2\bits\istream.tccmax' is not a member of `std::numeric_limits<int>'

C:\Dev-Cpp\include\c++\3.4.2\bits\istream.tcc In member function std::basic_istream<_CharT, _Traits>& std::basic_istream<_CharT, _Traits>::ignore(std::streamsize, typename _Traits::int_type)': 147 C:\Dev-Cpp\include\c++\3.4.2\bits\istream.tccmax' is not a member of `std::numeric_limits<int>'

C:\Dev-Cpp\include\c++\3.4.2\bits\istream.tcc In function std::basic_istream<_CharT, _Traits>& std::operator>>(std::basic_istream<_CharT, _Traits>&, _CharT*)': 147 C:\Dev-Cpp\include\c++\3.4.2\bits\istream.tccmax' is not a member of `std::numeric_limits<int>'

16 C:\Documents and Settings\Ben\Desktop\C++\New Asteroids\Particles_Class\Particles_Class.cpp [Warning] converting to unsigned int' fromdouble'

C:\Documents and Settings\Ben\Desktop\C++\New Asteroids\Makefile.win [Build Error] [Particles_Class/Particles_Class.o] Error 1

Then when I remove the use of the bitset array it still throws these errors, then i removed the [50] in the decleration and it STILL threw these errors! (i am so confused)

Dev c++ 4.9.9.2 on Windows XP.

Dragon 257

[Osito]

You should always attack the first error first. Sometimes it is the cause of all the others. Post the line where you've used the min() macro.

[Dragon257]

Theres a problem with that, i haven't used the min macro.

Dragon 257.

[Wayne Keen]

That is similar to what I have seen on some code at work. The error is a little
different, as it crops up on Cygwin compilation and not MinGW, and I have seen it
come in with iostream inclusion, but that is as far as I have gotten - I have
a mojor program review coming up next week, and it is taking most of my time...

Wayne

[Wayne Keen]

I have run into a very similar error, with different boundary conditions at work. If/when I get
it run to ground, I will post on it.

By the way Dragon, it is a VERY BAD idea to put a project in a directory with spaces in it.
This is mentioned prominantly in the thread titled "Please Read Before Posting a Question".
which, presumably you read before posting this question. I don't think this has anything
to do with your error, but it will bite you eventually, and hard.

Wayne

[Anonymous]

The error cannot be reproduced from teh little information you have provided about the code. The code below embodies all you have told us about it, and it compiles and links ok.

include <bitset>

using namespace std;

static bitset <50> Bitset [50];

int main()
{
Bitset [0].set (0, true);
}

What you have to do is provide some complete code that reproduces the problem.

However my bet is that this is a symbol clash caused by moving the std:: namespace into the global namespace. This is a bad thing to do, especially when using the STL because it annoyingly defines several symbols globally that might be quite commonly used elsewhere. The error messages that the compiler generates in these circumstances can be very confusing because the compiler itself is confused!

So post more code, if not the code, a small standalone example that reproduces similar errors.

Clifford

[Dragon257]

I thought that was enough information, and after playing around for while I think ive found why that isen't enough.
My windproc function and my (MSG messages) varible both need to be removed (along with the definition and use of the bitset) before the code will compile, wich suggests that its somthing at a very low level (I do include windows.h).

I tried to compile it without the using namespace std; but it still threw the long list of errors.

After I had to remove the windproc function and the (MSG messages) varible, I reopened my project for another trie, uncommented them, and it worked... so I then tried adding the defination of the bitset, wich worked, then I added the use of the bitset, and it all fell to peices, then I removed the use of the bitset, it was still unhappy, then I removed the definition and the #include <bitset>, it was ok, then I added the definition and the #include <bitset>, and its ok.

Wierd huh?

I then repeated the whole thing, but i did the bit where I removed the definition and the #include <bitset>, diffrently in that I removed the definition, it was still mad, then I removed the #include <bitset>, and it was fine...

So theorecticly its the surrondings of the use of the bitset wich kills everything.

Ive taken all the surroundings of the bitset and its use and reduced it down to this (wich will still through the errors):

File name: Particles_Class_Header.hpp

include <windows.h>

include <math.h>

include <bitset>

class Particles
{
public:

    static std::bitset <50> Bitset [50];

    bool bCollisoin_Detect ();

};

File name: Particles_Class.cpp

include "Particles_Class_Header.hpp"

bool Particles::bCollisoin_Detect ()
{
Bitset [0].set (0, true);

return true;

}

File name: Asteroids_Main.cpp

include <iostream>

include "Particles_Class.cpp"

using namespace std;

int main(int argc, char *argv[])
{
system("PAUSE");
return EXIT_SUCCESS;
}

This is all in a project with the defult console settings with one change, in the tab marked "files", Particles_Class.cpp has its "include in linking" box unchecked.

That sucsesfully produces the error on my machine, and if you remove the:

include <windows.h>

include <math.h>

In file Particles_Class.cpp, the errors change intrigingly...

Sorry for my realy bad writting skills :(

Dragon257

[Osito]

When you include a cpp file rather than compiling and linking, sometimes changes to that file don't get recognized each time and you get inconsistent results. It's not your root problem, but it might be causing the weird results you are seeing. Under Tools-Compiler Options there is a box marked Use Fast But Imperfect Dependency Generation. Uncheck it to make sure changes to your included cpp file are always recognized.

[Dragon257]

That would explain alot.

I assume the perpurse of the "Rebuild all" butten is to force the files to be linked and compiled?

Dragon 257

[Soma]

This error will occur regardless of compiler when certain 'std::bitset' methods are invoked. GCC is being strict.

Soma

Hint: '#define max(a,b) ((a)>(b)?(a):(b))'
Hint: '#define min(a,b) ((a)<(b)?(a):(b))'
Hint: 'std::numeric_limits<type>::max();'
Hint: 'std::numeric_limits<type>::min();'

[Anonymous]

Do yourself a favour use separate compilation and linking (i.e use File->New->Project, and add the .cpp files to teh project rather than #includ'ing them. The pre-processor is not a linker - don't try to use it as one, for anything other than trivial projects it is impractical.

Your headers need include guards - in more complex builds you will run into trouble otherwise.

For the purposes of reproducing the error however, all that code could have been placed in a single source (and you would have avoided the above criticism - always make it as small an to the point as possible. To be honest you did a better job at this than most it has to be said, usually we get "it is too big to post" or it is too big and they post it anyway! .)

I did suggest earlier that this was a namespace issue, it is not, but it is the result of a name clash. Unfortunately the preprocessor is not namespace aware it does simple text replacement. So a macro called "min" will replace all occurances of "min" in subsequent headers, rendering some code nonsense (such as the numeric_limits definitions).

Teh solution is unfortunately cumbersome and a little unsatisfactory. Reordering the header files is one way. In general place any standard headers ahead of third-party and project headers:

The code below compiles (as a single file), but does not link - you have not instantiated the static Bitset member. I'll leave that to you - I've never used Bitset.

include <math.h>

include <bitset>

include <iostream>

include <windows.h>

class Particles
{
public:

static std::bitset <50> Bitset [50];

bool bCollisoin_Detect ();
};

bool Particles::bCollisoin_Detect ()
{
Bitset [0].set (0, true);

return true;
}

using namespace std;

int main()
{
system("PAUSE");
return EXIT_SUCCESS;
}

---

An alternative is to undefine the offending macros - but it is not always obvious what they are:

include <windows.h>

undef min

undef max

include <math.h>

include <bitset>

include <iostream>

With respect to the weird behaviour of the problem appearing and disappearing, well I would suggest that you were doing so many different thing that unless you did a Rebuild All between each build, I would suggest that it was 'experimental error'.

Credit to Soma - I know the hint was meant for the OP, and he'll be annoyed that I elaborated instead of making you figure it out, but there you go.

Clifford

[Dragon257]

The cpp files are in a proejct, along with there headers, but if I remove the #include's I get loads of not declered errors, this may have somthing to do thith the fact that under project options in tab files all the cpp files have "Include in linking" boxes unchecked. I did trie checking them and removing the #include but I still got loads of not declered messages.

Do you mean the headers need include guards for the standerd headers?

Thanks. Realy, thanks. This forum scary, took huge amounts of curedge to start this thread. How many lines of code is too big?

Oh. I've never used static members\attributes before. I had to look it up before I understood what you meant

I would never have worked that out. Well, maby in about a month. Thanks (again)

Dragon257

[Soma]

O_o

sigh

Clifford's first proposed solution is a short term fix. The code will eventually fail again with the same errors.

Clifford's second proposed solution is the correct solution, but not complete. Create a new header that safely wraps the existing third-party header.

Soma

[Anonymous]

>> Do you mean the headers need include guards for the standard headers?

The standard headers already have include guards!

I mean for example Particles_Class_Header.hpp:

// Only comments should be here.

if !defined Particles_Class_Header_HPP

define Particles_Class_Header_HPP

// #include <windows.h> NOT NEEDED HERE!!
// #include <math.h> NOT NEEDED HERE!!

include <bitset>

class Particles
{
public:

static std::bitset <50> Bitset [50];

bool bCollisoin_Detect ();
};

endif // Particles_Class_Header_HPP

---

Generally nothing other than comments should appear before the "#if !defined Particles_Class_Header_HPP". Since you are already having problems with headers don't include them where they are not needed! I've commented out the redundant ones.

W.r.t. Soma's suggestion about wrapping windows.h in a 'safe' header; I felt that this problem cannot be uncommon. I did a judicious Google using "min max windows.h STL", and found this: http://support.microsoft.com/kb/143208

If you simply add -DNOMINMAX to your compiler options it will resolve the issue - regardless of order of inclusion. I suggest that you put the option in Tools->Compiler options, on the Compiler tab, check "Add following commands when calling the compiler", and place the option the box. (While you are there add -Wall -Werror also). This will ensure that the option is applied to all your builds including existing projects. In the unlikely event that you need the min/max macros, it is trivial to define your own in a manner that does not clash.

Clifford

[Soma]

"If you simply [...] does not clash."

LOL

How idiotic! You've completely missed the point! And the site you linked isn't even referencing this instance of common collisions.

Soma

[Anonymous]

I disagree (well I would wouldn't I). -DNOMMINMAX prevents the definition of min and max macros in windows.h. I would suggest that this directly addresses the problem at hand.

I guess you'll have to enlighten me.