|
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 
|
|
|
|
|
i'll use it in a .cpp unless i'm feeling particularly masochistic that day and want to type "std::" a hundred times.
|
|
|
|
|
It's worth noting that it can be used in any scope, not just globally. For example, you could use it in a function like this:
void DoStuff()
{
using namespace std;
cout << "Yeah!" << endl;
}
You can also selectively "lift" something into a namespace with a using declaration:
void DoStufff()
{
using std::cout;
using std::endl;
cout << "Yeah!" << endl;
}
Steve
modified 1-Oct-11 2:46am.
|
|
|
|
|
Hey, thanks, I actually never thought of that!
Yes, I suppose if you have some dedicated IO functions it would be quite reasonable to add a using directive in there. Good idea! 
|
|
|
|
|
There is a great article here:
Printing Class Library[^]
on how to print. I have read the article since 1999 and am hoping there are others out there
that use this class. There is this function:
pPage->PrintRotatedText(2.30,0.72,0.50,0.85,TEXT_NORMAL|TEXT_NOCLIP,9,"some text",90*10);
which will rotate the text 90 degrees. My problem is, the text is rotated and left justified
and I need it to be rotated and right justified. If I try changing the flags to TEXT_RIGHT
or TEXT_CENTER, the text still is left justified.
Any chance, any one knows how to rotate text and make it right justified. Im trying to rotate
these numbers and it looks silly having them left justified.
Please, any response any one can give me will be greatly appreciated.
Sincerely,
Danielle Brina
|
|
|
|
|
I haven't tested this, but a quick look through the source suggests that the line
m_PrtDesc.uTextFlags = flags;
is missing in the PrintRotatedText function.
If you vote me down, my score will only get lower
|
|
|
|
|
I just tried adding that code and recompiled and it still is left justified.
Any other ideas and I'll try them. Please any response any one can give me will
be greatly appreciated.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
