Secrets Tips and Advanced Programming
BlitzMax Forums/BlitzMax Programming/Secrets Tips and Advanced Programming
| ||
| Hi Blitzers! I've been programming for about 4 years now and I'm always astonished at how many things I learn every day when it comes to programming. Some of the things I've learned and used more recently include Function pointers and referencing function parameters with "var." Please share things you've learned that are very useful to know or considered more advanced programming! Thanks! |
| ||
| I've been programming for 27 years. Where do you want me to start? |
| ||
| One day, I hope to learn to program too :-) |
| ||
| Been doing coding for 32 years now, one thing I learned is comment your code even though it may look obvious now come back to it years later it will look like it was done by a fresh faced newbie. |
| ||
| Yeah, where did i read something like "only myself and God know how this code works. Three months from now, God alone will know"! True, that! |
| ||
| On the topic of cool uses for function pointers, if you make an array of function pointers and load it with various functions, then in a loop call each of the functions in turn as you iterate through the array (by keeping a `program counter` for the index), then you essentially can execute a simple script language with very very minimal `interpretation overhead`. You can also implement the concept of `immediate data` (similar to assembly language here) by storing integer data in the same array as the function pointers. Then each function `eats` a known hardcoded amount of data and increments the program counter before returning. You can store most data types by converting them to integers. I had this up and running very nicely with quite an extensive library of functions and also then began to implement a custom scheduler which could interleave/prioritize calls to the functions from multiple `programs` at once, so that there could be some simple multitasking - of course at a fairly coarse grained level but useful nonetheless. This was of course before BlitzMax got proper threads ;-) But using threads with `function call programs` is also quite useful as a way to batch jobs that need performing ie each thread runs through an array of function pointers to do work. The function pointers can even manage the state of the scheduling system, implement loops/branches, make a program end or suspend or loop around, or put the thread to sleep, etc. Another good use of threading is the thread pool - create lots of threads up-front and then re-use them and put them to sleep as needed. I recommend allocating 2x as many threads as there are cpu cores because often a given thread doesn't get to use 100% of a core. I also found it very useful, if this applies to you, to interleave the memory accesses performed by concurrent threads as they pass over a set of data, because this seemed to do well with the shared cache instead of accessing entirely separate chunks of data. I'm pretty sure I saw a 50% speedup on a dual-core machine this way. |
| ||
| I wish I learn how to code... One thing that has helped me is to code as much as possible far from the computer. I mean, design your algorithms, classes, etc using a regular pen and a notepad before writting a single line of code. that helps getting better quality programs. well... that works for me. |
| ||
| Code is data <-> data is code. Types are functions <-> functions are types <-> types are kinds. Spin the lambda cube and it's the same cube, just from a different perspective. A compiler is (just?) a theorem prover. |
| ||
| Three months from now, God alone will know lol love this sentence |
| ||
| When coding, remember this - It's always a trade-off: memory x speed. You can pre-calculate a lot of stuff, fake effects, etc - consuming tons of memory, or you can save memory doing things 'the hard way'... very, very few cases where you get best results saving both memory *and* processor power. As for time as a programmer... 27 years here :) (Just noticed, just like Gfk! hehehe) |
| ||
| You'll never stop learning, no matter how 'young' we are ;) Good things to learn in BMax are passing by value, callbacks, designing a good object inheritance model ( well, as good as can be in BMax ), and of course cross language programming can sometimes come in handy as a dev - ie c/c++ assembly. Been at it since I was 10! jeez, nearly 40 now and never been payed a penny for programming as its never been my job :D |
| ||
| You can always pollish more, you can always add features, you can always rewrite sections BUT At some point you NEED to say "That's finished". |
| ||
| @ImaginaryHuman, that's fascinating! Is there an example of a simple scripting language using an array of pointers? |
| ||
| I wish I learn how to code... One thing that has helped me is to code as much as possible far from the computer. I mean, design your algorithms, classes, etc using a regular pen and a notepad before writting a single line of code. that helps getting better quality programs. well... that works for me. I had a lecturer about 20 odd years ago tell a story about a COBOL programmer who lived in the Ukraine (I think from memory) who could write flawless programs - the guy had never had access to a computer system. |
| ||
| COBOL is awful programming language as it was nightmare to code them! |
| ||
| Yup done COBOL, Fortran and DBase III at college and let me tell you its an experience I do NOT want to repeat. |
| ||
| How about calling bmax type instances and methods directly from c++ WITHOUT writing any extra C bridging code? I've been playing with a new method of using c++ interfaces in these passed days specifically for COM purposes, and I have it working sweetly. Theres still plenty of work to do but the foundation of calling bmax objects directly from c++ is stable and it also relies on its own reference counting. It works by knowing the BMax object layout in memory and the c++ object layout in memory and injecting a pointer to the BMax object method table into where the c++ object is expecting its one. You can then call those methods directly from c++ as you would normally do with a c++ object method ( pObject->CallMe[ ... ] ), also with passing variables into and out of the methods reliably. It uses the Win32 calling convention to keep the stack in check. Using the C calling convention misaligns the variables of the stack for my purposes, and as COM is *mostly* used on Windows ( even though it could be used with other systems) , I didn't bother looking into why that is or fixing it. Its unlikely the BMax object layout will change nowadays and although there is no standard defined for the layout of c++ objects in memory, it seems most c++ compilers lay out their objects in the same pattern. So by abusing that fact I can reliably call different instances of types and its methods directly from c++ without any of that extra C glue code. So now, I've started fleshing it out into a usable system to see how it scales rather than just leaving it as a proof of concept demo. The whole idea came from allowing c++ code written from outside the BMax environment to access BMax objects by utilizing the COM paradigm. |
| ||
| In programming order is the key of success. This is the most important Issue I would teach as a teacher. Im reorganizing my code again and again until Ill get it Perfect! col You seems like an experienced programmer I wish I knew what you know. I haven't reached the level you described on this post. Im too busy dealing with blitzmax alone |
| ||
| One of the greatest lessons you can learn is to stop working on making an engine and walk away from the graveyard of 100,000 failed engines and just use something off-the shelf that someone else made. It may be a blow to your ego to let go of control and let yourself be helped but it's also a great relief and time saver. |
| ||
| The best tip/secret to advanced programming: stop posting on this forum, get back to coding. The second-best tip: read the documentation. Third-best: use C++11. |
| ||
| +1 on that one but you have to he in the frame of mind to code if you think its a chore dont do it. Nothing is worse than plodding on hating the end result |
| ||
| @N, post 20- Two out of three of those are actively bad advice. 1) coding is an implementation detail. If you spend the majority of your time writing code as opposed to thinking and architecting, you're either doing grunt work (and therefore 99% certain to be reinventing the wheel), or you're plodding ahead on a terrible design. Writing code should not take up more than 10% of your programming time at most. So no, don't get back to coding, get back to doing something useful. 3) C++11 is better than C++03, but at the end of the day it's still C++: an unproductive mess that causes more problems than it solves. Use something high-level if you want productivity. There is simply no good excuse to use C++ in the 21st century. The language is bad and its superior performance is a complete myth. |
| ||
| You should spend less time arguing semantics just to argue semantics. Coding is not just the act of writing code, it's everything involved before it and after it. So, really, your only argument here is against C++11, which is a flimsy one at best. Now, regarding C++ being a mess: yes, it is. It is also one of the few languages with a vast number of useful libraries (including C libraries, as they work fine in C++), unlike all the other languages that various language zealots would like others to adopt. For game development, choosing C++ is not about performance, it's about getting the language features you want with the libraries you want, and those libraries are often not available for use with (or are gimped because of) the myriad of other languages that purport to be safe, fast (never as fast, but it's almost always within what you need), and usually some other mix of things. |
| ||
| C libraries are available for every non-research language. That's a genuine pro feature of C++, but one that it shares with every other language anyway to exactly the same extent (C++ does not have source-level compatibility with nontrivial C code, so you're importing binaries either way), so it's hardly an actual advantage. The whole point about features over performance is precisely why one should avoid C++. Its features are ill-designed and don't provide anything even remotely approximating safety or convenience: what they do provide is code cruft, endless sources of new bugs, and a lot of extra work for the compiler. My argument is short because it's all been said before... see YosefK's excellent FQA for a hundreds-of-pages-long polemic against basically every single design decision in the language. I don't mean to suggest that there are no situations where C++ is a pragmatic option, but suggesting the use of it is an "advanced secret" that new programmers would improve themselves by learning is... frankly cruel; and the "argument to pragmatism" to always stick with old technology is anyway the kind of thinking that slows down the progress of engineering. |
| ||
| So, name a good alternative to C++11. I'll warm up the laughter machine while I wait. |
| ||
| Depending on what platform is appropriate... C (for lowlevel work) Objective-C 2.0 (for mid-level work) Java (for performance, portability) Cython (for readability) JavaScript (for performance, portability, dynamism) Lisp/Scheme (for performance, extreme brevity, dynamism, concurrency) Scala (for portability, reliability) Erlang (for concurrency) OCaml (for reliability) Haskell (for reliability) ATS (for performance) All of these languages have user bases in the tens of thousands at least, have general-purpose library support, and can be used on all common platforms. All of these provide strictly better linguistic environments than C++ (yes, I count C in that, with a tight domain focus on bit twiddling). All of these languages are demonstrably easier to learn than C++, and depending on your exact priorities, are highly competitive with most of its major features to varying extents. |
| ||
| N is back! \o/ ;) |
| ||
| I'm going to point out, everything after Obj-C 2.0 is mostly useless, and everything after C is terrible for portability. Allow me to run the laughter machine, for you have failed to list good, portable alternatives. If you want to hit as many architectures and operating systems as possible, your choices are C and C++. Considering C++ is safer than C in a vast array of ways, using C in those situations would be a detriment to your code because writing C++ in a C-esque manner is still safer than writing straight C. Edit: Though I do want to thank you for ordering it such that I can say "everything after X" so conveniently. |
| ||
| Well, define those words, and define why precisely each one is worse than C++. For instance, I consider a language adequately portable for most purposes if it runs equally well on Windows/Mac/Desktop Linux/iOS/Android, because I live in an end-user dominated world and we're talking on a game dev forum, so whether half of these run on a mainframe or embedded chip I for the most part neither know nor care. By this definition JavaScript is most definitely portable. C sure ain't if you're using it within its domain, since the point of using it is usually to play with nonstandard details. Similarly I am lost as to how you could consider Java non-portable since that is its entire hat; and given that half of those languages potentially offer backends that run through a C compiler as a final step, they are by definition at least as portable as C anyway. As for usefulness: again, define. You can generate code, the code will be efficient, the library access is as good as C++, and the build process is easy (to generalise across all those suggestions). Most of those languages can do absolutely anything C++ can do - certainly within the user-level application development arena. And since what they can do, they do more safely and with shorter development (objectively measurable by time/LOC), that equates to "better" by what I consider a perfectly reasonable definition. Meanwhile, the suggestion that C++ is safer than C when used like C is baffling. C++ has pitifully few safety features and almost all of them require you to write code in completely different ways. You can't implicitly cast from void*. Woohoo. Other than that...? shared_ptr and unique_ptr hardly count as C-like, while blind reliance on e.g. RAII for everything is likely to trash your memory performance which is the reason you would have been using C. etc. |
   |