|
kumar sanghvi wrote: May i know how the static variable is stored in memory...
I'm not sure what you mean by this. The variable is stored in the program's data space and exists for the life of the program.
kumar sanghvi wrote: and is it right if i declare static variable inside class but not outside the clas...
A static declared inside a class is a class variable and can only be accessed through the class name. A static declared outside a class may be accessed directly in a function, module or application depending on where it is declared.
I suggest a re-reading of the C++ documentation on variables for more information.
|
|
|
|
|
Alright, I've ran into a problem that I'm really confused over:
I'm writing a simple mail client. It runs fine on my computer (Windows XP, SP2). However, when ran on a Vista machine, it crashes. Not as in BSOD-crash, it's more like the whole system just freezes over. A friend of mine, who was testing it on her vista machine, she says that everything just freezes (including the mouse) and the few times she had music on,
*the last few times
*i had musci on
*but not this time
*and it like..
*Stutters
*in that spot
I managed to trace it down to here:
MessageBox(NULL,"got here 1","okay",MB_OK);
closesocket(hSocket);
hSocket = NULL;
MessageBox(NULL,"got here 3","okay",MB_OK);
The first msgbox shows, but the second doesn't. (friend of mine isn't exactly computer-savvy, so I put the messageboxs in there so she could test the app).
I'm really stumped by this, because it works fine on XP. What does Vista change that doesn't allow the proper disconnection and closing of a socket?
If it changes anything, this is all happening in a seperate thread, started by a call to AfxBeginThread inside a WH_KEYBOARD_LL callback function. But that shouldn't make a difference, should it?
If any more info is needed, just ask. It's a rather large piece of code, so it's hard for me to describe everything that's going on.
Thanks in advance. 
|
|
|
|
|
Did you try it on more than one Vista machines? Does it crash at the same spot on every vista computers? You mentioned that it is happeneding in a separate thread, so, could it be a synchronization error? I mean, synchronization errors tend to be different depending on a lot of things, for example we had such error(s) that would never pop up on a single core muchine but they would happen almost every time on dual core systems, also they can depend on timings, for example you could have such an error that doesn't pop up at first but if you run winamp and start playing your favourite music then it does because if the computer has more things to do then your process/threads get less CPU time and then somethings that before did not happen simulteniously before will happen now and cause the problem...
Also, are you sure your hSocket is valid?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
Again, sorry for the vagueness.
No, I haven't tried it on more than 1 Vista machines, and I doubt it's a synchronization error. All the thread does is create an email header and sends it, while the main thread is open for the UI. Aside from the 4 variables passed to the thread at the start, the thread doesn't even use any of the variables used in the main thread.
Yes, I'm sure my hSocket is valid, as I seem to be able to send emails using it.
I'm going to try it on some more vista machines today, thanks for the suggestion.
|
|
|
|
|
hxhl95 wrote: If it changes anything, this is all happening in a seperate thread, started by a call to AfxBeginThread inside a WH_KEYBOARD_LL callback function. But that shouldn't make a difference, should it?
Introducing multiple threads will always make a difference. Race conditions, sharing of resources, deadlocks, and context switches are just some of the things that come into play above and beyond the normal stuff.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
im develping a Win32 Program with the name """"Add"""" that takes a """string""" as input at command line. The command line argument should be of the following format (commandline argument may be provided from DOS console):
D:\Add\Debug>Add 2,4
The program will extract the integer values from commandline string (e.g. it will extract the values “2” and “4” in above argument) and will add them, finally the result will be displayed in a message box:
wht i did so far
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE prevInstance, LPSTR lpCmdLine, int nShowCmd)
{
LPWSTR *szArgList;
int argCount;
szArgList = CommandLineToArgvW(GetCommandLine(), &argCount);
if (szArgList == NULL)
{
MessageBox(NULL, L"Unable to parse command line", L"Error", MB_OK);
return 10;
}
for(int i = 0; i++; i < argCount)
{
MessageBox(NULL, szArgList[i], L"Arglist contents", MB_OK);
}
LocalFree(szArgList);
return 0;
}
|
|
|
|
|
can anyone help me to complete it ,im stuck
thanks
|
|
|
|
|
Is your application compiled with UNICODE support?
Write your WinMain as _tWinMain.
Also you command line must look like Add 2 4.
Your for loop is wrong.
It must be -
for (int i = 0; i < argCount; ++i)
{
MessageBox(NULL, szArgList[i], L"Arglist contents", MB_OK);
}
|
|
|
|
|
did you mean the fllowing code i tried? having errors
really not getting through !! kindly help me
what i want to have is
------------------------
a Win32 Program with the name “Add” that takes a string as input at command line. The command line argument should be of the following format (commandline argument may be provided from DOS console):
D:\Add\Debug>Add 2,4
The program will extract the integer values from commandline string (e.g. it will extract the values “2” and “4” in above argument) and will add them, finally the result will be displayed in a message box:
-----------------------
what i did
#include "stdafx.h"
int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
LPWSTR *szArgList;
int argCount;
szArgList = CommandLineToArgvW(GetCommandLine(), Add 2 4 );
if (szArgList == NULL)
{
MessageBox(NULL, L"Unable to parse command line", L"Error", MB_OK);
return 10;
}
for (int i = 0; i < argCount; ++i)
{
MessageBox(NULL, szArgList[i], L"Answer is", MB_OK);
}
LocalFree(szArgList);
return 0;
}
|
|
|
|
|
Get a book and learn the basics.
Assignment questions are not appreciated here.
|
|
|
|
|
Ok, so what exactly is the problem? Hint: "It doesn't work" does not qualify as an answer.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Hi,
I have successfully implemented serialization of various collection classes even when the data contained CStrings so I'm very familiar with the requirements.
However, I have attempted to serialize a CArray <myclass, myclass&=""> MyCArray from a CPropertyPage class (to save various page defaults) and I noticed that the following serialize overrides are never executed when MyCArray.Serialize(archive) is called and CStrings recovered from the archive are either empty or have a bad pointer. Integers recovered from the archive are correct.
CMyClass : public CObject
{
DECLARE_SERIAL(CMyClass)
public:
void Serialize(CArchive& ar);
....
}
class CMyPage : public CPropertyPage
{
DECLARE_DYNAMIC(CMyPage)
public:
CArray < CMyClass, CMYClass& > MyArray;
.....
}
MyClass::Serialize(CArchive& ar)
{
}
and
template <> void AFXAPI SerializeElements < CMYClass > (.....)
Assuming there no's easy fix, is there another simple method could I use to save a small amount of default data to disk (integers and CStrings). I'm just trying to allow the user to save the various property page settings so they do not have to enter them each time.
Thanks
P.S. What's really strange and really frustrating is that on another property page I have a CArray < CString, CString& > MYStringArray and it serializes correctly! Could CPropertyPages have it's own Serialize function ?
modified on Saturday, November 7, 2009 9:12 PM
|
|
|
|
|
Try changing DECLARE_DYNAMIC(CMyPage) to DECLARE_SERIAL(CMyPage)
|
|
|
|
|
Superman,
DECLARE_SERIAL did not help but I forgot to mention that in the module where I write the archive, I have some test code which immediately reads back the archive. In this case, the CArray is always correct.
It's when the Property page is closed, re-entered and the archive read that the CStrings have bad pointers. The doubles and ints are OK. I also occasionally get some odd errors like "out of memory" or a locked buffer assertion when I exit the property page (but only when the property page has read the archive).
I can seperate the CStrings and ints/doubles into 2 different archives/files since the files are transparent to the users anyhow. As I said, a CArray < CString, CString& > serializes OK.
modified on Sunday, November 8, 2009 5:31 PM
|
|
|
|
|
Hello! I acutally program in C# and chose to start learning C++. I have two questions. One would be if I develop a C++ application using visual c++ 2008, is there a way for it to be converted to run on Mac OS X? Or do you have to write it over in a different IDE?
The main question I have is I was trying to learn from this tutorial I found on www.learncpp.com.
It seems the tutorials were geared more towards Visual C++ 2005 and not 2008 (I am using 2008).
I ran into trouble with the headers. The code I am using is from the tutorial so I am confused as to why it is not working?
I noticed a few things different. In the tutorial it doesn't include "stdafx.h" which it needs to compile. Also when trying to use a header file i get these errors:
Error 1 error LNK2019: unresolved external symbol "int __cdecl add(int,int)" (?add@@YAHHH@Z) referenced in function _main HelloWorld.obj HelloWorld
Error 2 fatal error LNK1120: 1 unresolved externals C:\C++\HelloWorld\Debug\HelloWorld.exe HelloWorld
Now I understand it is having trouble reading the add.h file but I am not sure why?
Here is my code:
HelloWorld.cpp:
#include "stdafx.h"
#include <iostream>
#include "add.h"
int main()
{
using namespace std;
cout << "The sum of 3 and 4 is " << add(3, 4) << endl;
return 0;
}
and here is my add.h:
#ifndef ADD_H
#define ADD_H
int add(int x, int y);
#endif
Any help would be great! Thanks!
|
|
|
|
|
Nevermind after looking at it again I figured out why.
I still have to include
int add(int x, int y)
{
return x + y;
}
in the HelloWorld.cpp file right? The tutorial didn't show this. IF thats why then whats the point of putting that other code in the header file when you could add
int add(int x, int y)
at the top of the HelloWorld.cpp file? Or I'm guessing you would put the whole function in the header file instead of what the tutorial just showed
|
|
|
|
|
The whole build process consists of a compilation process and a linking process.
Including the header is for the compiler to figure out the signature of the function.
The linker needs the actual definition of the function.
|
|
|
|
|
Jacob Dixon wrote: One would be if I develop a C++ application using visual c++ 2008, is there a way for it to be converted to run on Mac OS X? Or do you have to write it over in a different IDE?
If you don't use any Microsoft specific functions, you would be able to reuse the code, but you would still need to compile it using a compiler for the MAC.
As for you second question, where is the add function defined?
Is it in another module, like a DLL or a LIB file?
If so you will need to include the LIB file as a dependency in the project settings under -
Project Properties -> Configuration Properties -> Linker -> Input -> Additional Dependencies.
If it is in a .CPP file, you need to include it as part of your project.
|
|
|
|
|
Superman,
That was it, I never defined it. The tutorial just showed
int add(int x, int y) ,
It never showed the rest. So when I put this in the add.h file:
int add(int x, int y)
{
return x + y;
}
It worked perfectly. I should of known better 
Thanks for helping out!
|
|
|
|
|
in general, you should avoid putting code in a .H file.
put this in the .C/.CPP:
int add(int x, int y)
{
return x + y;
}
and put this in the .H:
extern int add(int x, int y);
that extern says "there is a function which looks like this, but is implemented somewhere else". that will satisfy the compiler. the linker will take care of the rest.
the reason you don't want to put code in a .H file is that someday you might end up #including that .H into multiple .CPP files, and when you do that, you're going to get linker errors complaining about a multiply-defined symbol called "add".
think of what #include does: the C/C++ preprocessor literally inserts the text of the .H file into the place where you did the #include, before starting the compilation. so if you #include that .H file into multiple .CPPs, you will get multiple copies of the .H file contents. and if the .H file has a function, you'll get multiple copies of that function.
about the only time you'll do implementation in a .H file is if the function is a class member function.
|
|
|
|
|
Ohhh! Ok I understand. I haven't got far into the tutorials just yet but I figure on down they line they will talk about extern and more of the best practices. Thanks guys
|
|
|
|
|
Chris Losinger wrote: about the only time you'll do implementation in a .H file is if the function is a class member function.
Or you're doing a naked inline global function. And about the only time that happens (or should IMNSHO) in C++ programs are those places you need those pesky friend functions that there's just no way around.
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
Chris Losinger wrote: about the only time you'll do implementation in a .H file is if the function is a class member function.
... or it's a template class.
modified on Sunday, November 8, 2009 3:21 PM
|
|
|
|
|
yep. i was counting that as part of the 'class member function' category.
|
|
|
|
|
Ah. Very good.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
