- Change use of 'iterator' into 'int'. Very simple, modify 'begin() and 'end()' to reflect 0, and current last element.
- begin() is just '0'. if 'end()' is 0, then the vector is empty.
- Just add these methods to a class that contains the array, and keep a maximum size of the array. *Allocate that size on initialization*.
- It can be static or from a pool. This helps fix the memory fragmentation problems that occur when allocations and frees occur while the app executes in real time.
Tuesday, August 27, 2013
Turning stl::vector<> into an array
General concepts, things to change in the code:
Saturday, August 24, 2013
Big Goal! -Plugin able code-
In short, if you implement some arbitrary functionality, can it be plugged in and removed easily?
Can you put it into a different app (executable) and demo it as a stand-alone?
Can you make a script (like Python) and run it to test it?
In large software projects I'm involved with (including games) we usually write the code to work as a big piece, get it running, so that the boss can sell it.
If we are lucky, the project does not end, and we can perfect it later. We can take pieces out and make them plug-in-able, with the goal already stated above.
Good plan?
With my project right now, implemented already, (but I'm removing the STL vector<>, see post: http://easybestcodetricks.blogspot.com/2013/08/c-code-and-stdvector-stl-remarks.html
I could extract it, and demo it maybe on a cell phone or in a nice web app.
The project specifically allows the user to draw (by mouse or touch) points whose distance is rather arbitrary, the points can become connected with lines to create a closed figure, they are ordered, have highlights, randomly or in groups, which can be deleted by the user, and when deleted the figure is re-opened (lines removed) and the user is back into editing mode, creating new points by moving the cursor or finger, again.
How's that for a description?
Can you put it into a different app (executable) and demo it as a stand-alone?
Can you make a script (like Python) and run it to test it?
In large software projects I'm involved with (including games) we usually write the code to work as a big piece, get it running, so that the boss can sell it.
If we are lucky, the project does not end, and we can perfect it later. We can take pieces out and make them plug-in-able, with the goal already stated above.
Good plan?
With my project right now, implemented already, (but I'm removing the STL vector<>, see post: http://easybestcodetricks.blogspot.com/2013/08/c-code-and-stdvector-stl-remarks.html
I could extract it, and demo it maybe on a cell phone or in a nice web app.
The project specifically allows the user to draw (by mouse or touch) points whose distance is rather arbitrary, the points can become connected with lines to create a closed figure, they are ordered, have highlights, randomly or in groups, which can be deleted by the user, and when deleted the figure is re-opened (lines removed) and the user is back into editing mode, creating new points by moving the cursor or finger, again.
How's that for a description?
C++ Code? and std::vector<> STL remarks.
SUMMARY: Better to write logical, simple run-time code that works well, than to include a ton of compile-time logic of which you know very little about what happens when the app is actually running, running for a long time, with unpredictable user (and other) input, in real time. Real-time is chaotic, and you can control the bugs easier this way.
I write my production SW in C++.
If code is well written, it can EASILY be converted ('ported') to a different language, and that's my goal. Best targets these days that I am aware of would be Python, Objective-C because Apple uses it, Java, or JavaScript.
One of my projects which is actually a lot of fun, is to REMOVE STL std::vector<> from code, and replace it with simple, easy to maintain and BUG FREE classes.
Why? It seems that with many days of debugging, headaches, very infrequent but persistent crash bugs, and memory usage problems, I conclude that the complexity of the STL code itself is a problem. It is a source of unending difficulties with young programmers. After reading the goals of the Python language, I've seen the light, and understand more. (also, I am stupid).
Run time efficiency, and simplicity, is very important. Using templates to provide much logic, might be elegant, cool, and might work well, but bugs do happen when people try to upgrade, change, modify, use pre-existing code.
So that code should be simple, obvious, transparent, not hidden in complex structures that are hard to find, follow, and trace. C++ templates, used in excess (more than a little) are kind of an exercise for geniuses, not so much for ordinary mortals. You're better off writing good run-time code classes rather than elegant compile time templates.
Done with my pulpit? Not yet. Remember Vista? Do you know where that project originated?
Vista was a programming project using some 'Loki' which was a template C++ library project (of Andrei Alexandrescu and maybe Herb Sutter) who wrote the book "Modern C++ Design" about the library.
Why was Vista such a problem? I'm not sure if they've discussed it in depth publicly, but we can make assumptions. It used too much memory because templates make it hard to manage memory effectively. It had many bugs due to excessive complexity, and programmers had to program around those bugs rather than strictly simplify their code.
Perhaps you should use BOOST, you will learn a lot, but will you produce easily maintainable, efficient, great working run-time real-time code? Maybe, but you could just write good classes and implement the patterns that you need with as much simplicity as possible, and you will control EVERYTHING.
Small discussion: http://stackoverflow.com/questions/2348112/why-is-the-loki-library-not-more-widely-used
This would be a great research project!
I write my production SW in C++.
If code is well written, it can EASILY be converted ('ported') to a different language, and that's my goal. Best targets these days that I am aware of would be Python, Objective-C because Apple uses it, Java, or JavaScript.
One of my projects which is actually a lot of fun, is to REMOVE STL std::vector<> from code, and replace it with simple, easy to maintain and BUG FREE classes.
Why? It seems that with many days of debugging, headaches, very infrequent but persistent crash bugs, and memory usage problems, I conclude that the complexity of the STL code itself is a problem. It is a source of unending difficulties with young programmers. After reading the goals of the Python language, I've seen the light, and understand more. (also, I am stupid).
Run time efficiency, and simplicity, is very important. Using templates to provide much logic, might be elegant, cool, and might work well, but bugs do happen when people try to upgrade, change, modify, use pre-existing code.
So that code should be simple, obvious, transparent, not hidden in complex structures that are hard to find, follow, and trace. C++ templates, used in excess (more than a little) are kind of an exercise for geniuses, not so much for ordinary mortals. You're better off writing good run-time code classes rather than elegant compile time templates.
Done with my pulpit? Not yet. Remember Vista? Do you know where that project originated?
Vista was a programming project using some 'Loki' which was a template C++ library project (of Andrei Alexandrescu and maybe Herb Sutter) who wrote the book "Modern C++ Design" about the library.
Why was Vista such a problem? I'm not sure if they've discussed it in depth publicly, but we can make assumptions. It used too much memory because templates make it hard to manage memory effectively. It had many bugs due to excessive complexity, and programmers had to program around those bugs rather than strictly simplify their code.
Perhaps you should use BOOST, you will learn a lot, but will you produce easily maintainable, efficient, great working run-time real-time code? Maybe, but you could just write good classes and implement the patterns that you need with as much simplicity as possible, and you will control EVERYTHING.
Small discussion: http://stackoverflow.com/questions/2348112/why-is-the-loki-library-not-more-widely-used
This would be a great research project!
First Projects: static memory buffers on initialization, removing STL vector<> from code.
The need for static memory buffers allocated on initialization, I learned by necessity, coding games for Mac Classic, and Power Macintosh computers. I've since re-implemented (in 2012) for medical devices.
REQUIREMENT:
On the old Mac OS, if your application ran out of memory, you were out of luck, it crashed. This was Motorola processor days before Apple switched to their OSX and Intel system. Those old MACs gave you a fixed size memory buffer which you had to declare when your app was installed, and if there was not enough, the app did not run. You had to figure out by hand how much to ask for and hope it was available after any other apps were loaded and running on a user's computer.
On any system, if your app runs out of memory while running in real time, it can slow down while the memory manager is working to provide memory pages, or while the app is swapping around data to allocate more and more.
SOLUTION:
When your app initializes, allocate all the memory you might need right away, and from then on, minimize system allocations while running in real time.
IMPLEMENTATION:
Static heap allocations of fixed size, code checks that allocations fit in this static heap while running, and if not, it can re-allocate a larger heap (not desirable). Code to be provided.
WHY:
As always, if YOU control the code, you can make it work. If you rely on the OS, there is more in the 'black box' of uncertainty.
REQUIREMENT:
On the old Mac OS, if your application ran out of memory, you were out of luck, it crashed. This was Motorola processor days before Apple switched to their OSX and Intel system. Those old MACs gave you a fixed size memory buffer which you had to declare when your app was installed, and if there was not enough, the app did not run. You had to figure out by hand how much to ask for and hope it was available after any other apps were loaded and running on a user's computer.
On any system, if your app runs out of memory while running in real time, it can slow down while the memory manager is working to provide memory pages, or while the app is swapping around data to allocate more and more.
SOLUTION:
When your app initializes, allocate all the memory you might need right away, and from then on, minimize system allocations while running in real time.
IMPLEMENTATION:
Static heap allocations of fixed size, code checks that allocations fit in this static heap while running, and if not, it can re-allocate a larger heap (not desirable). Code to be provided.
WHY:
As always, if YOU control the code, you can make it work. If you rely on the OS, there is more in the 'black box' of uncertainty.
Subscribe to:
Posts (Atom)