What counts towards demo scene size restrictions? [closed] - c++

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
So I wanna make a small (64k) demo--nothing super impressive, just for the coding experience. I've been wondering, what exactly counts towards a byte count? For example, I could embed Lua as a scripting language once I have a simple demo engine running, but since python comes on pretty much every *nix computer, can I use its interpreter at no cost?
Some might argue that it's not in the spirit of the demo scene, but I do think it counts as milking every last byte. Plus, Lua is 50k and I don't want to write a smaller, custom interpreter (which will be buggy).

The general spirit of the thing is that, as a piece of art, any random person ought to be able to download and view your demo. So it's the base default install of the platform that you're concerned with. This is why most of the best demos target Windows; DirectX is universally available, and the ability to use those libraries dramatically reduces the amount of code in the demo executable.
The same is true of OSX, but other Linux/UNIX variants are really problematic, because there's often no such thing as a standard install. And good luck as far as drivers for hardware-accelerated 3D go.
That said, it's really up to the individual group or competition that you plan to submit your demo to. You'd be best off contacting one of the members or organizers to see what their rules are. If you're just doing this for yourself, to post on the web, then you get to decide what seems fair. The more restrictions you place on yourself, the more impressive the demo ends up being.
If you're really serious about a 64k demo, though, you'll use assembly, not an interpreted language. You only benefit from something like Python if you can get short text to expand into a very complicated function in the stdlib. Most of the places where that matters for a demo are related to graphics and sound, and Python's stdlib doesn't provide much (nor should it) in either regard.

Related

