COLLADA is an open XML 3d file format initially published by Sony for their PS3 development toolchain and eventually supported by the Khronos Group who is also responsible for the OpenGL and OpenVG API (details here: http://en.wikipedia.org/wiki/COLLADA).
I’ve used C++ ever since I started serious programming in 2003 so when I knew that TopCoder was offering Development Competition for C++ the first time, I was excited to join.. too excited perhaps.
It was a big lesson for me on knowing how to follow directions - implement it EXACTLY as stated in the specifications. They were very particular about the access levels changes especially in the public interface. Furthermore, EVERY entity has to be documented. Whew, that was my first time taking part in a SERIOUS development “team'’.
Anyway, I landed second place (which is pretty ok, considering that the reward is $400 for the second place) but the thing is, I lost to the first placer by .87 points over (the perfect was 100). He got 79 while I got 78.13. I admit it was my stubborness of using tabs instead of the require 4 spaces (but.. but… you can always run it through a code beautifier!!) and some missed specs (didn’t read the instructions well enough). But at least, I have the pride of having a better makefile.
But the part that ticked me off the most (or else, I would’ve been content getting second place) was the parts on the winner’s entry that showed that he’s not too familiar with C++
.
Anyway, I’ll stop ranting for the meantime, what’s done is done. I’ll probably give more specifics in the following posts.
While I was writing the footnotes plugin for b2evolution, I discovered a loophole, or rather, ambiguity, in the HTML 4.01 specification which causes a lot, if not all, browsers to behave incorrectly. It has something to do with the <base> tag and how self-referencing anchor/URI fragments are resolved.
What is the base tag? According to the W3’s HTML 4.01 specification here, the base tag “specifies an absolute URI that acts as the base URI for resolving relative URIs.” So if you have index.html in www.yourserver.com and index.html has his:
HTML:
image.jpg would get resolved to www.yahoo.com/image.jpg instead of www.yourserver.com/image.jpg. This is how the “Save webpage” feature of html browsers manipulate relative URIs
Now what about self-referencing anchors/fragments? Well, everyone knows anchors. They’re basically go like. <a name="anchor_a">foo</a> which could be referenced on the same page using <a href="#anchor_a">bar</a>. The text after the crosshatch (#) sign is called the fragment identifier the entire thing is called, logically, a same-document reference. If you specify a URI before the fragment identifier (e.g. <a href="www.something.com/index.html#anchor_a">), instead of the link taking you to the anchor on the same page, it will take you to the anchor of that URI (another page). More information can be found in the RFC 2396.
Now we know that if a fragment doesn’t contain any URI before it, it is meant to refer to the same document. Now the problem: where should those same-document reference point to when the base is changed using the base tag? Should they still point to the document or should they point to the anchor of the document located at the base URI or should they do something else? Keep in mind how same-document references are being used.
Manifests. Now windows programmers have more issues.
Those who lived through the Windows 9x era very well experience the situation known as DLL Hell. For those without background, it’s the situation where different programs overwrite shared libraries, known in Windows as DLLs. For example, Program A needs sound.dll to run, it then proceeds to copy that file to the Windows directory usually upon installation. Then here comes Program B with its own version of sound.dll, sees sound.dll in the Windows Directory and proceeds to overwrite sound.dll which Program A uses. Have a hundred programs overwriting each other’s shared libraries including Window’s own DLLs (DirectX, C runtime libraries) and the end result is different programs (including Windows!) are getting unexpected results from the shared libraries that they use, causing crashes and other odd behavior. Nevertheless, they didn’t prevent this (the use of shared libraries) because it was necessary for other things like servicing (more information about servicing could be found here.
Windows 2000 and XP “fixed” these problems by intoducing Protected DLLs and Side-by-side Assemblies (SxS for short). Protected DLLs are basically DLLs which are protected by the Operating System: modify it and the system will attempt to restore it. SxS assemblies, on the other hand, are more complicated. An article at CodeProject explains almost everything.
Basically, in order to use the “manifested” DLLs, you’ll have to include an xml file either together with your application or compiled as a resource. This may not seem much but the problem is, it’s note entirely automatic. In order to be able to use Common Controls 6 and Windows XP visual styles to a Windows GUI Application, this XML has be included in the manifest (taken from http://msdn2.microsoft.com/en-us/library/ms649781.aspx):
XML:
| <?xml version="1.0" encoding="UTF-8" standalone="yes"?> | |
| <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> | |
| <assemblyIdentity | |
| version="1.0.0.0" | |
| processorArchitecture="X86" | |
| name="YourCompanyName.YourDivision.YourApplication" | |
| type="win32" | |
| /> | |
| <description>Your application description here.</description> | |
| <dependency> | |
| <dependentAssembly> | |
| <assemblyIdentity | |
| type="win32" | |
| name="Microsoft.Windows.Common-Controls" | |
| version="6.0.0.0" | |
| processorArchitecture="X86" | |
| publicKeyToken="6595b64144ccf1df" | |
| language="*" | |
| /> | |
| </dependentAssembly> | |
| </dependency> | |
| </assembly> |
The first assemblyIdentity element was needed to enable Visual Styles in the application while the second one was to use common-controls. The first one is already automated by Visual Studio but the common controls element has to be manually placed either using that method (manually typing the XML) or using the #pragma directive:
C++:
| #if defined(_M_IX86) | |
| #define MANIFEST_PROCESSORARCHITECTURE "x86" | |
| #elif defined(_M_AMD64) | |
| #define MANIFEST_PROCESSORARCHITECTURE "amd64" | |
| #elif defined(_M_IA64) | |
| #define MANIFEST_PROCESSORARCHITECTURE "ia64" | |
| #else | |
| #error Unknown processor architecture. | |
| #endif | |
| #pragma comment(linker, \ | |
| "\"/manifestdependency:type=’Win32′ "\ | |
| "name=’Microsoft.Windows.Common-Controls’ "\ | |
| "version=’6.0.0.0′ "\ | |
| "processorArchitecture=’" MANIFEST_PROCESSORARCHITECTURE "’ "\ | |
| "publicKeyToken=’6595b64144ccf1df’ "\ | |
| "language=’*’\"") |
Anyway, the main point is, why does it have to be this tedious? Can’t we just add references just like how .net applications do?
In the linux world, this doesn’t matter very much since the applications are compiles to the user’s machine so all, if not most, dependencies are resolved using package managers and the like. And unlike Microsoft, there’s no single entity that carries all responsibility of servicing so they don’t have to worry about it much.
For Mac, with what they call “Frameworks”, it gets even easier, just add the Framework to the project (like how you Add References in .Net) and place this in your code:
C++:
| #include <Framework_name/Header_filename.h> |
Sometimes, I just hate how Microsoft treat C/C++ programmers like 2nd class citizens.