|
|
Each item in the list box has a bind data( set with the func 'SetItemData') , if I delete the item which who's index is 7(based zero), so now , is the new 7 indexed item has the last eighth item's data or seventh 's data ?
|
|
|
|
|
the new 7 indexed item will be the old 8th item(with its data set with SetItemData). list box will handle this internally whenever you delete an item from it.
If you set a pointer to some dynamically allocated memory as SetItemData(index, ptr), take care to delete that memory before removing the list box item, if you don't need that memory again.
|
|
|
|
|
Thank you! I just know where are you come from? 
|
|
|
|
|
you may email the forum members for further activitiees.. no such discussions here please.
|
|
|
|
|
Hi I want to find the number of comma(,) in particular string.
Like char* str = "a,b,c,d,e". So how many commas are there in str ?
Thanks
|
|
|
|
|
Use strchr in a loop.
char* str = "a,b,c,d,e";
int count = 0;
for (;;)
{
str = strchr(str, ',');
if (NULL == str)
break;
++str;
++count;
}
|
|
|
|
|
std::count is your friend. It does exactly what you'd expect it to do from it's name. The only problem you're likely to have is working out where the end of the characters in memory are, but if you're feeling lazy bung the characters in a std::string first:
std::string s( str );
std::cout << "There are " << std::count( s.begin(), s.end(), ',' ) << " commas in " << s << std::endl;
Cheers,
Ash
|
|
|
|
|
char c;
int commas=0;
while((c=*str++)!=0) if (c==',') commas++;
|
|
|
|
|
const char *p = "a,b,c,de,f,";
int c = 0;
for (;*p;c+=(','==*p++));
|
|
|
|
|
Ahh, the joys of C++. Did you make it so complex on purpose, or is all your code written like that ? 
|
|
|
|
|
That was classic Kernighan and Richie C!
Sheesh, youngsters of today...
Whippersnapper!
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
[Untested]:
std::string str("a, b, c, d, e");
int count = std::count(str.begin(), str.end(), ',');
or if you insist on C-style strings:
int count = std::count(str, str + strlen(str), ',');
|
|
|
|
|
The inline ASM version is still missing, anyone? 
|
|
|
|
|
I think is interesting to compare the solutions.
Note: The "trivial" algorithm is to scan the string and count the ','.
Now:
Superman: Just did that using CRT: no additional data are added, and the strchr function is made walking from ',' to ','.
Aescleal: Made an elegant use of STL algorithms.
But: a constant literal is copied into a temporary std::string (probably with also a dynamic array allocated by the class itself), creates two temporary iterators, passing them to the std::count algorithm that just do the loop.
Luc Pattyn: Use a more concise loop.
Chris Losinger: same. Very elegant, but more cryptic.
Nemanja Trifunovich: Same a Aescleal, but also propose to use std::cout with const char* instead of std::string::iterator-s, eliminating the need of the conversions.
Moral of the story: I'm starting to believe that STL - and in particular "strings" are over-evaluated.
The more coincise and elegant (together) is probably the second Nemanja proposal.
But one question makes me wonder:
Suppose I'm a coder asked to do this task, and suppose I know the algoritm, but i'm not expert in the language libraries: what should be fastest for me?
- Read the STL documentation -probaly in strict alphabetic order- trying to guess is there can be something that can help me in counting the ',' (I'm luky the <algorithm> header come as first and the count function is one of the firsts ... estimated time: 15 minutes - but supposing I already know the "iterator"/"container"/"algorithm" model)
- Just write
unsigned count_chars(const char* s, char d)
{
unsigned c=0;
for(unsigned int i=0; s[i]; ++i)
if(s[i]==d) ++c;
return c;
}
actual time 2 minutes! And the best of efficiency (no spurious allocation and copies)
<sarcasm>Do yo understand the beauty of STL ?!?</sarcasm>
(NOTE: using indexes, instead of incrementing pointers, is actually more efficient when translated into todays processor's code)
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
An interesting comparison, Emilio!
My two cents. I think someone who has encountered this kind of problem before (data manipulation, string parsing) will need the equal amount of time for either a handcoded C-string solution (e.g. Luc's) or using a library solution (e.g. Aescleal's). Let's say 1 minute. Someone who does it the first time, would probably do the same as when I write something in a new language, you Google for examples and then use the first code snippet you like (probably it's not the best solution but a working one). Let's say 5 minutes.
Cheers,
M
PS: The beauty of STL glows in less trivial examples. The iterator design pattern in particular is a nice idea in my opinion, it gives you a decoupling of data object and algorithm, e.g. you can use the same algorithm with a wide range of objects... and only have to learn it once = time saved.
|
|
|
|
|
Moak wrote: The beauty of STL glows in less trivial examples
Oh yes ... but reality is different: it is a matter of fact that vector (sequential indexed), list (sequential) and map (indexed) don't have same interfaces, and that the most of stl algorithm that are "non trivial" works with "sequential indexed" (aka "random access") iterators.
Two siple example:
std::list<int> alist;
std::vector<int> avector;
alist.remove(10);
avector.erase(std::remove(avector.begin(),avector.end(),10),avector.end());
Until someone doesn't demonstrate me how can I come to write the second example without having the knowledge of at least 20 pages of documentation (yes, I want a 8 y.o. baby coding that!), I will consider "you can use the same algorithm with a wide range of objects... and only have to learn it once = time saved." a pure marketing lye.
(The fake is that vector doesn't have a remove function, hence is not dual to list, and std::remove doesn't remove: it just swaps things around. You cannot know that unless someone tells you)
The pattern itself can be a good idea (iterators as a bridge between collections and algorithms) but the way is implemented is far from being obvious.
That's the point i was considering.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Please have a breakfast before making angry morning postings.
|
|
|
|
|
I have two applications, both of which I have written.
AppA was written in C++ using MFC. During startup it registers a CSingleDocTemplate and creates a document. The document provides a COM interface and registers itself in the ROT:
LPUNKNOWN punk = GetInterface(&IID_Welder);
::RegisterActiveObject(punk, CLSID_Interface, ACTIVEOBJECT_WEAK, &m_dwRegister);
AppA revokes the entry in the ROT when it is destroyed:
if (m_dwRegister)
::RevokeActiveObject(m_dwRegister, NULL);
The destructor is only called when AppA terminates.
AppB is written in C# and is a client of the interface provided by AppA:
private void Connect()
{
welderInterface = (Welder.Interface)Marshal.GetActiveObject("Welder.Interface");
Marshal.GetIUnknownForObject(welderInterface);
}
private void Disconnect()
{
if (welderInterface != null)
{
Marshal.ReleaseComObject(welderInterface);
welderInterface = null;
}
}(error handling omitted for clarity)
That all works perfectly the first time AppB runs after AppA has started; AppB can call Connect and Disconnect as often as it wants and use the interface between. However, if AppB terminates and runs again (AppA still running) the interface is no longer available - Marshal.GetActiveObject throws an exception from MK_E_UNAVAILABLE. The only way to make the interface available again is to restart AppA - not an acceptable solution!
Please can someone suggest how I might fix this?
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
modified on Monday, August 2, 2010 7:16 AM
|
|
|
|
|
My guess is that when you do this:
Phil J Pearson wrote: Marshal.ReleaseComObject(welderInterface);
your object's reference count reaches zero and it gets destroyed. If this is your COM object, try initializing its reference counter to 1 (i guess it is zero now), or AddRef it after creation and Release when your AppA exits.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
No, that's not it. as I said:
1. The destructor is only called when AppA exits (checked in the debugger).
2. AppB can call Connect and Disconnect many times without problem. The problem only occurs when AppB exits. There's nothing special done with the interface on exit.
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
How did you check that your interface isn't deleted when AppB exits? I mean,
Phil J Pearson wrote: (checked in the debugger).
explain this, please.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Logging code and breakpoints in the doc destructor and in the doc OnFinalRelease. Only called when AppA exits - not AppB.
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
Oops! Sorry! I take back my earlier rejection of your reply.
It seems that the interface was being destroyed even though the document that implements it was not.
I AddRef'd the interface in the doc constructor and Release'd it again in the destructor as you suggested and the problem is solved.
Thank you!
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
It happens...great it works now. 
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)