So I thought a primer on OpenGl in C/C++ would be easy based upon tutorials. Turns out not so easy or nice. At least some examples written in older framework/binding stuff (e.g., glaux, glut, and others). While openGl, or Gl and Glu headers provided natively here. Unfortunately examples might be outdated relative to present stuff furnished by Microsoft. Then trying to learn how to link libraries and what not. I have to say C++ std::map containers look more pythonic then ever in terms of implementation which is nice. Easy to remember, compact coding, noticed older implementations in a way old C++ book of mine has a much long winded speak to do the same thing I believe. I was tempted here to go to Boost libraries for C++ for embedding code. Because I love the python dictionary so much was looking to alternately try to create a custom dictionary class, one by overloading key and value typeobjects here (way un pythonic but is the work around to C++ rigid type fixations), and then coverting all data with multi map associations between key to key type values, similarly for value to value type pairs, and then cast converting data all to one type, which provides ostensibly one data type container virtually housing like a dictionary multi type data, just have to re cast convert data back to its original form and overload returns on get functions so that the appropriate return type can be furnished. The other way of handling this, seems to set up mulit type map containers and tracking in the deeper dimensional case scale of data in its given dimensional position. Mostly my consideration of the equivalent dictionary written to C++ were a shallow form, however, and likely since I'm a enough a noob, neither allowing self nesting, until I could figure out something like a string cast conversion of such self (this) class. Dictionaries in python are sort of the nice database utility like all in one (data type) container which I really love a lot...hmm, or then its just retraining one's thinking with respect to data handling which might not be so hard in C++ using the map container. Also the other thing, that I might miss are the python list. Of course, map and vectors in the standard library seem to be a closer equivalent to pythons list, since you hadn't need alloc() or malloc() to assign dynamic memory as in the case of an array whose size is yet to be formally determined?! If you know your data's scaling in C++ already, arrays are easy and not much of a problem, but then it seems (in my rudimentary understanding) if you were say making sql calls to a given database with dynamically assigned memory, then you might easily run into problems with storage for a given return container. Ideally I imagine an interface in C++ already has something like a multi map container setup, and at least in SQL work you could know ahead of time the type assignments for multi map in so far as data container storage. Secondly with the multi map, the container's size could be dynamically assigned in so far as data storage (which is generally the case I believe with most python containers).
Finally figured out the purpose of the pointer here which always boggled my mind in the past. One offered here that pointing to memory avoids having to recopy say object data sent, for example, to a function or inside a class and what not. And when specific data were needed instead when the pointing object call needs reference values in memory, it could do so on an as needed basis. Its seems logical and efficient enough in terms of memory usage. If you were working with heavy data intensive projects, and you were worried about memory usage, seems important. Nowadays though if you were working with small scaled projects, not heavy in data usage, pointers might seem a bit unnecessary in terms of computational efficiency, it seems there's more memory to go around these days then ever, and then generally it seems supposedly python is supposed to be fairly good at cleaning up on no longer used memory. Pointers are generally absent in python lexicon.
As to working with Visual Studio which I haven't done in a long time, and when I did last, it were very very brief, so it should seem enough of a learning curve. Python offers also natively a command line console, I haven't yet figured out a similar tool implementation in C++, although you can run scripts from console with C++ once compiled and built, not sure how to do the compilation and building from console.
In any event, spent the better half of the day, trying to install or work with any number of stuff, like DirectX sdks, here despite my hardware not being an Nvidia based system (more so Intel graphics architecture), I were able to install Nvidia's SDK and run some examples. OpenGl weren't so good in terms of getting working either by tutorial examples seen here, either attempting code examples with 2010 C++ libraries, or 2012 C++ libraries, or even working with supposedly appropriately linked libraries(?) packaged project files, not sure if this were because the project file examples were old enough and outdated relative to present libraries, or probably that I don't know what I am doing here so much. :) OpenCl were yet another fail install, having thought followed all but one pre requisite here, namely the Windows 3.1 installer fails to install. While windows does have a patch (64 bit upgrade) coupled with the redistributable binary installer (32 bit), it seems the installer's installation was a no go, and Intel's package fails on the assertion of a missing .dll, presuming this could be owing to the missing installer version here but I am not so certain. MSDN provides it seems tutorial information for getting started in development, included integrations for application development, there's even in the 2012 Visual studio idea, an object mesh handler for handling 3d objects, would alternately recommend Blender for in depth work and complex mesh object work here. Hmm, anything else, not that I could think of...despite the supposed benefits of OpenGl here, I'd offer unless it can be a chore getting up and running even with supposedly easy tutorials guiding either implementation and installation. OpenGl site itself sort of helps, but then I've been disappointed with the results. Sure game engines like Ogre can possibly run on Linux, but the OpenGL interfaces don't properly render at times object...not sure if this were occurring because of the OpenGl packaging. Sadly I wanted to say you might have better luck diving into WebGl before you were working decently with OpenGl from my experience if you were really new to programming there. Hopefully in Linux OpenGl will improve more so, and hopefully in Windows...well hopefully I'll figure out some basics here.
Ending the ramble...