Writing drivers for Windows [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I recently asked the question if I could limit bandwidth via a C# WinForms applications much like NetLimiter and NetBalancer. I was told that there's two ways to do this. Either via proper QoS or writing something along the lines of an "NDIS Network Filter Driver". Using QoS isn't the way I want to take. So I've looked up some of the stuff required to write drivers and found some interesting points. Points such as a good understanding of C/C++, because the executed code being very prone to BSODs since it could be run in something called "Kernel mode". I also found a GitHub "dump" which looks interesting and tempts me to investigate and look around in.
As you can see I'm no where near advanced enough to delve into this on a professional level. Ignoring that, what would be a good start to start my adventures into writing drivers to monitor - and further down the line manipulate the network to introduce throttling.
Any help, guides or information that might be of help is always appreciated.
PS: I am unsure as to whether this is (as afore mentioned in a comment to my previous question) too broad a question to be answered on Stack Overflow. If so, where would I go to ask this?
Indeed, this would be too broad. Driver writing is a complicated thing which requires a good understanding of how a computer and the OS works. Also, C# (and .NET itself) indeed isn't available in Kernel Mode, so C/C++ is the preferred way. Although theoretically any unmanaged language (like Pascal) could do, I haven't heard of anyone writing drivers in them. Microsoft's own developer resources are also written with C/C++ in mind.
Which brings us to the question of why you want to do it.
If you need it for work and there's a deadline - forget it. Get someone else who already knows this stuff. Or there might be a library out there that fills the need. Any of these options will be cheaper than your time spent learning all this stuff.
If it's for your own curiosity however - go for it! I'd advise by starting to learn C first. Not C++, that's more complicated and for drivers it will be easier with C anyway. But you can pick up C++ later too, it's good stuff. C++ is mostly compatible with C, so you can start with C and then continue with C++.
In parallel, get a good book about OS design. Not because you want to design an OS, but to understand the basic concepts that it is built upon. You should get a good understanding of things such as Kernel Mode/User Mode, virtual memory, interrupts, process scheduling, etc.
Learning a bit of assembly might be useful too (albeit not required).
Finally, when you feel like you've got a good grasp of the above, head over to MSDN and start reading about driver development. There will be long articles and example programs to get you started. Tweak them and play around in a virtual machine until you get what you need.
And also... read this.

Alternatives to C and asm on microcontrollers [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
My background is like this: embedded/C, then C++, then higher level OO languages (Java, Scala, Ruby, Groovy, etc.), and now I am doing a small project involving MSP430 microcontroller. Meanwhile, inspired by that, I am contemplating a number of potential pet embedded system projects (meshes and/or RTLS look appealing). So my question is focused primarily on MSP430 for now, though, as an aside, I'd love to have a broader picture, too, involving other microcontrollers.
I was a bit surprised finding out that, after so many years, I might need to go back to C, with its macros, naming conventions, and all. My brain used to be wired for C, but that was many, many years ago.
So what alternatives are available?
C++ feels much more agreeable to me, and, fortunately, seems doable: http://stonepile.fi/object-oriented-approach-to-embedded-programming-with-c/
So if I am to program C++, I just need to inline a lot, avoid virtual functions when possible, and I should be good, right? (at least, memory-wise; they did not benchmark for performance at the above link).
However, if it's so easy, why do people program C? I must be missing something.
The above link also seems to provide a wrapper library for pico]OS. Has anyone used picoOS on MSP430, how reliable is it, and how much resources does it take?
What are the pros and cons of Energia for a simple MS430 project? I tried it, it seems very intuitive and self-documenting, but does it result in as neat a code under the hood? For instance, does Energia initialize unused GPIO to the off state to save energy? Does it initialize unused interrupts? What is the overhead in terms of memory and speed? Etc.
Edit: As a long-time Eclipse person, I'd love to use CCS. I saw that Energia sketches can be imported to CCS. Does it mean that CCS have full support for Energia and can be used as an Energia IDE?
Has anyone used Java Grinder http://hackaday.com/2014/02/10/java-grinder-spits-out-dspic-and-msp430-assembly-code/ ? It seems appealing, but because it spits out an Assembly and not C/C++ code, it's a bit scary to commit to it: what if I am locked into it and it's not ready for the prime time? If it generated C code, I could have easily dropped it if it did not work.
I mentioned Java and my question was deleted, as it's self-evident that other than grinder-like syntactic sugar (not that I mind syntactic sugar!), Java can't run on MSP430. I guess I'll ask another question re WHERE Java can run. This has already grown too long.
What other languages/environments are out there, that fill the niche between low- and hig-level languages?
you seem to have several questions here so I shall go through in the order you numbered them.
Most micros will indeed run C++ (assuming the manufacturer or an open source project provides a compiler back-end), however you have to be wary of a number of drawbacks. C++ Is less deterministic, as in, it provides a significantly higher level of abstraction, which one likely does not want an a resource constrained embedded system, and by and large it is not needed either as embedded systems are rarely powerful enough to usefully run the enormously complex algorithms that warrant a high level language like C++. It is also likely to cause a wide range of hard to track bugs, given the difficulty of debugging code from an embedded system having bugs which are simple and easy to trace are very much nicer. However very importantly, the C++ standard libraries are enormous, they will use excessive ram and very likely waste much of your limited memory space. Thus, even if you do use C++, you wont be able to use any of the techniques that make it powerful.
Simply, I have not used it, however like any RTOS, it is useful if you want a slightly higher level interface, however for a micro the tiny size of the MSP430 it seems overkill, I cannot imagine you doing anything on there that warrants an ROTS, if you need multitasking it would be better to provide simple cooperative tasking yourself.
Unfortunately I have not used that platform either, however given it is based on wiring, my guess it that it does not provide high levels of hardware specific optimization, if you want that I recommend using it for the bulk of your code but make calls into lower level libraries when needed. Beyond that however, it does provide a lovely, self documenting interface, I strongly encourage you to try it. It will also make your code many times easier port if you switch to another micro later (many systems from many companies provide wiring bindings).
You really answer this yourself here, it could be very powerful but is still very immature, I would avoid it purely because of this lock-in until it becomes more mature, then it is worth re-assessing.
Java works nicely on more powerful ARM chips, that is the only place I have seen it in wide use, and implemented fairly efficiently in a micro (ARM provides hardware assistance specifically for Java). Other than this Java is a poor fit for the micro world, at one point it appeared it might go somewhere but this was largely unrealized, for now C likes are the way to go for smaller micros.
Unfortunately there is not really a huge amount of choice other than C. My best recommendation is using higher level libs like wiring. That gives you slightly nicer interfaces without killing efficiency, otherwise there is little point in using a tiny micro if you need high levels of abstraction.
In summary, C does a fairly good job here, I do not think there has been any motivation or effort to make a good replacement. And frankly I largely feel this way too, C never became a bad language, it is still well suited for small systems for the same reasons as it was before. It provides power, efficiency and predictability.
I hope this helps somewhat, if you have any queries please comment me and I will see what I can do to help.

Should I use a code converter (Python to C++)? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 months ago.
Improve this question
Let me just say right off the bat that i'm not a programmer. I'm just a guy with an idea taking his first steps to make it a reality. I'm no stranger to programming, mind you, but some of the concepts and terminology here are way over my head; so i apologize in advance if this question was answered before (i.e. Convert Python program to C/C++ code?).
I have an idea to create a simple A.I. network to analyze music data sent from a phone via cloud computing (I got a guy for the cloud stuff). It will require a lot of memory and need to be fast for the hard number-crunching. I had planned on doing it in python, but have since learned that might not be such a good idea (Is Python faster and lighter than C++?).
Since python is really the only gun i have in my holster, i was thinking of using a python-to-C++-converter. But nothing comes without a price:
Is this an advantageous way to keep my code fast?
What's the give-and-take for using a converter?
Am i missing anything? I'm still new to this so i'm not even sure what questions to ask.
Thanks in advance.
Generally it's an awful way to write code, and does not guarantee that it will be any faster. Things which are simple and fast in one language can be complex and slow in another. You're better off either learning how to write fast Python code or learning C++ directly than fighting with a translator and figuring out how to make the generated code run acceptably.
If you want C++, use C++. Note, however that PyPy have a bunch of benchmarks showing that they can be much faster than C; and with NumPy, which uses compiled extensions, numerical work becomes much faster and easier.
If you want to programme in something statically compiled, and a bit like Python, there's RPython.
Finally, you can do what NumPy does: use extensions written in C or C++ for most of your heavy computational lifting, where that appears to be appropriate, either because profiling shows a hotspot, or because you need an extension to more easily do something involving python's internals. Note that this will tie your code to a particular implementation.
Similar to what was already stated, C++ may be faster in some areas and slower in others. Python is exactly the same. In the end, any language will be converted into machine code. It is really up to the compiler in the end to make it as efficient as it knows how to do. That said, it is better to pick one language and learn how to write fast and efficient code to do what you want.
No because significant part of the good C++ performance comes from the possibility to choose the better performing architecture. It does not come magically from the same fact "because it is C".
A simple, line by line translation from Python into C++ is unlikely to increase the performance more than just using something like Cython so I think it is more reasonable to use Cython. It can still be much worse than a good developer can do with C++ from scratch. C++ simply provides more control over everything like possibility to define data type of the minimal needed length, fixed size array on stack, turn off array bounds checking in production and the like.

C++ Adobe source libraries impressions? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I just stumbled upon Adobe source libraries, ASL. It is set of templates and functions similar to boost, under MIT license.
Some of the utilities in the library I found quite useful and now I consider using it.
the library seems pretty straightforward, however.
Have you used ASL yourself? if so, what were your impressions? do you recommend it?
does it work well with a range of compilers and platforms e.g. IBM C++, ICC, g++?
have you encountered quirks/unexpected things?
thanks
ASL uses Boost heavily, so it's not such similar to Boost, as (in some cases) a relatively thin wrapper around Boost.
The "big" pieces of ASL are Adam and Eve. Most of the rest appears to be (and if memory serves, really is) little more than support for those.
ASL hasn't been updated in a while, and if I'm not mistaken some of what it provides in wrappers around Boost has now been incorporated into the Boost libraries themselves (most Boost authors have been aware of ASL at least since they featured in Sean Parent's keynote presentation at Boostcon 1).
My own experience with them has been somewhat mixed. At one time, I used a couple of their Boost-wrapper classes a bit, but IIRC, within the next release or two, the bits I cared about were available in Boost without any wrappers (though offhand, I don't remember exactly what those pieces were...)
Adam and Eve are kind of cool for playing around with different UI layouts and such -- but I've never used them for a finished version of a program. At least to me, it appears that they're useful primarily with a relatively complex UI. My impression was that if you find them very useful, your UI probably needs work. If you need Adam and Eve to help understand what's going on, chances are your users can't figure out either.
OTOH, there are probably at least a few cases where a dialog is clear to a user, but the code much less so to a developer. If you do a lot of disabling some controls until values have been entered in other controls, and such, it can make it a lot easier to ensure controls are disabled until all values they depend upon have been entered.
As already noted, thew whole point of ASL is Adam and Eve, the rest are just handy tools.
Adam & Eve work together to describe UI with auto-layout in a cross-platform way.
If this is not what you need, then you should probably not spend much time on ASL.
Eve has the typical collection of vertical/horizontal/other containers for auto-layout.
And scripting with Adam allows you to achieve things difficult (if not impossible) to achieve just with layout containers (things like keeping separate groups of controls the same size, for instance).
True, you implement some of the rules in your C++ code. But it makes sense to store the UI description rules related to UI behavior in the same place where you store the UI to begin with.

What to look for in a candidate with over 8 years of experience in C, C++, Linux Application Development? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I need to interview a candidate with over 8 years of experience in Linux using C/C++.
What would be the best way to judge such a candidate?
Do I need to test his understanding of algorithms?
Do I need to test his programming skills by asking to write a program?
How should I test his understanding of Linux?
It depends entirely on what you want him to do. You haven't said anything about the position that you are hiring for but if, say, you want him to write C# then you need him to prove his adaptibility.
Do you need him to write (or modify or bugfix) algorithms? If not, then it is pointless determining how good at them he is.
On the other hand, in order to understand his abilities, you may be better off talking to him about a domain that he is familiar with. You should certainly get him to describe a recent project that he has been involved in, what his contribution was, what the challenges were, what went well, what lessons he learnt.
"Over 8 years of experience in Linux using C/C++" is a fairly vague requirement without reasons for the time length. What are the specific reasons for that time length? Would you prefer more C/C++ experience if some of it were BSD or Solaris or other Unix? Would you prefer less time or a wider experience with different distributions; would you prefer 5 years experience with Red Hat or 7 years experience spanning Red Hat, Debian, SUSE, Gentoo, and others. What are you trying to get from the person you hire, that relates to the amount of time?
The best way to judge a candidate, any candidate, is on how well he can do the job, not how good the qualifications are. You mentioned Lead Developer, owning a product feature and eventually new features. What sort of feature? A highly responsive and adaptive UI? A UI-free recursive data mining calculation? Offline document scanning/indexing code? Custom device drivers?
Basic understanding of algorithms is important, but that can be tested easily in a phone interview. The ability to map out an algorithm for problem solving, and clearly state the reasons for preferring one over another is much more useful, and harder to test.
Test his programming skills by asking to write a program is a fairly useful BS indicator test; there are quite a few people who are adept at slinging manure who can't actually write a line of code. Another useful test is to give him some code with a defect and ask him what's wrong with it, and how he would fix it.
To test his understanding of Linux, I would look at a basic BS test; fire up a Linux box and ask him to perform some basic tasks, including maybe write and compile "Hello world". This will identify the BS artists. Then I would just go with some stock test, showing that he understands the basics of the Linux design; some file system knowledge, some knowledge of tools, ask about how he would add removable device permissions for a user using SE Linux, how he'd configure access to an application that needs elevated privileges so users without those privileges can use the application.
But ultimately, these are all pretty generic ideas; IMHO, it's much more useful to think in terms of "what do we want the candidate to accomplish", than "how do we test basic skills".
Maybe you should focus on what you need. Can he help you? Has he solved problems similar to yours? What are his expectations, what are yours?
I interview people like this all the time. The answer is that no matter how much experience he has, you must prove to yourself that he is capable of the job.
Joel Spolsky is right, hiring badly is destructive to a team and organization. It should be avoided at all costs.
The more I think about it, the more I begin to think good professional developers must be good communicators - in their code and with people. Think of the old saying - the more you know, the more you realise you don't know.
That's not to say you want somebody who isn't confident: but neither do you want someone that is cocky and unwilling to interact with others.
Recently someone asked about whether they should become a programmer in this posting. No matter how a programmer starts out they will likely learn from many mistakes they've made and as a result have an element of humility about themselves and development in general.
A good programmer continues to learn and keeps a relatively open mind.