![]() |
|
#1
|
|||
|
|||
Anyone can fix the error for me?Hi,
I am doing some exercise on file reading/writing and C++ vector operation. My code is as following: CPP / C++ / C Code:
Specifically, what I want is to write a 2D matrix to a file named "test.bin" and then read the data back to a 2D C++ vector "vec_2d", after that, model the neighborhood of each elememts using a mathematic vector consists of some nearby elements and print them out respectively. In consideration for boundary elements, an extra padding operation is also carried out. However, there seems to be something wrong with the red colored code. In VS 2005,the error while compilation is listed as: CPP / C++ / C Code:
Anybody can tell me why does this happen and give me some guide about an effective solution?Thank u in advance. nanchuangyeyu |
|||
|
#2
|
|||
|
|||
Re: Anyone can fix the error for me?[quote=nanchuangyeyu]
CPP / C++ / C Code:
The error messages from the compiler may not seem to be particularly enlightening, since you don't recognize the problem, but that's often the case. There are actually two errors here. Your compiler doesn't get past the first one. 1. Standard C++ does not support variable-length arrays. 2. The arguments to the constructor can be three doubles, not three arrays. One possible solution: Use static_cast on the arguments: CPP / C++ / C Code:
Another: Use old-style C casts: CPP / C++ / C Code:
Another: Given that you have a constructor that takes three doubles, let the compiler figure out that is what needs and it will promote the arguments. In other words, it sees if the arguments can unambiguously be made compatible with any of the constructors that you have defined, and does the work of converting them. CPP / C++ / C Code:
C++ purists would probably use the first one. I like it because there is absolutely no question as to the programmer's intent. Many old-hand C programmers would use the second. C++ purists might point out that, although there is nothing "wrong" with this in this case, the gratuitous and habitual use of old-style casts can get you into trouble some day. Rather than give tiresome examples of how it can go wrong, I would suggest that cultivation good habits is important when people are learning. Lazy and/or non-observant programmers might use the third one. As for the third example, well I personally think that "letting the compiler figure it out" is not necessarily the best habit to get into either. The compiler won't get confused, but programmers trying to maintain and/or debug code like this can easily overlook problems that could arise. Regards, Dave |
Recent GIDBlog
Toyota - 2009 May Promotion by Nihal
| Thread Tools | Search this Thread |
| Rate This Thread | |
|
|
Network Sites: GIDNetwork · GIDWebHosts · GIDSearch · Learning Journal by J de Silva, The