|
|
|
Hi all,
I have an google imagery. And i want to implement a datum and projection for it.
how should i proceed?
Can any body please suggest something...
|
|
|
|
|
|
Hi, dear all,
Maybe my title make you confused, but I really don't know how to express it.
The project was created by other people before, inside the project there is a server called XXXX which inherite from COleServerDoc class. There are two containers that invoke the methods in the sever. Everything works fine.
Until now, before it only handle 4 types of materials, now it needs to handle 8 types of mateials, so I need to modify the server, otherwise it will cause array overflow. I modify the server and compile it, but when I run the container program, I still get the material overflow error, it totally didn't use the latest server I just compiled.
I check the container project and find it invode the server use the code: CreateDispatch(_T("XXXX.Document")), then I got to the Registry editor and find it was registered there before. So even I modify the server and recompile it, but the registered XXXX .Document is not updated, what should I do? how can I make the container project call my latest server?
Thank you very much!
|
|
|
|
|
Hello friends
I am writing in a Binary File Using FILE object.
And the structure that I am using while Writing is :
class A
{
int a;
int b;
};
While Reading Mine structure is :
class B
{
string name;
int a;
int b;
}
I am using fread like this way:
B* obj = new B();
fread(obj,sizeof(B)-sizeof(string),1,stream);
but not working,I m assuming that memory pointer obj is pointing at string name,so thats why i want to move obj pointer to int a,so it will read value of int a.
If ,i am wrong,please sugget me some other way. But there is restriction that i can change struture.
Thanks In Advance.
Regards
Yogesh
|
|
|
|
|
try
&obj->a
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Try ofstream[^] for serializing the objects in C++ way. Here[^] is an example.
Check this[^] site if you are interested to learn how to serialize in MFC.
|
|
|
|
|
I'd be inclined to load them individually.
I.e
B *obj = new B();
fread(&obj->a, sizeof(obj->a), 1, stream);
fread(&obj->b, sizeof(obj->b), 1, stream);
Please note also: the compiler may pad your structures where it sees fit, unless prevented via a compiler directive. I'd assume it also applied for classes, though do not know.
The implication is that if you declare a struct thusly:
struct simpleStruct{
char memberA;
long memberB;
}
You can often find that doing sizeof on each of the members then adding them together will give you a different result to sizeof theWholeStructure.
I.e, in my above example, it's quite possible that - sizeof(char) + sizeof(long) != sizeof(simpleStruct).
You may find that when you expect your structure to be 5 bytes as in the above example, that the compiler will pad it to 6 or 8 bytes. This means that when you do an fwrite using &simpleStuctInstance, you may in fact be adding 6 or 8 bytes to the file, although there are only 5 bytes of useful information. If you then do a fread using &simpleStructInstance, the extra bytes of padding will be magically of no consequence. However, if you fwrite the individual members out individually, then go onto fread the whole structure in one go, you'll be reading 6 or 8 bytes, discarding 1 or 3 of them and ending up with a struct that contains garbage.
This issue often arises when writing roll-your-own code for bitmap handling - failing to direct the compiler not to pad the structs results in all sorts of nasty behaviour.
|
|
|
|
|
That is really good advice concerning padding. It more often than not will cause huge grief and head aches when you ignore the effect of it. 
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
This is so wrong! If you go with this and release it into your commercial application then some developer some day is bound to change one of the classes but forget about the other one, at which time you system comes to a grinding halt. You should never use one class to save your data and a different one to restore it. Get your design right at the beginning and it will pay dividends in the future.
|
|
|
|
|
Hi,
I have a windows service which runs in XP, Vista and Win 7.
I am using WTSSendmessage() function to show a popup message at user desktop. But i need to display a popup message with different font size using the same WTSSendmessage() function.
Is there any way to accomplish this??
Thanks,
Nash
|
|
|
|
|
Not according to the documentation[^]. In general if you want a different font in message boxes then you need to create your own, either from scratch, or by subclassing an existing type, where that is possible.
|
|
|
|
|
I've put the topic in quotes, because I'm not asking for me. Instead I am referring to the various occasions I've seen where people advise inexperienced programmers to add
using namespace std; to their program. Personally I feel that this is not generally a good advice, for all of the reasons pointed out at http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.5[^].
But maybe the people offering this advice do have their reasons and take a different view? I'd like to know. What is your stance? Why do you think it is good to add a
using namespace statement, and when?
Or do you agree with me and generally advise against it? If so, can you offer any reasons not already offered at the site I linked above?
P.S.:
After reading the responses I've found there are indeed (IMHO) few strong arguments in favor of using using namespace std;. The two main arguments were:
1. Typing effort
2. Lack of readability, most notably (but not only) with the use of formatting in stream classes
Personally I don't think the typing effort should be considered a valid reason, unless there are absolutely no drawbacks to consider. Apart from that, both cases can be countered by various methods:
1. Use intelligent editors to minimize the typing effort
2. Use typedef to simplify complex (or just hard to type) expressions
3. Use a using declaration (e. g. using std::cout;) rather than a using directive
In those rare cases where, locally, symbols from namespace std are being heavily used (e. g. an output function using lots of formatting), adding a using directive locally (i. e. within the scope of the function only) could be a reasonable compromise. Thanks to Stephen Hewitt for pointing that out.
modified 6-Oct-11 4:55am.
|
|
|
|
|
Well, if you have lots of code using funcs only form one namespace in a file, then you can reduce the amount of typing you have to do by stating 'using namespace' at the top of the file.
If you are not, and you are mixing lots of code from different namespaces, then you shouldnt, because you might have a clash somewhere, and either compiler errors or runtime errors.
==============================
Nothing to say.
|
|
|
|
|
I don't consider the typing to be a problem - good editors will reduce the extra typing to a minimum, and even in Notepad there's nothing preventing you from copy-pasting the extra std:: repeatedly. I do it all the time. (the copy-pasting, not using Notepad  )
P.S.: You could also use typedefs to improve readability and reduce typing effort. This can be especially helpful for containers and iterators.
modified 3-Oct-11 4:23am.
|
|
|
|
|
Stefan_Lang wrote: I don't consider the typing to be a problem
So dont use 'using' then.
==============================
Nothing to say.
|
|
|
|
|
I personally almost never use it, simply because it clutters the global namespace. The worst abuse is to put it in a header file, and thus, polluting the global namespace in all files including that header.
I imagine though it can be useful in some situations, like when dealing with streams and manipulators. The code tends to get quite verbose if it's fully qualified. A local using namespace could be acceptable in my oppinion.
Good topic by the way.
|
|
|
|
|
Niklas Lindquist wrote: when dealing with streams and manipulators
Yes, I do find myself writing std::cout and std::endl quite a lot, but so far I've resisted the urge to add a using statement. However, you could insert a using declaration instead of a using directive for the most commonly used symbols, as pointed out at C++ FAQ.
Niklas Lindquist wrote: The code tends to get quite verbose
Are you implying this is a bad thing? I actually find that helpful. Besides, the extra typing is not actually an issue, thanks to intelligent editor tools.
|
|
|
|
|
Stefan_Lang wrote: The code tends to get quite verbose
Are you implying this is a bad thing?
In most cases, no. In some cases, yes. It does affect readability if it's too frequent. However, I have not experienced this in any other situation than when working with std streams.
|
|
|
|
|
I agree... it can affect readability...
|
|
|
|
|
Stefan_Lang wrote: Are you implying this is a bad thing?
I think it clutters the code.
Anyone puzzled by (for instance) STL error messages could share my opinion.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Ummm, I've never checked, but do error messages look different depending on whether or not you have a using directive? 
|
|
|
|
|
There's no relation, of course.
My point of view is: using std:: everywhere simply makes code look more cluttered and 'cluttered-looking' code is bad (as you may see in the 'really messy' STL error messages).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I've always thought that it's mostly the stuff that isn't also visible in the code, that makes compiler errors so hard to read, whereas the namespace symbols help separate the mangled symbols into managable bits that can be easier to understand.
Personally, when I look at unfamiliar code and try to locate a problem, seeing std:: or the like helps me exclude parts that I know I don't need to bother about. Similarly, when I try to understand what a particular piece of code does, I often start with the bits that call out 'STL' to me, because that is what I have the least trouble to grasp. In short, to me the namespace qualifiers within the code are more helpful than obstructive.
Of course, it might depend on the code you're looking at. If you're faced with types like
std::list<std::pair<MyClassA, MyClassB>, MyAllocator<std::pair<MyClassA, MyClassB> >::const_iterator
then you're in need of a typedef or two 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
