|
Use sizeof(arr) / 4;
#include <stdio.h>
void main()
{
int arr[] = {1,2,3,4,5};
int x = sizeof(arr)/4;
printf("sizeof(arr) = %d \n", x );
}
|
|
|
|
|
int main()
{
int a[] = {1,2,3,4,5};
printf("%d",sizeof(a)/sizeof(int));
getch();
}
|
|
|
|
|
hi everyone
i have a question
how can I compute space complexity O()?
and is it any already function in C++ to compute it?
|
|
|
|
|
moathyy wrote: hi everyone
i have a question
how can I compute space complexity O()?
Studying the problem.
moathyy wrote: and is it any already function in C++ to compute it?
No.
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]
|
|
|
|
|
The whole point of complexity analysis is finding an estimate based on certain premises, usually the premise that this is a worst-case scenario. The only way to find out about that is knowing the whole program and the algorithms involved in that scenario.
For a full analysis you'd need to find all possible call paths, then start at the lowest level, i. e. functions that do not call any other functions, and analyze their complexity. The you go a level higher and do the same, using the complexity values you've already calculated from the lowest level functions. So you work your way up, until you are able to determine the complexity of main().
Of course, it isn't quite as easy as that: If you use multithreading you will need to consider the cost of synchronisation, and at the same time consider shared resources, and make sure you don't count them multiple times. If you have recursive calls, you need to determine the recursion depth. And worst of all, for every conditional branch, including end-of-loop conditions , you need to estimate the likelyhood for each branch.
Also, space complexity has the added complication that it can be reduced temporarily, making it impossible to determine the complexity of multi-threaded applications.
The biggest problem however is, that even the lowest level functions in your application may need to call system functions, drivers, or other external functionality that you don't possess any complexity information about.
Currently there is no system that can automate this process. And a full-fledged analysis of the whole system as described above is impossible to do manually for all but the most trivial applications. So the only way to do this is by looking at the parts of the system that you think are most critical and important to your users, and manually estimate the complexity for that.
|
|
|
|
|
Hi,
I am developing application which is launched by another application. I wanted to notify the parent application (the launcher) that the task successful or failed. So I need to pass the main window handle of the launcher application to my second application like /CallingProgramWindow="0001009C". Then how can i convert the string back to window handle. And is this method is the right way to do this.? I am using VC++ to develop the application.
Thanks
Nitheesh
Nitheesh George
http://www.simpletools.co.in
|
|
|
|
|
As far as converting to HWND goes, a handle is really a void*, so all you need to do is to parse a HEX number into a void pointer. I do not know if this is the right approach, but I think it has a good chance of working. If it does not work, you could try a less reliable method of passing coordinates of, say, the upper-left corner of the window, and then call WindowFromPoint[^] on it.
|
|
|
|
|
While this may work, I am not sure that it is the 'correct' way to implement what you want. It may be better to use the Process functions (CreateProcess etc) and use the return value form GetExitCodeProcess()[^].
The best things in life are not things.
|
|
|
|
|
There are several ways to make the two processes communicate. The way you depicted is actually feasible, just use the strtoul[^] function to convert the string.
Another simple way would be using the RegisterWindowMessage[^] mechanism.
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]
|
|
|
|
|
Nitheesh George wrote: So I need to pass the main window handle of the launcher application to my second application like /CallingProgramWindow="0001009C". Then how can i convert the string back to window handle. And is this method is the right way to do this.?
Unlikely.
What exactly do you want to do with the handle in the second app?
In general you solve the problem like this.
1. Target app runs
2. Target app gets to point X in app and this is considered 'succcess'
3. Target app 'sends' result to host application.
Step 2 is defined by your application.
There are several ways to do 3, such as stdio or sockets. However if you just need to know if the target ran and the host ran it then the process of actually running it would tell you that.
|
|
|
|
|
Nitheesh George wrote: So I need to pass the main window handle of the launcher application to my second application
Interprocess COmmunication[^]
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
I'm in a situation like this:
while(1){
...
recvfrom(sock, buffer, buffSize, 0, (struct sockaddr *) &ClntAddr, &clientLen);
sendto(socket, buffer, Size, 0, (struct sockaddr *) &ClntAddr, sizeof(ClntAddr);
...
}
When I call the sendto if for some reason the host is not reachable, then the next call to recvfrom () fails with error 10054 ICMP Port Unreachable. How can I avoid to capture this kind of messages, and continue to process other datagram-requests from clients?
|
|
|
|
|
|
I have a class kind of like this.
class handle
{
int m_i ;
template< typenmae T >
T* operator->()
{
if( m_i == 1 )
return new classA ;
else if( m_i == 2 )
return new classB ;
}
} ;
The problem is the compiler has no way to infer which version of the ->() function to use( produce ). But if I use something like handle<classA>->();that breaks the C++ convention. So how can I solve this kind of problem?
|
|
|
|
|
I think your return value should be the same as your typename, i.e. something like:
return new T;
Some more information can be found in MSDN here[^].
The best things in life are not things.
|
|
|
|
|
Design looks broken to me.
That can only work if classA/B are derived from T.
And as such handle<parent> would work.
If not then you have code that at best is fragile and at worst is wrong.
Other than that if you need a factory then you should probably just use one.
|
|
|
|
|
As jschell said, the only way this would even work is if you make sure that classA and classB are derived from T, otherwise the return type is wrong.
Calling the 'right' operator is only possible for the compiler if it can derive the type from the function call, either by analyzing the arguments, or by explicitely stating the type. Without arguments, you have to do the latter, and that is only possible by using the full operator name like this:
handle h;
classA* a = h::operator-> <classA> ();
That said, there are multiple design mistakes:
1. When you overload an operator, anyone taking advantage of this operator will implicitely assume that it behaves similarly as the same operator for does for other objects. In case of operator->(), the standard behaviour is 'dereferencing', i. e. delivering a reference to on object that is encapsulated within the original object. Basically, what you did is like calling a function 'add', when in truth it performs a multiplication.
2. You should always strive to indicate when a function returns an object that is created on the heap, and thus needs to be properly deallocated again. Otherwise there is a high risk that anyone else who'll work with your class in the future will forget to delete the allocated resources later. Function names like 'CreateXY', or 'Copy', indicate that a new object is being created, and you need to take care to destroy it. The dereferencing operator is usually interpreted more as a 'Get' function, indicating that its resource management is handled by someone else.
3. There's no point at all in overloading an operator, when you always have to write it explicitely to be able to invoke it. Use an explicit, normal function name instead!
4. Your class handle serves in some way as an interface to a limited number of specific classes. Unless these classes may or should be mixed up within a single handle object, it's probably a good idea to make this a template class. This would also eliminate your problem, and the need for the type indicator m_i
template <class T>
class handle {
T* operator->() {
return new T;
}
};
class classA {
public:
doWork();
};
handle<classA> hA;
hA->doWork();
classA* a = hA.operator->();
a->doWork();
delete a;
I suspect that you wanted to write something like hA->doWork();, but in doing so you'd produce a memory leak. The only way to avoid that leak would be storing the reference, but that requires calling the full operator name, negating any advantages that you might have hoped to gain from overloading an operator in the first place. If I am correct, then what you need is not a handle, but a class hierarchy with virtual functions.
|
|
|
|
|
#include <string>
#include <iostream>
using namespace std;
void Print(const string& value)
{
cout << value << endl;
}
void PrintBy (const string& value, void (*printer)(const string& value))
{
printer(value);
}
class Printer
{
public:
void Print(const string& value)
{
cout << value << endl;
}
};
int main()
{
string s = "hi";
Print(s);
// why this work?
PrintBy(s, &Print);
// but this does not work!?
Printer p;
PrintBy(s, &p.Print);
return 0;
}
|
|
|
|
|
What exactly is the problem?
"One man's wage rise is another man's price increase." - Harold Wilson
"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
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
he did label the problem, look for the comments ('//')
|
|
|
|
|
"but this does not work!?" is not a useful problem description. It could be a compiler or linker problem. It could be an assertion. It could be an exception. It could be a logic problem.
"One man's wage rise is another man's price increase." - Harold Wilson
"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
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
It is if you look at the difference between his two statements
|
|
|
|
|
|
good link! ...you may be right, I didn't think about the address being different for non-statics.
|
|
|
|
|
What do you mean by "it does not work"?... The code as written just does not compile for a simple reason: Your second call to PrintBy does not match the signature of the called function. You either declare a second overload for PrintBy taking a proper pointer-to-method of Printer or (much better) you rely on standard library abilities:
#include <string>
#include <functional>
template < typename TPrinter >
void PrintBy( std::string const & pString, TPrinter pPrinter )
{
pPrinter(pString);
}
int main()
{
::PrintBy( "hi", Print );
::Printer p;
::PrintBy( "hi again", std::bind( &::Printer::Print, &p, std::placeholders::_1 ) );
}
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
