.NET or VC++
-
There are still a number of environments where C/C++ projects in Windows are the only means available. Those I know of include: - Windows services - Explorer extensions - Device drivers - Any of the 'extension agents' that require a DLL with a fixed signature: SNMP, HTTP, etc.
Software Zen:
delete this;Gary R. Wheeler wrote:
Windows services
I'm sure they can be done in C#
Christian Graus - C++ MVP
-
Gary R. Wheeler wrote:
Windows services
I'm sure they can be done in C#
Christian Graus - C++ MVP
While services can be implemented using C# and the .NET framework, they're not generally practical. They're very slow to start and have a huge memory footprint compared to an equivalent C++ service.
Software Zen:
delete this; -
MS is pushing for dotnet, but they will keep on releasing SDKs like Win32, Win64 (or even Win128). Depends on where you want to be in the herd...
That does not mean there will be a sizable market though..
Rocky <>< Latest Code Blog Post: ASP.NET HttpException - Cannot use leading "..".. Latest Tech Blog Post: Blog changed to Subtext!
-
There are still a number of environments where C/C++ projects in Windows are the only means available. Those I know of include: - Windows services - Explorer extensions - Device drivers - Any of the 'extension agents' that require a DLL with a fixed signature: SNMP, HTTP, etc.
Software Zen:
delete this;- Windows services Many VB programmers were writing true Windows services in VB6. I wrote my first Windows service in VB6 back in 1998. It isn't easy, but it works quite well and is fast. It is much easier to write them in VB.NET and C#.
-
- Windows services Many VB programmers were writing true Windows services in VB6. I wrote my first Windows service in VB6 back in 1998. It isn't easy, but it works quite well and is fast. It is much easier to write them in VB.NET and C#.
I'm going to go against the flow here. While I think there are many places where .NET is the way to go, I just can't see it replacing C++ for all new apps. Large categories of apps are going to be on C++ for a long long time. And yes, I know of new apps being written in unmanaged C++. I've been looking at some time critical apps. While I'm skeptical about claims of .NET going faster then well written unmanaged C++ using a good optimizing compiler I'll pass on that because it's not my main concern about .NET My main concerns are these: 1. The garbage collector. If you're doing a little database app (retrieve stuff from the database, display it, let the user edit it, put it back in the database) or something like that it's no big deal. If you're doing a time critical app which CANNOT EVER halt to do GC I'm skeptical. I know there's things you can do with the GC to keep some of it's problems in check, but they seem to me to be overly involved compared to just being able to do delete when need be. You don't need to be an expert on heap management to use delete, you do need to know a lot about the garbage collector to keep it from shooting you in the foot sometimes. Yes I know the C++ heap can become fragmented and the GC can relieve that issue, but it's been my experience that fragmentation is hardly ever a problem, and on those RARE occasions when it is there are ways to relieve it without chucking the whole thing and using a garbage collected language. 2. I have to give up control in the memory representation in .NET which often makes it hard to write good code. C++ lets me specify exactly how an object is handled in memory -- whether on the heap or stack, passed by value or reference, const reference, whatever. With C# several times I have found myself fighting the language just to get it to produce something halfway reasonable. 3. Portability is out the window. If you're in a mixed Unix/Linux/Windows shop like I am you're going to have problems in .NET even if you're writing managed C++, whereas if you stick to ANSI unmanaged C++, portability is often very manageable. Until MS can convince other OSes to use .NET this is going to be a serious problem in some environments. 4. It's been my observation that the problems .NET always trumpets as having solved aren't nearly as bad as they make them out to be and the problems it introduces are, in some situations far more serious. I am quite capable of using delete for example but the loss of control is sometimes nasty. Yes there's many
-
Todd Smith wrote:
- Any application where performance is an issue
Supposedly that's no longer the case. I've seen a number of articles where managed code is faster than the equivalent native code. The rationale is that the just-in-time compiler and loader can perform whole-program and load environment optimizations that yield greater performance than is possible with a 'static' compiler and linker. I'm willing to believe it on a case-by-case basis, but I have my doubts under general circumstances.
Software Zen:
delete this;i've just started a project and the question of efficiency arose, and i automatically thought c++ out of curiosity though i wrote two test programs one in c++ the other in vb.net using an array of 500,000 strings and 40,000 search words on my system Athlon XP 64 3000+ in vb.net i used the binarysearch function it took around .22 of a second on average to complete in c++ i used the below function since i don't know of any built in functionality it took around .3 of a second on average to complete i also tried using the same algorithm below in vb.net and i can't remember the time, but it was slower than the built in function basically i've found if you can't find the functionallity built into vb.net and have to write it yourself it will slower, i didn't want the hassle of writing things in assembly in c++ either just so i could get more efficiency than vb.net int binarySearchRecursive(string* a, string* value, int left, int right) { int mid; if(right < left) return -1; mid = (int)floor((float)(left + right) / 2); if (_stricmp(value->c_str(), a[mid].c_str())<0) return binarySearchRecursive(a, value, mid + 1, right); else if(_stricmp(value->c_str(), a[mid].c_str())>0) return binarySearchRecursive(a, value, left, mid - 1); else return mid; }
-
i've just started a project and the question of efficiency arose, and i automatically thought c++ out of curiosity though i wrote two test programs one in c++ the other in vb.net using an array of 500,000 strings and 40,000 search words on my system Athlon XP 64 3000+ in vb.net i used the binarysearch function it took around .22 of a second on average to complete in c++ i used the below function since i don't know of any built in functionality it took around .3 of a second on average to complete i also tried using the same algorithm below in vb.net and i can't remember the time, but it was slower than the built in function basically i've found if you can't find the functionallity built into vb.net and have to write it yourself it will slower, i didn't want the hassle of writing things in assembly in c++ either just so i could get more efficiency than vb.net int binarySearchRecursive(string* a, string* value, int left, int right) { int mid; if(right < left) return -1; mid = (int)floor((float)(left + right) / 2); if (_stricmp(value->c_str(), a[mid].c_str())<0) return binarySearchRecursive(a, value, mid + 1, right); else if(_stricmp(value->c_str(), a[mid].c_str())>0) return binarySearchRecursive(a, value, left, mid - 1); else return mid; }
sorry when i said the algorithm written in vb.net was slower than the built in one i meant it was slower than c++
-
There are still a number of environments where C/C++ projects in Windows are the only means available. Those I know of include: - Windows services - Explorer extensions - Device drivers - Any of the 'extension agents' that require a DLL with a fixed signature: SNMP, HTTP, etc.
Software Zen:
delete this;Windows services can be written using .NET, so you can take those off the list!
'Howard
-
i've just started a project and the question of efficiency arose, and i automatically thought c++ out of curiosity though i wrote two test programs one in c++ the other in vb.net using an array of 500,000 strings and 40,000 search words on my system Athlon XP 64 3000+ in vb.net i used the binarysearch function it took around .22 of a second on average to complete in c++ i used the below function since i don't know of any built in functionality it took around .3 of a second on average to complete i also tried using the same algorithm below in vb.net and i can't remember the time, but it was slower than the built in function basically i've found if you can't find the functionallity built into vb.net and have to write it yourself it will slower, i didn't want the hassle of writing things in assembly in c++ either just so i could get more efficiency than vb.net int binarySearchRecursive(string* a, string* value, int left, int right) { int mid; if(right < left) return -1; mid = (int)floor((float)(left + right) / 2); if (_stricmp(value->c_str(), a[mid].c_str())<0) return binarySearchRecursive(a, value, mid + 1, right); else if(_stricmp(value->c_str(), a[mid].c_str())>0) return binarySearchRecursive(a, value, left, mid - 1); else return mid; }
hi Do you have an sample main ? I want to optimize this function. just for fun ... I would like to speed up this code. Long life to C/C++ Fred
-
Hi, I am puzzled? I come from a .NET background but am currently engaged with VC++ (COM/ATL) at my current organization. Now, I am ina dillema. Should I go fill flegded with VC++ or keep uptodate with .NET too. Will VC++(COM/ATL) stay for some more years or will it be eradicated by .NET? What about MFC?
--- :beer: Hakuna-Matada :beer: It means no worries for the rest of your days... It's our problem free, Philosophy :jig: It’s rather simple to write an unmanaged C++ application that crashes when it performs a callback. It’s impossible to write a managed application that does the same, thanks to delegates. - Jeff Prosise
Hey I think that the C++ will surely exist for couple of years in future as a kind of native language to do some low level development where the run-time efficiency is more important than developing efficiency. But MFC might not be pretty a perfect thing, and I don't think that it is one of the best GUI developing helper amoung varieous kinds of programming language. Cheers one to two, two to three, three to everything
-
i've just started a project and the question of efficiency arose, and i automatically thought c++ out of curiosity though i wrote two test programs one in c++ the other in vb.net using an array of 500,000 strings and 40,000 search words on my system Athlon XP 64 3000+ in vb.net i used the binarysearch function it took around .22 of a second on average to complete in c++ i used the below function since i don't know of any built in functionality it took around .3 of a second on average to complete i also tried using the same algorithm below in vb.net and i can't remember the time, but it was slower than the built in function basically i've found if you can't find the functionallity built into vb.net and have to write it yourself it will slower, i didn't want the hassle of writing things in assembly in c++ either just so i could get more efficiency than vb.net int binarySearchRecursive(string* a, string* value, int left, int right) { int mid; if(right < left) return -1; mid = (int)floor((float)(left + right) / 2); if (_stricmp(value->c_str(), a[mid].c_str())<0) return binarySearchRecursive(a, value, mid + 1, right); else if(_stricmp(value->c_str(), a[mid].c_str())>0) return binarySearchRecursive(a, value, left, mid - 1); else return mid; }
-
sorry, but your algorithm can be rewritten (without assembly code) to work as twice as fast. that makes your test unrealistic and don't get me wrong, I believe .NET is the future for most applications PeroB
any suggestions you may have would be appreciated i am always interested in better algorithms
-
hi Do you have an sample main ? I want to optimize this function. just for fun ... I would like to speed up this code. Long life to C/C++ Fred
below is what i tested, threw it together the binarysearch function is the only one i thought about trying to optimise, the code is from a .h and .cpp file just copied and pasted would be interested in anything you do could probably change the string compares, but i want them to be case sensitive haven't thought about it too much, didn't like the casting but didn't have time to think about it #include #include #include #include #include #include using namespace std; void run(); void QuickSort(string* a, int lo0, int hi0); void swap(string* a, int i, int j); int binarySearchRecursive(string* a, string* value, int left, int right); int binarySearchLoop(string* a, string value, int left, int right); int _tmain(int argc, _TCHAR* argv[]) { run(); return 0; } #define MAX_NUMBER_OF_WORDS 500000 #define MAX_LENGTH_OF_STRING 20 #define WORDS_TO_SEARCH_FOR 40000 #define MIN_LENGTH_OF_STRING 3 string* strings; void run() { clock_t startTime; clock_t endTime; string characters[] = {"-", "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z", "A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z"}; int i; int j; int lengthOfString; strings=new string[MAX_NUMBER_OF_WORDS-1]; for(i=0;i
-
Gary R. Wheeler wrote:
Windows services
I'm sure they can be done in C#
Christian Graus - C++ MVP
Already have to wait for the PC to start, loading all the services. Do you imagine what it would be like, if each service loads a 25 MB runtime? :omg:
-
any suggestions you may have would be appreciated i am always interested in better algorithms
I considered that 'left' and 'right' are always positive when the function is called. int new_binarySearchLoop(string* a, string value, int left, int right) { int mid; int result; const char *search_value = value.c_str(); while (left <= right) { mid = (left + right) >> 1; result = _stricmp(search_value, a[mid].c_str()); if (result < 0) left = mid + 1; else if(result > 0) right = mid - 1; else return mid; } return -1; }
-
Todd Smith wrote:
- Any application where performance is an issue
Supposedly that's no longer the case. I've seen a number of articles where managed code is faster than the equivalent native code. The rationale is that the just-in-time compiler and loader can perform whole-program and load environment optimizations that yield greater performance than is possible with a 'static' compiler and linker. I'm willing to believe it on a case-by-case basis, but I have my doubts under general circumstances.
Software Zen:
delete this;Gary R. Wheeler wrote:
I've seen a number of articles where managed code is faster than the equivalent native code.
I've had two interviews in the .NET era where the interviewer told me that apps. they had ported to C# from C++ were faster as a result. Ultimately this must be down to a combination of better design and the things you mention. I've also read a case study where an app. ported from C to Eiffel (another language with GC) was 10 times faster as a result. Eiffel however compiles to C, so this is really C vs. C. But the greater abstraction of Eiffel obviously enabled a more efficient implementation than could be obtained in straight C.
Kevin
-
I'm going to go against the flow here. While I think there are many places where .NET is the way to go, I just can't see it replacing C++ for all new apps. Large categories of apps are going to be on C++ for a long long time. And yes, I know of new apps being written in unmanaged C++. I've been looking at some time critical apps. While I'm skeptical about claims of .NET going faster then well written unmanaged C++ using a good optimizing compiler I'll pass on that because it's not my main concern about .NET My main concerns are these: 1. The garbage collector. If you're doing a little database app (retrieve stuff from the database, display it, let the user edit it, put it back in the database) or something like that it's no big deal. If you're doing a time critical app which CANNOT EVER halt to do GC I'm skeptical. I know there's things you can do with the GC to keep some of it's problems in check, but they seem to me to be overly involved compared to just being able to do delete when need be. You don't need to be an expert on heap management to use delete, you do need to know a lot about the garbage collector to keep it from shooting you in the foot sometimes. Yes I know the C++ heap can become fragmented and the GC can relieve that issue, but it's been my experience that fragmentation is hardly ever a problem, and on those RARE occasions when it is there are ways to relieve it without chucking the whole thing and using a garbage collected language. 2. I have to give up control in the memory representation in .NET which often makes it hard to write good code. C++ lets me specify exactly how an object is handled in memory -- whether on the heap or stack, passed by value or reference, const reference, whatever. With C# several times I have found myself fighting the language just to get it to produce something halfway reasonable. 3. Portability is out the window. If you're in a mixed Unix/Linux/Windows shop like I am you're going to have problems in .NET even if you're writing managed C++, whereas if you stick to ANSI unmanaged C++, portability is often very manageable. Until MS can convince other OSes to use .NET this is going to be a serious problem in some environments. 4. It's been my observation that the problems .NET always trumpets as having solved aren't nearly as bad as they make them out to be and the problems it introduces are, in some situations far more serious. I am quite capable of using delete for example but the loss of control is sometimes nasty. Yes there's many
Goriax wrote:
While I think there are many places where .NET is the way to go, I just can't see it replacing C++ for all new apps.
Is anyone claiming this? The OP raised the issue of .NET or VC++. This pretty much presupposes an MS environment. Given that it seems fairly clear that the scope for new C++ apps. will be increasingly delimited. But of course there are still plenty of scenarios in which it is the best solution.
Goriax wrote:
My main concerns are these: 1. The garbage collector.
Why are almost all new languages designed with GC or a similar memory management scheme? It's because the advantages outweigh the disadvantages. Of course there are always scenarios where greater flexibility is required. There are tradeoffs, as always. But I generally prefer having GC to not having it. I've yet to work on a reasonably sized C++ app. that doesn't have non-trivial memory management problems. Also, we need to distinguish between. 1. Not being competent enough to do memory mangement properly. 2. The ordinary human propensity to make mistakes. The rationale for GC is 2, not 1. With unmanaged languages 2 leads to buffer overrun security vulnerabilities and the like. Almost every important distributed application written in C++ seems to suffer from this. Also, GC enables separation of concerns. We can focus more on the business problems we want to solve rather than book-keeping.
Goriax wrote:
3. Portability is out the window. If you're in a mixed Unix/Linux/Windows shop like I am you're going to have problems in .NET
You can always try Mono, provided you're not insistent in having the very latest features of .NET at any time. An alternative is Java, of course. And if you find that too slow, Eiffel is cross-platform and gives equivalent performance to C++.
Goriax wrote:
Yes there's many ways of crashing your app in C++. Happens all the time. But those obvious blunders are also easy to fix, if you know the language.
I think I know the language reasonably well, and they're not easy to fix. And I'd much rather spend time fixing bugs in business logic.
Goriax wrote:
I'm very intrigued by .NET and I agree that anyone in the MS world must be familiar with it.
Yep, that's the main thing.
-
As far as employment opportunities go, 95%+ of the MS C-type applications in the world are written in C++. They will be around for decades to come (eg COBOL programmers are still required). A company which has invested $millions in C++ software development is not going to chuck it all away just because something new has come along. I reckon it's easier to go from C++/MFC to c# than vice versa.
Ian Semmel wrote:
As far as employment opportunities go, 95%+ of the MS C-type applications in the world are written in C++.
That's right. But if you aspire to something more than just boring maintenance programming...
Kevin
-
Ian Semmel wrote:
As far as employment opportunities go, 95%+ of the MS C-type applications in the world are written in C++.
That's right. But if you aspire to something more than just boring maintenance programming...
Kevin
-
I considered that 'left' and 'right' are always positive when the function is called. int new_binarySearchLoop(string* a, string value, int left, int right) { int mid; int result; const char *search_value = value.c_str(); while (left <= right) { mid = (left + right) >> 1; result = _stricmp(search_value, a[mid].c_str()); if (result < 0) left = mid + 1; else if(result > 0) right = mid - 1; else return mid; } return -1; }
moved your changes over to the recursive version and it was even faster binarySearchRecursive doing the stricmp twice was just a stupid mistake on my part, but i assumed that c++ would automatically optimise the divide to a shift and remove the casting, now i know thanks