MAX_PATH is a #define, so it just gets literally substituted when compiling, there is no need for people copying it. After compilation it effectively is a hard-coded constant, indistinguishable from literally writing 260 (it's not 255).
My go-to choice for this has been SVG. For shapes as the ones in the post it's trivial to write by hand and equally trivial to generate various amounts of raster images in various sizes. It's been quite helpful for preparing Android and iOS app icons without constantly having to revise half a dozen different images whenever one changed. It's also easy to change opacity or colour of the shapes/strokes for generating icons for different themes (Holo Dark and Holo Light on Android need different colours, for example).
I used it only as source for the differently-sized raster images. I sort-of inherited an Android and iOS app at that workplace and just went with what was there. But given that the app used OpenGL I'm not sure there even was a possibility of a vector format to use.
why does OpenGL rule out vector formats? there aren't that many great libraries out there for doing it cross platform, but if you treat them as platform dependencies it should be easier...
you can probably google and find loads, but to get you started a little...
the main one I have experience of is 'cairo' which is quite a powerful library for all kinds of drawing things. there is an android build config (although its a bit old now) here: https://github.com/anoek/android-cairo - it is however not great for iOS or OS X...
It doesn't rule it out per se, but just rendering a texture is much easier, with fewer dependencies. Android toolbar icons are PNG, not SVG. Most renderers have trouble with all but the simplest SVGs (filters, etc. can be a pain in the ass – Inkscape renders them nicely to PNG and I just don't have to worry). There's a trade-off everywhere and all my solution did was take input SVGs and render the PNGs in various sizes which we previously had to maintain by hand. If rendering vector graphics would have been a major competitive advantage to the app I'm sure it would have been considered ;-)
The easist way to get rid of adware I tend to use on other's PCs is to just use System Restore. Most adware won't break in there so it just takes a few minutes to be reasonably sure that the system is clean again (at the expense of the last thing they installed, of course).
As for getting a clean slate back, Windows 8 has a Reset function that restores the system to a fresh install state while keeping data intact. Also much easier than hunting for a recovery DVD or an ISO.
You can annotate types within JSDoc, which can help somewhat. But granted, compared to statically typed languages it's still a clusterfuck. Currently writing documentation comment translation for a C#→Java/JS compiler and I'm injecting as much type-system metadata as I can, but IDE and editors still disagree to what extent they're actually using that.
Which is built on the MSBuild API. Which makes it a bit annoying to use without the pre-release Visual Studio right now, as Roslyn is built against an MSBuild assembly that doesn't exist on my machine.
What kind of numbers? Those appearing alone in attributes, such as <rect width='10' height='5'/>? Those appearing in path or polygon data are more complicated, as the syntax allows whitespace, commas, etc. as separators, but they're not needed in some cases. E.g.
is perfectly valid (AFAIR, not sure about the decimal points now), but not really nice to parse or extract.
The main point would be what your use case is? If you just need to transform something, e.g. translate or scale a shape it's easier to put a group around it and apply a transform on that.
Shouldn't programs simply support a @args.txt argument which references a file containing more arguments to the program? Most build tools I've seen do that and it makes command-line length limits mostly a moot point.
When creating a file handle you can usually specify how buffering will work. You can also say that everything should be written immediately. But even then there can be buffering inside the disk and cause you to lose the data. That's not the file system's fault. And sure, get rid of all those caches in between if you don't care about performance. You can do that.
And "write to the file" usually says "write to the file at a point convenient for you". Heck, it's an asynchronous call most of the time anyway so it cannot complete immediately for obvious reasons.
> But even then there can be buffering inside the disk
this, the system accounts for. If you tell the OS to sync data to disk, it has to make sure that the disk committed the data to the durable media.
One aspect of this is: As the disk, as long as it has unwritten cached data in its internal RAM cache, is free to write that data basically in any order, the OS will have to send a write barrier to the disk. Wouldn't this been accounted for by the OS, all filesystems would basically be completely broken on most power outages. Or one would have to flush the disk cache completely on every single and small change, which would severely degrade performance.