Search Results

Search found 3 results on 1 pages for 'embeddedprog'.

Page 1/1 | 1 

• Suggestions on error handling of Win32 C++ code: AtlThrow vs. STL exceptions

  - by EmbeddedProg

  In writing Win32 C++ code, I'd appreciate some hints on how to handle errors of Win32 APIs. In particular, in case of a failure of a Win32 function call (e.g. MapViewOfFile), is it better to: use AtlThrowLastWin32 define a Win32Exception class derived from std::exception, with an added HRESULT data member to store the HRESULT corresponding to value returned by GetLastError? In this latter case, I could use the what() method to return a detailed error string (e.g. "MapViewOfFile call failed in MyClass::DoSomething() method."). What are the pros and cons of 1 vs. 2? Is there any other better option that I am missing? As a side note, if I'd like to localize the component I'm developing, how could I localize the exception what() string? I was thinking of building a table mapping the original English string returned by what() into a Unicode localized error string. Could anyone suggest a better approach? Thanks much for your insights and suggestions.

  Read the article

• Quantifying the Performance of Garbage Collection vs. Explicit Memory Management

  - by EmbeddedProg

  I found this article here: Quantifying the Performance of Garbage Collection vs. Explicit Memory Management http://www.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf In the conclusion section, it reads: Comparing runtime, space consumption, and virtual memory footprints over a range of benchmarks, we show that the runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory. In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower. Garbage collection also is more susceptible to paging when physical memory is scarce. In such conditions, all of the garbage collectors we examine here suffer order-of-magnitude performance penalties relative to explicit memory management. So, if my understanding is correct: if I have an app written in native C++ requiring 100 MB of memory, to achieve the same performance with a "managed" (i.e. garbage collector based) language (e.g. Java, C#), the app should require 5*100 MB = 500 MB? (And with 2*100 MB = 200 MB, the managed app would run 70% slower than the native app?) Do you know if current (i.e. latest Java VM's and .NET 4.0's) garbage collectors suffer the same problems described in the aforementioned article? Has the performance of modern garbage collectors improved? Thanks.

  Read the article

• Use the right tool for the job: embedded programming

  - by EmbeddedProg

  I'm interested in programming languages well suited for embedded programming. In particular: Is it possible to program embedded systems in C++? Or is it better to use pure C? Or is C++ OK only if some features of the language (e.g. RTTI, exceptions and templates) are excluded? What about Java in this domain? Thanks.

  Read the article

1