|
nice thought but did you know vista is bloated piece of sh*t for some of us?
The only fine thing on it is its installer.. and the enhanced security and administration.. nobody needs ms nobody needs copyright..
but DO NOT let us discuss about Vista..
It WIL come and conquer the market..
|
|
|
|
|
are you serious ?
|
|
|
|
|
while using free() to free up calloc'ed arrays, I get the following error:
-------------------------
Debug Assertion Failed!
Program C:\...\sim.exe
File: dbgheap.c
Line:1017
Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)
For information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts.
(Press retry to debug this application)
------------ another error message i get ------
Program C:\...\sim.exe
Debug Error!
DAMAGE: after Normal block (#50) at 0x00440040
(Press retry to debug this application)
-------------------------
the exact code used is:
list=calloc(e,sizeof(int));
slist=calloc(e,sizeof(int));
nodes = (int *)malloc(nelems*sizeof(int));
.
.
.
free((void *) list );
free((void *) slist);
free(nodes);
----------------------
Does anyone know anything about this? Care to advise?
Thanks in advance...
|
|
|
|
|
You would be well-served to narrow the code down to just the statements necessary required to produce the problem. As it stands, it could be one of the other allocations, or the code that is using list, slist, or nodes.
leowwl wrote: list=calloc(e,sizeof(int));
slist=calloc(e,sizeof(int));
What is list, slist, and e? Why are the return values from the two calls to calloc() not cast to an int*?
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: Why are the return values from the two calls to calloc() not cast to an int*?
The calloc function returns a void* pointing to newly allocated data. It means that you only need to cast if the compiler complains.
regards
hint_54
|
|
|
|
|
hint_54 wrote: The calloc function returns a void* pointing to newly allocated data.
I'm aware of what it does.
hint_54 wrote: It means that you only need to cast if the compiler complains.
I don't subscribe to that philosophy. As it stands, if list is an int*, a compiler error will result unless a cast is provided. I suspect that list is a void*.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: a compiler error will result unless a cast is provided
Depends on the compiler you are using. Borland compilers (at least the older ones, don't know about the newest) would only issue a warning. You could simply ignore. I don't know wich compiler he is using, so I cant tell.
regards
hint_54
-- modified at 13:38 Thursday 6th April, 2006
Ups... I'm sorry, you are right. I didnt notice the title 
regards
|
|
|
|
|
This is a Microsoft VC++ forum and any answers given will/should reflect such.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Yes, you are right. Please reread my previous post.
regards
hint_54
|
|
|
|
|
Why don't you use new instead? (is it not c++?)
regards
hint_54
|
|
|
|
|
It happens when you allocate too small heap to keep data.
Code below causes such error:
char *buf = (char *)malloc(sizeof(char));
strcpy(buf, "longlonglong string. You allocated only one byte, just one char, how you copy so many chars in place where room is only for one char?");
free(buf);
compiler just inform you that your data are not allocated right way and may be corrupted.
-- modified at 18:37 Thursday 6th April, 2006
|
|
|
|
|
any reason why you don't use C++ memory management (new and delete) ??
|
|
|
|
|
The first one means that the heap manager does not think that you are freeing a pointer to a valid block of memory. The second usually means that you ran off the end of a block of allocated memory.
If the two errors happen on blocks of memory that were allocated back-to-back, I would think that you walked off the end of one block stepping on the next.
Check any code that copies data into the memory referenced by those pointers to make sure you are keeping the correct size constraints.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
Hi,
i have downloaded a DLL devloped in VB.NET, i want use it in VC++, i am using VisualStudio2005 IDE.The DLL name TaskPane.dll , i have take CMyFormView derived from CFromView i have taken Static Text on the CFormView , i want to replace the TaskPane control in place static at run time, add Frames to it etc..
From here i have downloaded the DLL
http://msdn2.microsoft.com/en-us/library/ms181002.aspx
How do we use VB.NET DLL in VC++...?
Thanks in before
JamesRocky.
-- modified at 11:52 Thursday 6th April, 2006
|
|
|
|
|
RockyJames wrote: i want to replace this...
With what? What does this have to do with using a DLL?
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
This DLL is to creat Windows Xp Style ExplorerBar. on the view.
|
|
|
|
|
Hi all 
I have found following code and have some questions :
void CCOde::Foo(LPCTSTR lpszFont, int iSize)
{
ASSERT(iSize > 0);
ASSERT(iSize <= 72);
ASSERT(lpszFont);
ASSERT(AfxIsValidString(lpszFont));
if (iSize > 0 && iSize <= 72 && lpszFont && AfxIsValidString(lpszFont))
{
}
}
Why is this coder writing so many ASSERT-s here when after he anyway checks the same conditions in if operator ?
I am a little bit confused...
Could someone also give me a good samples where I will see the neccessity of ASSERT macros ? Why are they
useful ?
thank you
-- modified at 10:57 Thursday 6th April, 2006
|
|
|
|
|
Because it is much easier to debug. If you call the function and did something wrong when passing the parameters, with a simple if case, you need to pass an error back and then you need to check for this error everytime you want to use the function.
Here you just have an assert that will be fired if something went wrong.
|
|
|
|
|
Surviving the Release Version[^] and go to the ASSERT and VERIFY paragraph (about average the page).
ASSERT purpose is to test an assertion, that mean the "equality" of a variable with a certain value.
|
|
|
|
|
There is a good answer to this question, but you, as the programmer, have to make a design decision about Foo(). The question you should ask is this:
Is it legal for another programmer to call Foo() with a null pointer?
or phrased differently:
If a programmer passed NULL to Foo(), would that be a bug in the calling code?
If you decide that getting NULL is an illegal condition (based on how you designed Foo()) and indicates a bug in the calling function, then you should use ASSERT. If, on the other hand, Foo()'s design makes getting a NULL pointer reasonable, and would not indicate a bug in the caller, then you should be using the if.
You'd use both when getting a NULL would indicate a bug, and when you'd still want the code to behave intelligently even when it gets garbage. The typical scenario would be aircraft controller software, or radiation machine software. Bugs in either of these pieces of software could be deadly and so you'd keep the if just in case a bug makes it into the final code. Hopefully the ASSERT would alert you to the bug long before then.
Probably the best way to figure out whether to use an ASSERT or an if is to follow this guideline:
Completely finish the function as you intend to ship it. Once you're convinced that you've got the code as you plan to ship it, _only then_ do you add assertions (and debug code), _without_ changing what your ship code does.
Remember, debug code is strictly _extra_ code.
Using this guideline, you can see that if your ship code has to handle NULL pointers, then you have to use an if statement to handle the NULL pointer. If the ship code doesn't have to handle the NULL pointer, then you can ASSERT that getting one is illegal so that it alerts callers to their bugs.
The main difference between ifif tests are for conditions that you plan to deal with. Assertions should not take the place of normal error-processing code. They should be used to flush out defects in your code. Put differently, an assertion should never fire unless there is a defect.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
-- modified at 11:51 Thursday 6th April, 2006
|
|
|
|
|
Hi All,
I have a application that uses buttons, combo box's etc. Using VS2005 Express in debug mode, all the controls are in the XP theme. But if I build the same image in release mode, the controls revert back to 95/98 controls. Now if I make the linker not embed the manifest, then I add the following lines to the manifest file:
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
</dependentAssembly>
</dependency>
And all is well. But now, how do I get the linker to embed it in the exe?
regards,
Rich
"Programming today is a race between software engineers striving to build bigger and
better idiot-proof programs, and the Universe trying to produce bigger and better idiots.
So far the Universe is winning." -- Rich Cook
|
|
|
|
|
You add the manifest file to the executable's resources with a specific Resource Type (that I cannot remember at the moment, but a Google search should help you out here).
You could also place the manifest file in the same run directory as the executable when it is deployed and that will work, too.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
Thanks. I have taken the later option, but now run against the problem where people will complain if they have to copy 2 files (the previous version was just an exe).
Do you know how to add it to the resources using VS2005 Express?
Express complains that it is not able to edit resources when I tried to open a .rc file.
regards,
Rich
"Programming today is a race between software engineers striving to build bigger and
better idiot-proof programs, and the Universe trying to produce bigger and better idiots.
So far the Universe is winning." -- Rich Cook
|
|
|
|
|
Hi,
Are there any Artices or Code to implement Windows Xp Style Explorer Bar in and MDI application.
Thanks in Before
JamesRocky.
|
|
|
|
|
Following is the code from MFC frame work,
if I call "pThread->InitInstance()" method application is calling CWinApp->InitInsatnce() method,
CWinThread is super class of CWinApp when I call with super class object "InitInsatnce" method
it should call CWinThread:InitInstance method,
how it is going to sub class,
can any body explain to me
thanks,
Siva
---------------------------------------------------------------------
int AFXAPI AfxWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPTSTR lpCmdLine, int nCmdShow)
{
ASSERT(hPrevInstance == NULL);
int nReturnCode = -1;
CWinThread* pThread = AfxGetThread();
CWinApp* pApp = AfxGetApp();
// AFX internal initialization
if (!AfxWinInit(hInstance, hPrevInstance, lpCmdLine, nCmdShow))
goto InitFailure;
// App global initializations (rare)
if (pApp != NULL && !pApp->InitApplication())
goto InitFailure;
// Perform specific initializations
if (pThread->InitInstance())
{
if (pThread->m_pMainWnd != NULL)
{
TRACE0("Warning: Destroying non-NULL m_pMainWnd\n");
pThread->m_pMainWnd->DestroyWindow();
}
nReturnCode = pThread->ExitInstance();
goto InitFailure;
}
nReturnCode = pThread->Run();
InitFailure:
#ifdef _DEBUG
// Check for missing AfxLockTempMap calls
if (AfxGetModuleThreadState()->m_nTempMapLock != 0)
{
TRACE1("Warning: Temp map lock count non-zero (%ld).\n",
AfxGetModuleThreadState()->m_nTempMapLock);
}
AfxLockTempMaps();
AfxUnlockTempMaps(-1);
#endif
AfxWinTerm();
return nReturnCode;
}
---------------------------------------------------------------------------------
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
