|
Hi Mykel,
This is EXACTLY what I was looking for! It solves the problem.
Thank you very much,
Ilan
|
|
|
|
|
int main()
{
int *ptr[2];
if(ptr[0] = null)
{
cout<<"this is empty"<
|
|
|
|
|
it is related to compiler.
E.g.
int i; //or a pointer
the value of i may be initialized as zero by some compiler, but not all.
good habit is that you initialize them yourself.
u can change code as:
===========================
int main()
{
int *ptr[2];
//====== initialize all to null
int i,iNum=sizeof(ptr)/sizeof(ptr[0]);
for(i=0;i<iNum;i++) ptr[i]=0;
//====== end enitilization
if(ptr[0] = null)
{
cout<<"this is empty"<<endl;
}
<hr style="margin ; width:405; text-align: left;">A nice <b><a style="text-decoration: underline;" href="http://www.syncedit.com/software/hypercare/" target="_new">tool</a></b> for optimizing your Microsoft <font color="#ff0000">html-help</font> contents.
Includeh10
-- modified at 9:41 Sunday 15th January, 2006
|
|
|
|
|
In addition to previous comment also change:
if(ptr[0] = null)
to:
if(ptr[0] == null):->
Michel Wassink
We must make user friendly software. Where are friendly users?
|
|
|
|
|
1. In a debug compile, the ptr[] array will be initialized to zero's. In a release compile, it will be random data. As a rule, always initialize your data.
2. if (ptr[0] = NULL) does an assignment inside an if , which is not good practice.
int main()
{
int *ptr[2];
for (int i = 0; i < 2; i++) {
ptr[i] = NULL;
}
if (ptr[0] == NULL) {
cout << "this is empty" << endl;
}
}
Software Zen: delete this;
|
|
|
|
|
Try this :-
int* ptr[2]={0};
cout << ptr[0] << endl;
cout << ptr[1] << endl;
Regards,
Nish
|
|
|
|
|
if u can use the class
CPtrArray
it has a construtor
Vikas Amin
Embin Technology
Bombay
|
|
|
|
|
#include<iostream>
#include<string>
using namespace std;
int mian()
{
string input;
char *driver;
cout<<"please input the drivers name :";
cin>>input;
cin.ignore();
driver = new char[strlen(input)+1];
return 0;
}
how come this dont work?
i am just trying to find the strlenght of input pls help me find and solve this
|
|
|
|
|
why do not add
cout<<strlen(input);
to see="" its="" length?
=""
<hr="" style="margin ; width:405; text-align: left;">A nice tool for optimizing your Microsoft html-help contents.
Includeh10
|
|
|
|
|
Try :
string input;
char *driver;
cout << "Please input the driver's name : ";
cin >> input;
driver = new char[input.length() + 1];
strcpy(driver, input.c_str());
driver[input.length()] = 0;
cout << driver << endl;
Regards,
Nish
|
|
|
|
|
i tryed it and it works thanks and i understand it too
but i wanna know wht do i need this?
driver[input.length()] = 0;
y shld assigh to 0??
|
|
|
|
|
neodeaths wrote: i tryed it and it works thanks and i understand it too
but i wanna know wht do i need this?
driver[input.length()] = 0;
y shld assigh to 0??
C/C++ strings are considered to be 0-terminated. If you don't terminate your string with a 0, any function that expects a 0-terminated string would run into issues.
Regards,
Nish
|
|
|
|
|
Nishant Sivakumar wrote: C/C++ strings are considered to be 0-terminated. If you don't terminate your string with a 0, any function that expects a 0-terminated string would run into issues.
Yes, but strcpy also copies the teminating '\0'.
|
|
|
|
|
Roland Pibinger wrote: Yes, but strcpy also copies the teminating '\0'.
Yeah
What was I smoking, eh?
Thanks.
Regards,
Nish
|
|
|
|
|
neodeaths wrote:
driver = new char[strlen(input)+1];
You probably don't need this line of code since you can access the driver name as const char* with input.c_str() .
-- modified at 11:38 Sunday 15th January, 2006
|
|
|
|
|
I am interested in doing a bit of DirectX coding. I don’t have to do anything cutting edge and to simplify distribution I would like to code against DirectX 8.1. Do I specifically need to develop against the 8.1 SDK?
Or is it all COM and as long as I stick to 8.1 functionality I can develop against the 9 SDK and run on 8.1?
Cheers
Rich
|
|
|
|
|
The purpose of the COM implementation of DirectX is for the runtime to be able to support applications written with previous versions of DirectX than the currently installed version of the runtime.
When you install the DirectX SDK, you must develop with its functionality. The previous interfaces are not included in the development version. The D3DX support library must be used with its new function formats and interfaces as well.
For example, I had to update an application written with a previous version of DX 9.0, when I was using the June 2005 SDK. The implementation of starting and ending a shader pass had changed and would not compile with my version of the SDK.
|
|
|
|
|
I have macros LOG1 to LOG5 for logging that aid debugging in my application. However with increased logging my application is effectively getting slowed down, so much to the extent that that application now takes 100 times longer.
While it is very hard to reduce to the number of log messages, i suspected most of the time is spent on writing the log message to the disk. So I implemented a buffered logger that writes to the disk only if the log buffer crosses 1 Mb. Although this has helped, for some reason I am not able to identify, the app is still slower than i am expecting.
Would it help if I offload the disk writing work to another "process" by sending the log messages to that process through a pipe or socket? I am interested in knowning people's experience, and if this will help I would like to know if it is worth implementing.
thanks!
|
|
|
|
|
Britley wrote: I have macros LOG1 to LOG5 for logging that aid debugging in my application. However with increased logging my application is effectively getting slowed down, so much to the extent that that application now takes 100 times longer.
How many log messages do log per unit of time? LOG1 ... LOG5 mean log levels that you turn on/off? How are the LOG1, ... LOG5 macros implemented? Are arguments always evaluated?
|
|
|
|
|
The arguments are not always evaluated. The LOGX imacro is implemented like this:
<br />
void _log(const char *format_str, ...);<br />
#define LOG1 if (logleve >= 1) _log<br />
#define LOG2 if (logleve >= 2) _log<br />
#define LOG3 if (logleve >= 3) _log<br />
I have not measured the number of log statements per unit of time, I am yet to add timestamps to the log messages. I havent added it just to avoid additional CPU cycles on the timestamp formatting. For the debugging to be fruitful I have to set the log level to 5 which outputs maximum number of log messages. I remember with log4j there was a way to redirect the log messages to another message, that is what makes me curious if that is going to help me here.
thanks!
|
|
|
|
|
Britley wrote: I have not measured the number of log statements per unit of time, I am yet to add timestamps to the log messages. I havent added it just to avoid additional CPU cycles on the timestamp formatting. For the debugging to be fruitful I have to set the log level to 5 which outputs maximum number of log messages. I remember with log4j there was a way to redirect the log messages to another message, that is what makes me curious if that is going to help me here.
It's difficult to decide if you simply write too much or if you have a bottleneck in your logger implementation. In the first case interprocess communication would not help you much because it only moves the problem to another location.
|
|
|
|
|
I get your point. I have been using my logger implementation for the past several months and its been doing well if the number of messages are not that many. I understand that IPC is not going to help if the IPC call takes as much longer as the original log call would take, but in my mind I was planning to implement a slow-reader/fast-writer model for the logger where the logger which is the slow reader will run from a seperate thread and will read the common buffer at a slower pace.
before I go ahead implement this, I also would like to profile my logging system. may be adding timestamps would help. Since the apps can be multithreaded profiling is going to be tricky. Any tips you have is appreciated.
thanks!
|
|
|
|
|
I use the event log manager API e.g. ReportEvent().
I created a new log for my 'company' so as not to poulute the Application, Security, or System logs. So far it has worked well.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
In my experience, the bottleneck very often is the sprintf()-statement, and it's variants, of course.
All variants of sprintf (and CString::Format(v)) is extremely time- and CPU-consuming.
For performance, it's always better to use strcpy, strcat, ltoa, e.t.c.
I once had a loop with bad performance. I could improve that loop with a factor 7 (!) just by replacing sprintf with strcpy, strcat and ltoa.
Kakan
|
|
|
|
|
The app that I am currently writing uses simulated mouse clicks to interact with controls on another program's window using Send/PostMessage() calls. I have successfully dealt with pushbuttons, radio buttons, edit boxes and comboboxes, but have now come up against one that won't cooperate ! It is a SysDateTimePick32 control which is used to input dates and times (surprisingly !!). Normally, one can left-click on one of the 3 fields within the control, that field would highlight, and then you could use keyboard input to change the value. In my app, I have (basically) used the same sequence of ops as I would to interact with an edit control. (Get the hwnd for the control, position the cursor over the target field, WM_LBUTTONDOWN/UP to highlight it, and then WM_SETTEXT to attempt to modify the text). This all works except that the text does NOT change (I have checked the message flow in MS SPY++, and it gets a TRUE response to the WM_SETTEXT. I'm baffled ! Surely, if the user can interact with this control in real life, I SHOULD be able to simulate his actions with messages ?? Anybody has experience of the SysDateTimePick32 control in this respect ? Any suggestions appreciated, as my app is dead unless I can get over this !
Doug
|
|
|
|