07.26.10
Posted in Programming at 2:04 am by Michael
The traditionally held restrictions of malloc()-allocated objects are “no constructor calls” and “no destructor calls”. However, there is an additional restriction: no virtual functions or polymorphism. If you wish to implement polymorphism on the Arduino and plan to use dynamic memory, you must declare operators new and delete (in terms of malloc() and free()) before you can use polymorphism. Once declared, these operators acquire the “magic” they are known for.
Attempting to call a virtual function on a malloc()-allocated object on the Arduino will not crash in an obvious way. It will merely return a bogus result which appears to come from some random spot in memory (maybe where the function points).
Of course, if you’re developing for a normal platform and not a microcontroller, just use the native new and delete and be done with it.
Permalink
07.21.10
Posted in Ideas, Programming at 10:03 pm by Michael
Images have texture. Sentences have texture too. Use the keyblock approach to dynamically build n-grams. ‘Nuff said.
Permalink
Posted in Ideas at 12:11 am by Michael
It is possible to define a mapping between the bits in a digital key and the shape of a physical key. Further, it is possible to physically etch a digital key onto a physical one below the resolution at which said data could be easily copied. Consequently, it is possible to design an intelligent lock which possesses a public key and which generates a cryptographic challenge, which is then decrypted using the private (physical) key. A key which could physically open the lock but which does not possess the appropriate private key could trigger an alarm.
Certainly digital keys exist, but this key would require no power source. The lock, on the other hand, would require both power and enough logic to implement the PKI approach of choice. Nevertheless, this strikes me as a practical approach for car or office locks.
Permalink