|
C compilers have had release/debug, or flags you can set with the same effect (e.g. optimise on/off, inlining, etc) for a very long time.
You are not talking to people in a way that will get answers, particularly after posting in the wrong forum (the HoS is explicitly not for asking questions).
When I have fun like this I usually put lots of debug-to-console (or, if you are not running somewhere you can see that, to file) statements in and play divide-and-conquer to pin down where the problem is.
|
|
|
|
|
He mentioned using C++ Builder 6, which is 10 years old. It may very well be that its runtime libraries or the Platform SDK are simply antiquated.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
hello, thanks for the help but that was five years ago that was the ultimate reason to select C# as main language, I have not any plans to fix that code i dont need it. Now i remember the error message: a popup window with this: external exception and no more, somewhat i located the error message in a simply i/o read but i couldnt do anything because the SAME code worked in other projects and I wasnt able to tell what was wrong i had to drop the project.
now c++ fans how many times where you stucked because an error that have you haunted for weeks- a LOT
since i use c# i never ever had an uncomprehensive stupid error again
and please this is not a question forum i post it here to see if anyone had that kind of error once in their lives to feel that i am not alone
|
|
|
|
|
Vasily Tserekh wrote: now c++ fans how many times where you stucked because an error that have you
haunted for weeks- a LOT
since i use c# i never ever had an uncomprehensive
stupid error again
Sounds like a case of selective perception to me. I would also like to have that version of the .Net framework that never does strange things 
C++ has two faces. It allows low level programming close to the computer's hardware, down to supporting writing assembly directly. On the other side it allows to go to a very high level, not dissimilar from what you do in C#. What makes C++ so scary? It can't be strange behavior, because you will encounter that in some form everywhere. C++ libraries are not perfect and the .Net framework also is not. The scary part must actually be low level programming where you must know what you are doing but also get very fine control over what's going on in return. Don't you know that the nice safe .Net world has a price?
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
a price that you wont notice on core i processors
|
|
|
|
|
*sigh* I knew he would say that...
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
I don't know who this "you" is, but it isn't me.
|
|
|
|
|
In case you didn't realize: the reason Vista was so bad was that it was mostly programmed in C#. The result was a shabby, unstable, and unreliable system that was unusable to thousands of users all over the world.
The reason Windows 7 is a lot more stable is that MS reprogrammed much of the OS in C++.
Also, the error message you got most certainly wasn't related to what programming language you used. If you had done the same in C#, most likely the only difference would have been that you might have been given a hunch of what library or subsystem was at fault. A short question on a user forum like this likely would have provided you with the means of that same info as well, and on top of that with some advice how to fix it.
You had an unlucky experience at a time when you were experimenting with C++, but that doesn't mean that C++ at fault anymore than your car manufacturer is at fault when a meteor hits your car.
|
|
|
|
|
Do you only develop for yourself? Saying that performance is fine on YOUR computer doesn't mean it's good for your users.
Also, no I've never been stuck for weeks on a problem with C++ code... I've been stuck getting libraries to work (opengl, sfml, etc) but I know how to properly debug... In fact if you are hiding behind C# instead of learning to debug with unmanged languages, you are hurting yourself in the long run... Those skills are relevent in all languages and will help you the next time C# throws you a fancy error message that you can't make heads or tales of.
|
|
|
|
|
Stephen Dycus wrote: Those skills are relevent in all languages and will help you the next time C#
throws you a fancy error message that you can't make heads or tales of.
You are so right, but he is not interested in hearing that. When that day comes, he will treat us to yet another rant with the title 'That's why i hate c#'.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
Yes, the .NET framework DOES sometimes malfunction and do strange things. But I have to agree with VT that it's much more common in C++.
"Microsoft -- Adding unnecessary complexity to your work since 1987!"
|
|
|
|
|
How do you arrive at that conclusion? You do realize that comparing a framework with a programming language is quite illogical.
Perhaps you think that the code generated by a C++ compiler is less stable than that generated by a C# compiler? In what way? And why does that problem affect compilers across different releases and manufacturers?
Or you think that the libraries for C++ compilers are less stable than the .Net framework. Maybe, but how does that make C++ inferior? Let's just design a brand new framework for C++ and everything is well.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
1. C# gives better error messages. C++'s error messages are more often cryptic.
2. C# catches more errors at compile time than C++. At this point the error is clearer.
3. C#'s managed code has more context information (which may account for the better error messages.)
4. C#'s run-time checks give you an explicit error, as opposed to C++ where the reported error location (if a location is even given) is far from where the error occurred.
5. C#s code is more stable for reason 4; a C++ error (e.g. exceeding array bounds) may exist for years before it produces a crash or wrong results.
A better framework COULD be designed for C++; my comments were on the existing implementations.
"Microsoft -- Adding unnecessary complexity to your work since 1987!"
|
|
|
|
|
1. C++ really does not have a monopoly on stupid error messages. No matter where they turn up, I look them up in MSDN only twice: For the first and the last time. After that I know what they are about.
2. Really? What kind of errors are these? I can think of many cases where the compiler cannot distinguish between an error and intention and must assume that you know what you are doing. By design that's more the case for C++. You can't have both freedom and safeguards against unintentional mistakes at once, but that's a matter of preferences and not really a flaw.
3. I used to be quite capable to supply those myself quite easily with my own exception classes and error logging. It was not really hard to write an exception class, stuff it into a library and consequently use it.
4. Never had any problems with that. I came from assembly programming and was used to having no automatic checks at runtime. Instead of testing array bounds I usually preferred to ensure that the code to calculate the pointers to the item could not violate the bounds. Often by simple means like an assembly macro. Or by design, like using a byte as index for arrays with 256 items. Simple, safe, costs nothing Another way would be to code in a way that must lead to an exception unless everything is correct. 90% of all errors are avoidable, like forgetting to check for null pointers at the proper locations. If it is ensured that an exception will be raised, then those locations should be found during testing and then eliminated forever. This works very well for me. I have one recent web application that now has been running for 18 months without a single failed job.
5. By my experience thats true for every language and library, it's just the scenarios in which those errors occur that change. My best defense against that (also in managed languages) is to keep the code as simple and straightforward as possible. No design for design's sake. No heaping one framework upon another. And, of course, a layer where no error gets past without being recorded, preferranly with as much information as possible. In a way I have turned every operation of the application into a unit test. A transparent design, a few practices and monitoring your application is all that is needed.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
If you're not putting debug prints into your crashing code, you're not doing it right. XD
I think this is the OP's main problem. He's expecting his compiled exe to tell him what's wrong instead of figuring it out himself. It's really not that hard to log some basic info to a text file... or even to the console. You'll know exactly where the crash happens because debug statement X was never printed. *shrug* Just seems like bad programming IMO. I love C# personally, it's quick and easy for simple tools but it's by no means a replacement for C++.
|
|
|
|
|
Please, please, please stick to C# programming.
It sounds like you're not cut out for C++ development.
|
|
|
|
|
I have never had a problem haunt me for weeks.
Post your code here for review. I'm certain I could fix it in a few minutes.
I can write C# code that would haunt you for weeks.
As far a feeling alone. I'm certain that you are not alone. I work with other engineers who are stuck a Perl. When they try Python or C#, there are too many problems to solve. They will tell you that Perl is easy and doesn't have any problems.
Take an assembly language class. I think it will illuminate just what computers do.
|
|
|
|
|
I am an informatic engineer i do know how computers work, and I have made several programs in asm
|
|
|
|
|
I promise you that you surely don't know what you are talking about. The symptom you are describing is an operating system issue. You are:
step one - missing dlls. C++ Builder will alter the environment variables to account for any dlls you are dependent on.
step two - when your code is in the wild, it needs the dependent dlls. That includes any dlls that you have written and the C++ Builder C/C++ runtime dlls.
step three - if you were using Visual Studio, you would need to install vcredist when running wild.
step four - Java, C#, Python... all have their issue that correspond to this one.
step five - Don't post here and ask for help and then argue with the people who are trying to help you. You come off arrogant and based on your first post, you don't have the right to be that arrogant.
If you hate C++, try C#. If you know C#, stick with C#. Just know that you won't be able to do anything outside the sandbox.
|
|
|
|
|
I have seen a lot of guys here that doesnt have a clue of what they are talking about.
C# its not a sandbox, after passsing an enormous amount of time porting C lines to C#
(ak NEHE lessons to my game engine)
i realized that there are almost anything that c\c++ can do that c# doesnt
you can use pointers(althought not encouraged)
you can system make dll calls,
working with data streams is a wonder, if you havent tryed try it.
The only thing is that you lose control not in doing a task you lose control in how is done.
Just tell me one thing that c/c++ can do that c# dont(please dont tell me inline asm)
|
|
|
|
|
Vasily, by definition, C# is a sandbox. That is what managed code means. You run in a sandbox and don't have access to the process space. Sandbox. Got it?
So, you want one thing? Write me a device driver in C#.
Another? Write me an HTTP server that can handle 100,000+ simultaneous connections. I can do that in C++ using overlapped IO and completion ports. I hear the same arguments from the Java guys. My Grails on Groovy on Java framework can handle 200 simultaneous connections and it doesn't matter because I can throw more hardware at it. Do you have any idea how many machines you will need to replace the 1 C++ machine?
You talk about making system DLL calls. What do you think those DLLs are written in? And, BTW, if you don't have the C/C++ run-times installed, those DLLs will not load either. I gave you the solution to your problem.
I use QT. QT's streams are a wonder as well. And you know what, they are a lot faster too. QT and C# with WPF gives you declarative programming. Guess what, C++ and QT are much faster again. Both are equivalently trivial.
You allude to an idea that I don't have a clue. Go back and read what I wrote about insulting people when you make a bold statement and then try to argue the point. My guess is you are about 15 years old. You are learning to program and you still have holes in your knowledge. Me, I'm 50 years old. I've been doing this since the Apple II days. I've done mainframe. I can do assembly, PASCAL, PL1, C, C++, C#, Perl, Python, JavaScript, Java, HTML, device drivers, DLLs, servers, clients, OpenSSL, mobile devices, and much more. I can do all this stuff on Windows, Windows CE, MacOSx and Linux.
Oh, and BTW, you can't do inline ASM.
M
|
|
|
|
|
I stand corrected. You are older and not 15.
|
|
|
|
|
It is alwayas good a people that have a lot more knowledge and experience than you to shut your mouth.
I was not insulting you i just can see how superior is c++ because you can make device drivers on it in that case, i can argue than asm code is superior to c++ because you can make device drivers and its more flexible. and you will tell me that you are not productive with asm, the same thing i tell you with c++ and C#
c++ is to computer programming like php for web programming, they are OLD, misconceived, with a lot of patches, modified on the run, the syntax is awfull and yet eveyone says is wonderfull because everything is built on that. That is not an argument at least for me
You tell me that c++ code is a lot faster, and I recommend you to read some articles because in a lot of use cases c# is faster.
and BTW
Inline assembly was a technique that enabled C++ programmers to put I386
assembly language directives into the C++ code. It was a horrible hack that
made all kinds of assumptions about the processor (in a portable language?)
and was used quite often when something fast and low-level was needed.
|
|
|
|
|
Why don't you just once speak for yourself? Never mind what your Guru has to say about anything. How many years have you done all those things? On how many different systems? All what you say may apply to you. You may not be productive with something. You may be too lazy to learn and understand the fundamentals before relying on all kinds of mechanisms and gadgets. You may be helpless when those things fail because you don't have a clue what might be going on.
Don't be so arrogant to assume that everybody is like that. Many of us have forgotten more about those things than you have ever known and done those things when you still were a possibility in the gene pool. And you don't have to take our or any Guru's word for it. We can prove it.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
unsigned long value;
_highestFunction = 0;
union VendorUnion
{
unsigned long vendorLong;
unsigned char vendorArray[4];
} vendorTail;
unsigned char temp;
__asm
{
mov eax, 0x00
cpuid
mov value, eax
mov vendorTail.vendorLong, ecx
}
_highestFunction = value;
temp = vendorTail.vendorArray[0];
vendorTail.vendorArray[0] = vendorTail.vendorArray[3];
vendorTail.vendorArray[3] = temp;
temp = vendorTail.vendorArray[2];
vendorTail.vendorArray[2] = vendorTail.vendorArray[1];
vendorTail.vendorArray[1] = temp;
switch (vendorTail.vendorLong)
{
case 'ter!': _vendorID = eAMDK5; break;
case 'cAMD': _vendorID = dAMD; break;
case 'auls': _vendorID = eCentaur; break;
case 'tead': _vendorID = eCyrix; break;
case 'ntel': _vendorID = eIntel; break;
case 'Mx86': _vendorID = eTransmeta; break;
case 'aCPU': _vendorID = eTransmeta; break;
case ' NSC': _vendorID = eNationalSemiconductor; break;
case 'iven': _vendorID = eNexGen; break;
case 'Rise': _vendorID = eRise; break;
case ' SIS': _vendorID = eSiS; break;
case ' UMC': _vendorID = eUMC; break;
case ' VIA': _vendorID = eVIA; break;
}
unsigned long _eax, _ebx, _ecx, _edx;
__asm
{
mov eax, 0x01
cpuid
mov _eax, eax
mov _ebx, ebx
mov _ecx, ecx
mov _edx, edx
}
if (_highestFunction >= 3)
{
__asm
{
mov eax, 0x03
cpuid
}
}
Writing that same code in pure ASM would be a pain but in this case, you can use the higher level language when appropriate but use the assembly to access the hardware. The ASM being platform dependent is irrelevant at this point because that is the point. The only time that C# or Java can outperform C++ is when a loop is being performed and the VM can rearrange the byte codes to predict execution. C++ is statically built so the speed is constant. Other than that, I am aware of no instances of C# or Java being faster than well written C++.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
