|
Thanks for the testimonials -- I think I am going to take a look at HtmlLayout...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<a href="http://www.soonr.com">SoonR Inc -- PC Power delivered to your phone</a>
|
|
|
|
|
Hey RANDOR.
A very good library that htmlayout.
Thankx for the link.
Demian.
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my telephone."
-Bjarne Stroustrup, computer science professor, designer of C++
programming language (1950- )
|
|
|
|
|
Hi ,
I have a simple File - logging class which I plan to use in a COM Server.
I also have a template based Singleton Class ( CSingleTonT) that takes this object such that there is only 1 instance of this in the system.
I am trying to add a CComCriticalSection protected member variable and inspite of including the header for this I am getting a compilation error
<br />
#ifndef _CLOGGER_H<br />
#define _CLOGGER_H <br />
<br />
#include "atlbase.h"<br />
#include "atlcore.h"<br />
..<br />
..<br />
<br />
<br />
<br />
class CLogger <br />
{<br />
public : <br />
<br />
<br />
<br />
protected : <br />
<br />
<br />
bool m_bInitialized ; <br />
ofstream m_logfile; <br />
<br />
CComCriticalSection myCS ; <br />
<br />
<br />
string strFileName ; <br />
<br />
<br />
};<br />
<br />
Now these are the compilation errors I get
1>d:\code\com\clogger.h(172) : error C2146: syntax error : missing ';' before identifier 'myCS'
1>d:\code\com\clogger.h(172) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>d:\code\com\clogger.h(172) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
The definition for CComCriticalSection exists in atlcore.h which is included .
Any help is appreciated
Engineering is the effort !
|
|
|
|
|
Browse into "atlcore.h", and check if there is any condition around the declaration of that class type. For example:
#if (WINNT_VERSION > 5001)
class HelloEx { };
#else
class Hello { };
#endif
PS: I don't have VC++ at home now. Sorry!
Maxwell Chen
|
|
|
|
|
act_x wrote: CComCriticalSection myCS ;
I just created an ATL server project by Wizrad, and it compiles fine.
The class CComCriticalSection is in the namespace ATL. Maybe you should do this way if your class is not derived from built-in ATL classes:
ALT::CComCriticalSection myCS;
Maxwell Chen
|
|
|
|
|
Hello,
How do u get double pointers address in memory?
<br />
char **String;<br />
I need to get String's address?<br />
is there a way to get it?<br />
thanks
It is never late to learn
|
|
|
|
|
Gofur Halmurat wrote: How do u get double pointers address in memory?
AFAIK, address of any data type can be obtained by address-of operator (&).
obviously, &String. 
|
|
|
|
|
My Application crashes  by displaying the message,
"The instruction at 0x00427289 referenced memory at 0x7ffdf000. The memory could not be read. Click OK to terminate the program".
The Application works fine with debug build but fails with release build.
If anyone have any idea with this please let me know.
Thanks ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
Thanks a lot
|
|
|
|
|
|
Hey man, that was copyrighted.
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
|
|
|
|
|
ROTFL 
sorry, if i can't find the licence agreement.
Anyway keeping the author, i kept intact the owner ship.
|
|
|
|
|
Why does program work in debug mode, but fail in release mode?
A: First of all, there is no such thing as 'debug mode' or 'release mode'. The VC++ IDE offers the possibility to define configurations which include a set of project settings (like compiler / linker options, output directories etc.) When a project is created using AppWizard, you get two default configurations: "Win32 Debug" and "Win32 Release". These are just convenient starter configurations with several preset options which are suitable for typical debug builds or release builds respectively, but you are by no means restricted to those settings. Actually, you can modify those configurations, delete them, or create new ones. Now let's see what the two default configurations typically include and what distinguishes them:
Win32 Debug:
Subdirectory 'Debug' used for temporary and output files
Preprocessor symbol _DEBUG defined
Debug version of the runtime libraries is used
All compiler optimizations turned off
Generate debug info
Win32 Release:
Subdirectory 'Release' used for temporary and output files
Preprocessor symbol NDEBUG defined
Release version of the runtime libraries is used
Various compiler optimizations turned on
Generate no debug info
There are a few other differences, but these are the most important ones. Now, what's the first implication of all this? That, as opposed to a common misunderstanding, you can debug a release build. Just go to 'Project -> Settings', choose the Win32 Release configuration, tab 'C/C++', 'General' and set 'Debug Info' to 'Program Database'. Then go to the tab 'Linker', and turn on 'Generate Debug Info'. If you rebuild your project now, you will be able to run it in the debugger. Regardless of whether your program crashes or just doesn't behave as expected, running it in the debugger will show you why. Note however, that due to optimizations turned on in the release build, the instruction pointer will sometimes be off by a few code lines, or even skip lines altogether (as the optimizer didn't generate code for them). This shouldn't be a concern, if it is, turn off optimizations.
When debugging your release build this way, you will probably discover that at a certain point during execution, a variable has a different value in the release and in the debug build, causing the differing behaviour. And if you go back and see where the value of that variable is set, you will most probably find out that it isn't: You simply forgot to initialize that variable. The reason why the debug build seemed to work is that the debug version of the runtime library initializes dynamic memory and stack variables to known values (in order to track down memory allocation and overwrite errors), while the release version of the runtime library doesn't. This is by far the most frequent single cause for different behaviour between debug and release builds, so chances are good that this fixes your problem (and for the future, remember to always initialize your variables).
If uninitialized variables were not the cause of your problem, let's look at the next possible difference between debug and release builds: The preprocessor symbols _DEBUG and NDEBUG. If you have any code inside an #ifdef _DEBUG / #endif block, it will not be contained in a release build. What's worse, the dependency of those symbols can be hidden inside other macros. A typical candidate for this is ASSERT: It expands to the assertion testing code if _DEBUG is defined, and to nothing if it is not. Therefore, be careful to have no code with side effects inside an ASSERT macro. For example, the following code will work in a debug build, but fail in a release build:
CSomeDialog dlg;
ASSERT(dlg.Create(IDD_SOME_DLG));
dlg.ShowWindow(SW_SHOW);
As a rule, never put code which needs to be executed inside an ASSERT. (A side note: Conditions which can be expected to fail at runtime, like the 'Create()' call in the example, should never be tested with ASSERTs anyway. Assertions are a tool to assert pre- and postconditions regarding your code, not runtime error conditions.)
At this point, you have most probably found out why your code failed in the release build. If not, this might be one of the very rare cases where the compiler optimizations caused your code to behave differently (the VC++ compiler had several optimizer bugs in the past, and I doubt they have all been fixed). To exclude this, first turn all the optimizations off (Project -> Settings, tab 'C/C++', category 'Optimizations', option 'Disable (Debug)'). If your code works now, selectively turn optimization options on until you found the culprit. Simply leave it turned off, or upgrade to a newer version of the compiler (or install the most recent service packs) which might hopefully fix that bug.
This should help you get your release build running in most of the situations. For a more in-depth discussion about the differences between debug and release builds, see the excellent article Surviving the Release Version (http://www.codeproject.com/debug/survivereleasever.asp).
<br><br>
lavatema
|
|
|
|
|
You mean to reply the OP?
|
|
|
|
|
Hi! I m working on a c++ project in which I have two values one is 987654321123456789 and another is 1000000000000000000. My problem is that I m dividing first value by second value which is a decimal type value in result, when I do this I store the result in a double value after typecasting the above calculation by double but it give wrong result. The result is .98755432112346 which is wrong the exact result is .987554321123456789.
The code which I use is as -.
double dd = double(987554321123456789 /1000000000000000000)
After calculation
dd = .98755432112346
which is wrong because the actual result is .987554321123456789.
So how I do this calculation so that I get the correct result please help me regarding this
Thanks
|
|
|
|
|
nitin_pro wrote: So how I do this calculation so that I get the correct result please help me regarding this
You can't. Approximation it's the very nature of floating point numbers (possibly because memory locations can hold only a discrete set of values).
See [^].
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
|
|
|
|
|
Hi!
Actually my problem is that when I perform
double dd = double(987554321123456789 /1000000000000000000)
this calculation the result is truncated up to 15 digit and it gives result dd = 0.98755432112346
but I want result completely means up to 18 digit may be it’s the limitation of Double data type that it can only store result up to 15 digit bt if it is tn I need some other data type which can store complete result yp to 18 digit.
Pls help me to store complete result manse 0.987554321123456789 without truncation .
|
|
|
|
|
Why don't you keep it inside long long assuming implicit multiplication by 10^18?
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
|
|
|
|
|
The FPU (x87) uses 80-bit fields for its operations for loading and storing back and forth from the x87 stack. However the Microsoft run-time library sets the default internal precision of the math coprocessor to 64 bits in Windows XP. This can be controlled by the function _controlfp which is documented here:
http://msdn2.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx[^]
There are some documents where Microsoft claims the precision can be changed to the full 80 bits such as this document:
http://support.microsoft.com/kb/q263213/[^]
These documents conflict with some of the statements in this document:
http://msdn2.microsoft.com/en-us/library/y0ybw9fy(VS.80).aspx[^]
Such things are common in the MSDN. I personally believe its a documentation error or perhaps they are not explaining all of the details. I have never tried it nor tested it however. Try it and see.
Best Wishes,
-David Delaune
|
|
|
|
|
|
|
Hi,everybody. I have a little question: is there MFC Class which allows to obtain R,G,B - value of each pixels in jpeg-file?
|
|
|
|
|
CImage::Load then CImage::GetPixel()
|
|
|
|
|
|
And then use of GetRvalue or G or B.
|
|
|
|
|
m_pAnimate = new CStatusbarAnimate; cause crash with the following info below when called from thread
work fine normally, any resolution please...
The instruction at "0x00402150" referenced memory at "0x00b9004c". The memory could not be "written".
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
