Yes. Your "local display system" just happens to be "the display I am near at the moment".
So you:
- run an Xvnc all the time; - have your DISPLAY set to that X server (Xvnc) - connect to that X server from wherever you can run a VNC client (your local display; a thin X client; someone else's X server; that Windows box you are walking past; your PDA?; an internet cafe if you are bold enough with your firewall rules (or just crazy))
I believe it does do what you want. I think this is exactly what VNC was designed for (over in the Olivetti^H^H^H^H^H^H^H^HATT research labs in Cambridge (UK)). (Hi Tweest, if you're reading...hope RealVNC is going well.)
You're "planning ahead" becomes what you do by default.
*All* your apps are launched with their X 'DISPLAY' set to the VNC X server (a single server, not a per-app one). Then, whereever *you* are, you run a VNC client session to your VNC X Server and see your desktop.
Ta-da.
For bonus points, get some of their cool "active badge" technology so that "the system" knows where you are in the building and routes your desktop and phone extension to wherever you have happened to sit yourself down.
ASN.1 can be tricky, I'll agree. (as is, perhaps, writing a set of XML tools. Fortunately, libraries for both exist).
However, it is tagged, and data items are variable length.
Each ASN.1 element is a (tag,length,value) tuple. Structured data types are formed by use of the SEQUENCE (ordered) and SET (unordered) elements, whose value is a collection of other elements. Elements deemed optional may be omitted since the tags determine which elements are present. (By nesting SEQ and SET, you may build arbitrarily complex data elements).
The context of the tag determines both the syntax (integer, real, bytestring, datetime, etc) and meaning (height, age, surname) of the value. In this sense it is very similar to XML, except that by encoding a length for a value, you don't need quote-delimiters for string text and hence don't need to scan string data for escape sequences, just grab the bytes.
You've just invented ASN.1! (abstract syntax notation one, used to define network protocols in the X.400 email world and in some IETF protocols such as SNMP and LDAP, and before a pedant prods me, yes I'm conflating BER/DER with ASN.1 itself. Google for more info, you'll find tutorials).
More seriously, ASN.1 and XML have a lot of similar properties. Machine-independent formats for storing/passing arbitrarily complex items of structured data, using a tagging strategy (rather than pure ordering) to identify items (hence allowing optional terms).
The differences are:
- XML is 'self describing' in that the headers determine which DTD to use (is this actually true? Aren't there namespace issues? Can I receive an out-of-context XML document and find a DTD? What the heck would I do with it if I could?) whereas the 'top level' type of an ASN.1 object is determined by context (oh...I just received an ASN.1 chunk from a remote mail system, I'd better start decoding that as a P1 message format).
- ASN.1 is binary, not text (hence more compact, but not human readable).
I've been thinking for some time that a tool which:
1 - took an XML DTD and produced an equivalent ASN.1 definition (or vice versa, but practically speaking there wouldn't be much demand for that).
2 - Could use these complementary definitions to freely convert XML documents to and from ASN.1 PDUs "on the fly".
would be pretty cool. But then I remember that I would be burning CPU to save network bandwidth, and the XML people just turn to gzip when that tradeoff makes sense.
Maybe it would fly as an idea if it was significantly more efficient than gzipping XML (but somehow I doubt that would be sufficient incentive, even if true).
Actually, if you take a reasonable heat source to a comet (say...strap a fission pile to a satellite and make a rendevous), you could then get quite a nice reaction engine going.
Simply vapourise cometary ice and ensure it squirts off in the direction you would like your thrust.
OK, so your impact would be a bit more radioactive than it would have been otherwise, but then again, you might get away with jettisoning the reactor on a different trajectory as the whole shebang was heading down to the moon.
I mean, the comet can land pretty hard, we only need to stop it being an astronmical calamity, not get it down in one piece.
Don't forget, LDIR wasn't the fastest way to sling data around on the Z80, despite it being "easier". I think a simple loop could beat it and I remember reading that one of the later spectrum games used a trick something like:
Change stack ptr to source: pop BC pop DE pop as many as you can get away with change SP to dest: push... push DE push BC loop...
which shifted more bytes/clock than any other method people came up with.
OK. Can someone please tell me the difference between this and:
- adding a 'X-Header: this is not spam' - extending trust to specific IP address/address ranges (if someone from 1.2.3.4 says "its not spam" then I trust them)?
If you are going to say that it uses certificates to establish trust relationships and so it is more secure then you can just go and whistle. You can't reliably spoof an IP address on a TCP connection over the Internet (UDP yes, TCP no. LAN yes, Internet No.)
Spam is a problem because it is convenient for us to be able to receive mail from people we don't know.
If we choose to not receive email from people we don't know, then there are many ways to achieve that now, within the existing protocols. They are even easier for home users to use too.
THIS DOESN'T NEED A NEW PROTOCOL-LEVEL COMMAND.
Phew, sorry, but this comes up on slashdot WAY too often. Please stop it.
Do some searching around (linux-kernel mailing list archives, the bugzilla for linux-kernel) and try to work out whether it has already been reported.
Ensure that you can reproduce the problem on the latest kernel.
If the bug has only just appeared, it is very useful for the developers to know which kernel version it appeared in. The best way to find this out is to do a binary search between the working and non-working kernel versions.
If it has been reported, you might be able to contact the relevant maintainer (check the bug details or the MAINTAINERS file for details) and get a "possible fix" patch to try out.
If it hasn't been reported, I guess the best way to report it is to use the bugzilla. Please read and follow the advice there for how to report a bug, but again common sense applies.
Depending on the bug and your level of interest and ability, it can be really fun to try and work out a fix yourself.
(Sometime you can do this even if you aren't a great coder
e.g. Once I couldn't mount a CD and had a kernel message error about a 2k block size. I knew nothing about the driver, but grepped for the message, found it was bracketed by a "is it 1k or 4k" test. Simply adding 2k as another option to the "if" test and recompiling/rebooting allowed the CD to mount. That ruled.)
If you do produce your own fix, sending it to the relevant maintainer as a suggested change may be helpful, but please don't be upset if your fix isn't used. There are many reasons (some good, some bad) why something which works for someone isn't a good thing in general. (If you do send a patch, use 'diff -u oldfile.c newfile.c' to generate the patch file)).
Top tip was to copy the tape save/load routines from the ROM to the RAM and tweak the timing constants. You could (fairly reliably) get up to 4500 baud that way.
I'd forgotten that about the display. The ZX81 had the CPU generate the display (from an interrupt). There were "SLOW" and "FAST" keywords in the basic language. The FAST keyword spared the CPU the job of updating the display to get more cycles for processing (but of couse you couldn't see anything until you switched back).
Contrariwise, the Spectrum had the ULA read the video memory and do the display. Now, ROM was 0K->16K, RAM was 16K-32K or 16K->64K (in two banks, second bank running from 32K->64K). The display memory was about 6-7K in the lower bank (starting at 16K I think).
So...the lower RAM bank had both the CPU and ULA accessing it, which meant slower access times. So some Kewl Koders used to forgo the use of RAM below 32K to get faster games. I think the (legendary) Manic Miner and its derivatives used this approach.
(Of course, the *right* thing to do would be to keep all code and live data above 32K and page stuff to and from the lower bank at low-performance moments, e.g. to load a level).
Don't get me started on the fastest way to copy memory on a Z-80 processor... (LDIR? no....apparently disabling interrupts, shifting the stack pointer and push/popping was the way to go about it).
Noun. Colloquial, mildly offensive term for "woman", esp. attractive womain. See "trim", "bird", etc.
"moistened"
Adjective. Made wet, or "wetted".
"moistened bint": humourously (sp?) constructed phrase referring to the "Lady of the Lake", a character in Arthurian legend who is the source of the sword Excalibur, used by King Arthur. The sword symbolises Arthur's right of rule and so, in effect, the power of government ultimately resides with the wet woman in question.
Because Outlook is based on MAPI (allowing a certain degree of plug-in behaviour) and has its own plug-in architecture which makes it very extensible, whereas Outlook Express is (was?) much more monolithic.
But all template code requires that the object types implement certain functionality, precisely the functionality which the template uses. If a template doesn't call any methods on an object, it isn't really very useful.
I've made a couple of other replies in the thread, which might be of interest, but the point is that in this case a template feels fine.
In the more general case, you would need to reply on code inspection and/or trial and error compiling to learn the interface you need. (even then it isn't necessarily obvious. Say my template calls a method called "to_string()" on your code, assigning the result to std::string? Should you implement something which returns a string or a const char * (the compiler will be happy if you do either)? Do I do anything odd like call into some legacy routines which implicitly assume that the memory in that std::string has a zero byte after it [hmm...thats where this example probably falls down, since to do that I'd need to call data() rather than c_str() on the string or something, which would be a bug.]
If the implicit interface the writer of the generic code is using is in terms of a const char *, the null byte will be there.
The above example isn't perfect, but it tries to make the point that reverse-engineering an interface from reading template code and compiler error messages might not be as trivial as the original example leads you to think.
It was a templates versus derivation question. I probably didn't describe it well.
Intead of a template test function which takes two args of templates type T (which implicitly must implement == and ), the function could be non-templated and takes two pointers to "Testable".
Testable is a pure abstract base class. In order to use the function with a class, the class must derive from Testable (this imposes the requirement that the functions be defined).
This gives all the same type checking and is equivalent in many ways. Because it is equivalent, you need to make a design choice on which to use. I was asking for help in making that design choice (but I didn't phrase it very well).
Note - the test thing is simply a single example. The general question is: "to implement generic functionality, should you write in terms of templates, or require that the users of your generic code derive from some base interfaces?".
My current position (open to change, please convince me) is that it is a complexity thing. The template approach is suitable for fairly trivial interfaces, but breaks down with a complex interface because the interface is *implicitly* defined in the usage of the class throughout the generic code, rather than explicity in the interface class definition.
You can address the implicit interface with comments (not assertions), but that requires significant discipline on behalf of code maintainers.
[You can't use assertions in the generic code to enforce this, because the generic code (by definition!) doesn't have a full picture of the class with which it might be used.]
Hmm. I outlined a situation, but didn't really state a question/problem very well. Sorry about that.
Its more of a design issue.
Templates "smell funny" because you could end up with arbitrarily complex requirements on the types with which you could use them, requiring code inspection and/or compile/read error/implement new method cycles. That sucks.
Derivation is cleaner, but it clutters the design. Each class which can run in the test framework would need to implement derive from a "Testable" interface. This is probably correct but a bit of a pain, you could end up deriving a bunch of stuff. Maybe this is where the "mixin" approach pays off.
I guess I've answered my question. Use templates only in simple cases (if at all) - derivation if the required (implicit) interface is non-trivial (or if you feel like being purist).
In that respect at least, templates feel more like C macros - you *can* do anything with them, but its a sign that your design is a bit screwed if you go overboard.
[and here's that once again with feeling (and better HTML)]
OK. Could someone please offer some informed comment on the following. (thanks in advance).
If I template a two-argument function in C++ to (e.g.) compare two instances of a class for equality (using the == operator) and print them to an ostream if they fail to match (using the << operator) [why yes, I was writing some unit testing infrastructure, why do you ask?] then:
- my template function will fail to compile if called with two instances of objects which lack the == and << operators.
- this is a broadly equivalent approach to defining a virtual base class (java interface) requiring implementation of these two operators and re-writing the template function to take pointers to the relevant base class. Users would need to derive from my base class to call my function (and hence would have to implement those two operators).
The latter approach (derivation) is more coding for the caller.
The former approach (templating) requires the coder to inspect my entire template function (or read the Fine Docs) to determine the interface s/he needs to implement to use it.
Both approaches are compile-time type safe.
Given that the two approaches are in some sense equivalent, are there good guidelines on when to use derivation instead of templates or vice versa?
PS. The equivalent for the STL would be that the list<type T> template was actually a class which manipulated objects which derive from a "Listable" interface.
OK. Could someone please offer some informed comment on the following. (thanks in advance).
If I template a two-argument function in C++ to (e.g.) compare two instances of a class for equality (using the == operator) and print them to an ostream if they fail to match (using the template was actually a class which manipulated objects which derive from a "Listable" interface.
To answer your question (redundantly, I guess) use nbd. (network block device). Linux-specific solution.
But you don't want to do that (for reasons posted elsewhere in this discussion).
You refer to this as "a raid array". You don't supply more details, which makes me suspect that your raid array isn't well understood. Which means you perhaps have RAID 5 set up, perhaps using IDE RAID and perhaps have multiple disks per IDE channel.
What you need (IDE or SCSI, don't care) is multiple disks set up with a RAID 0 configuration for speed. If you need reliability (and I assume you don't, since you are considering RAM disks) it is best added via RAID 1+0 or 0+1.
This introduces mirroring, either by mirroring your disks in pairs and then raid 0'ing those pairs together or by taking two big RAID0 devices and mirroring them. [Nice thought exercise. Why is 1+0 better than 0+1? Hint: what happens if two random disks fail.]
This will half your storage. But you said you had plenty of storage.
Solution:
Reconfigure to a more appropriate raid config (1+0, 0+1) and ensure you aren't using a really cheesy solution.
(DON'T put multiple disks on the same channel with IDE RAID! Performance will suck as the disks contend for the channel. You may say that you have an IDE raid controller with two channels, max of 4 disks and only by putting two disks on each channel. That is why those controllers suck. They are OK for mirroring. If that is the case, you will be faster overall by using software RAID over 4 disks on your 4 IDE channels (2 from your mobo, 2 from your IDE RAID solution).
Thanks for the off-the-wall idea though. Caused us all to think a bit.
mean, I understand why relatively clueless people use Word for HTML, but why the hell do they try to use it for desktop publishing, for image manipulation, even for freakin' web browsing?
Not just MS users... *cough* emacs *cough*
OK. (So this *could* be taken as a troll, but hey - try and see if in a jovial, festive, spirit:-)
Hmm. Too braindead to do the calculation, but do you get a win if you have a circular track? You can go round that, accelerating away and then either let go (wheeee!) or bank off onto a straightening bit.
Anyone care to do some sums on circumference, centripetel (sp?) force (oooh ooh centrigugal/centripetal flame war please) and other interesting numbers?
You can also get in over LDAP. This can be done nicely from perl with the 'Net::LDAP' module, available under the name 'perl-ldap' from CPAN and with a homepage on sourceforge.
It is a useful interface, the biggest hurdle you are likely to face is authenticating yourself properly to the directory. There may be bits and pieces of example code in the distribution, otherwise do the web search thing and check the mailing list (and archives) for answers.
Slashdot Mirror
Yes. Your "local display system" just happens to be "the display I am near at the moment".
So you:
- run an Xvnc all the time;
- have your DISPLAY set to that X server (Xvnc)
- connect to that X server from wherever you can run a VNC client (your local display; a thin X client; someone else's X server; that Windows box you are walking past; your PDA?; an internet cafe if you are bold enough with your firewall rules (or just crazy))
I believe it does do what you want. I think this is exactly what VNC was designed for (over in the Olivetti^H^H^H^H^H^H^H^HATT research labs in Cambridge (UK)). (Hi Tweest, if you're reading...hope RealVNC is going well.)
You're "planning ahead" becomes what you do by default.
*All* your apps are launched with their X 'DISPLAY' set to the VNC X server (a single server, not a per-app one). Then, whereever *you* are, you run a VNC client session to your VNC X Server and see your desktop.
Ta-da.
For bonus points, get some of their cool "active badge" technology so that "the system" knows where you are in the building and routes your desktop and phone extension to wherever you have happened to sit yourself down.
Sorry, thats not right.
ASN.1 can be tricky, I'll agree. (as is, perhaps, writing a set of XML tools. Fortunately, libraries for both exist).
However, it is tagged, and data items are variable length.
Each ASN.1 element is a (tag,length,value) tuple. Structured data types are formed by use of the SEQUENCE (ordered) and SET (unordered) elements, whose value is a collection of other elements. Elements deemed optional may be omitted since the tags determine which elements are present. (By nesting SEQ and SET, you may build arbitrarily complex data elements).
The context of the tag determines both the syntax (integer, real, bytestring, datetime, etc) and meaning (height, age, surname) of the value. In this sense it is very similar to XML, except that by encoding a length for a value, you don't need quote-delimiters for string text and hence don't need to scan string data for escape sequences, just grab the bytes.
There is a tutorial here if you are interested.
Congratulations!
You've just invented ASN.1! (abstract syntax notation one, used to define network protocols in the X.400 email world and in some IETF protocols such as SNMP and LDAP, and before a pedant prods me, yes I'm conflating BER/DER with ASN.1 itself. Google for more info, you'll find tutorials).
More seriously, ASN.1 and XML have a lot of similar properties. Machine-independent formats for storing/passing arbitrarily complex items of structured data, using a tagging strategy (rather than pure ordering) to identify items (hence allowing optional terms).
The differences are:
- XML is 'self describing' in that the headers determine which DTD to use (is this actually true? Aren't there namespace issues? Can I receive an out-of-context XML document and find a DTD? What the heck would I do with it if I could?) whereas the 'top level' type of an ASN.1 object is determined by context (oh...I just received an ASN.1 chunk from a remote mail system, I'd better start decoding that as a P1 message format).
- ASN.1 is binary, not text (hence more compact, but not human readable).
I've been thinking for some time that a tool which:
1 - took an XML DTD and produced an equivalent ASN.1 definition (or vice versa, but practically speaking there wouldn't be much demand for that).
2 - Could use these complementary definitions to freely convert XML documents to and from ASN.1 PDUs "on the fly".
would be pretty cool. But then I remember that I would be burning CPU to save network bandwidth, and the XML people just turn to gzip when that tradeoff makes sense.
Maybe it would fly as an idea if it was significantly more efficient than gzipping XML (but somehow I doubt that would be sufficient incentive, even if true).
Actually, if you take a reasonable heat source to a comet (say...strap a fission pile to a satellite and make a rendevous), you could then get quite a nice reaction engine going.
Simply vapourise cometary ice and ensure it squirts off in the direction you would like your thrust.
OK, so your impact would be a bit more radioactive than it would have been otherwise, but then again, you might get away with jettisoning the reactor on a different trajectory as the whole shebang was heading down to the moon.
I mean, the comet can land pretty hard, we only need to stop it being an astronmical calamity, not get it down in one piece.
Not far fetched at all I guess.
Don't forget, LDIR wasn't the fastest way to sling data around on the Z80, despite it being "easier". I think a simple loop could beat it and I remember reading that one of the later spectrum games used a trick something like:
...
Change stack ptr to source:
pop BC
pop DE
pop as many as you can get away with
change SP to dest:
push
push DE
push BC
loop...
which shifted more bytes/clock than any other method people came up with.
OK. Can someone please tell me the difference between this and:
- adding a 'X-Header: this is not spam'
- extending trust to specific IP address/address ranges (if someone from 1.2.3.4 says "its not spam" then I trust them)?
If you are going to say that it uses certificates to establish trust relationships and so it is more secure then you can just go and whistle. You can't reliably spoof an IP address on a TCP connection over the Internet (UDP yes, TCP no. LAN yes, Internet No.)
Spam is a problem because it is convenient for us to be able to receive mail from people we don't know.
If we choose to not receive email from people we don't know, then there are many ways to achieve that now, within the existing protocols. They are even easier for home users to use too.
THIS DOESN'T NEED A NEW PROTOCOL-LEVEL COMMAND.
Phew, sorry, but this comes up on slashdot WAY too often. Please stop it.
Do some searching around (linux-kernel mailing list archives, the bugzilla for linux-kernel) and try to work out whether it has already been reported.
Ensure that you can reproduce the problem on the latest kernel.
If the bug has only just appeared, it is very useful for the developers to know which kernel version it appeared in. The best way to find this out is to do a binary search between the working and non-working kernel versions.
If it has been reported, you might be able to contact the relevant maintainer (check the bug details or the MAINTAINERS file for details) and get a "possible fix" patch to try out.
If it hasn't been reported, I guess the best way to report it is to use the bugzilla. Please read and follow the advice there for how to report a bug, but again common sense applies.
Depending on the bug and your level of interest and ability, it can be really fun to try and work out a fix yourself.
(Sometime you can do this even if you aren't a great coder
e.g. Once I couldn't mount a CD and had a kernel message error about a 2k block size. I knew nothing about the driver, but grepped for the message, found it was bracketed by a "is it 1k or 4k" test. Simply adding 2k as another option to the "if" test and recompiling/rebooting allowed the CD to mount. That ruled.)
If you do produce your own fix, sending it to the relevant maintainer as a suggested change may be helpful, but please don't be upset if your fix isn't used. There are many reasons (some good, some bad) why something which works for someone isn't a good thing in general. (If you do send a patch, use 'diff -u oldfile.c newfile.c' to generate the patch file)).
Good luck
Top tip was to copy the tape save/load routines from the ROM to the RAM and tweak the timing constants. You could (fairly reliably) get up to 4500 baud that way.
I'd forgotten that about the display. The ZX81 had the CPU generate the display (from an interrupt). There were "SLOW" and "FAST" keywords in the basic language. The FAST keyword spared the CPU the job of updating the display to get more cycles for processing (but of couse you couldn't see anything until you switched back).
Contrariwise, the Spectrum had the ULA read the video memory and do the display. Now, ROM was 0K->16K, RAM was 16K-32K or 16K->64K (in two banks, second bank running from 32K->64K).
The display memory was about 6-7K in the lower bank (starting at 16K I think).
So...the lower RAM bank had both the CPU and ULA accessing it, which meant slower access times. So some Kewl Koders used to forgo the use of RAM below 32K to get faster games. I think the (legendary) Manic Miner and its derivatives used this approach.
(Of course, the *right* thing to do would be to keep all code and live data above 32K and page stuff to and from the lower bank at low-performance moments, e.g. to load a level).
Don't get me started on the fastest way to copy memory on a Z-80 processor... (LDIR? no....apparently disabling interrupts, shifting the stack pointer and push/popping was the way to go about it).
"bint"
Noun. Colloquial, mildly offensive term for "woman", esp. attractive womain. See "trim", "bird", etc.
"moistened"
Adjective. Made wet, or "wetted".
"moistened bint": humourously (sp?) constructed phrase referring to the "Lady of the Lake", a character in Arthurian legend who is the source of the sword Excalibur, used by King Arthur. The sword symbolises Arthur's right of rule and so, in effect, the power of government ultimately resides with the wet woman in question.
Did this remind anyone else of the onion 'statshot' feature.
Top-ten reasons: Why are we on e-mail blacklists?
1 - Poor social skills cause instant dislike in anyone we communicate with
2 - Cursed by bequest of Nigerian Uncle's Viagra stockpile
3 - Was unaware that neighbours were advertising us as "live nerd-cam!"
4 - this is slashdot?????
5 - profit!
Because Outlook is based on MAPI (allowing a certain degree of plug-in behaviour) and has its own plug-in architecture which makes it very extensible, whereas Outlook Express is (was?) much more monolithic.
Very different programs in all but name.
But all template code requires that the object types implement certain functionality, precisely the functionality which the template uses. If a template doesn't call any methods on an object, it isn't really very useful.
I've made a couple of other replies in the thread, which might be of interest, but the point is that in this case a template feels fine.
In the more general case, you would need to reply on code inspection and/or trial and error compiling to learn the interface you need. (even then it isn't necessarily obvious. Say my template calls a method called "to_string()" on your code, assigning the result to std::string? Should you implement something which returns a string or a const char * (the compiler will be happy if you do either)? Do I do anything odd like call into some legacy routines which implicitly assume that the memory in that std::string has a zero byte after it [hmm...thats where this example probably falls down, since to do that I'd need to call data() rather than c_str() on the string or something, which would be a bug.]
If the implicit interface the writer of the generic code is using is in terms of a const char *, the null byte will be there.
The above example isn't perfect, but it tries to make the point that reverse-engineering an interface from reading template code and compiler error messages might not be as trivial as the original example leads you to think.
It was a templates versus derivation question. I probably didn't describe it well.
Intead of a template test function which takes two args of templates type T (which implicitly must implement == and ), the function could be non-templated and takes two pointers to "Testable".
Testable is a pure abstract base class. In order to use the function with a class, the class must derive from Testable (this imposes the requirement that the functions be defined).
This gives all the same type checking and is equivalent in many ways. Because it is equivalent, you need to make a design choice on which to use. I was asking for help in making that design choice (but I didn't phrase it very well).
Note - the test thing is simply a single example. The general question is: "to implement generic functionality, should you write in terms of templates, or require that the users of your generic code derive from some base interfaces?".
My current position (open to change, please convince me) is that it is a complexity thing. The template approach is suitable for fairly trivial interfaces, but breaks down with a complex interface because the interface is *implicitly* defined in the usage of the class throughout the generic code, rather than explicity in the interface class definition.
You can address the implicit interface with comments (not assertions), but that requires significant discipline on behalf of code maintainers.
[You can't use assertions in the generic code to enforce this, because the generic code (by definition!) doesn't have a full picture of the class with which it might be used.]
Hmm. I outlined a situation, but didn't really state a question/problem very well. Sorry about that.
Its more of a design issue.
Templates "smell funny" because you could end up with arbitrarily complex requirements on the types with which you could use them, requiring code inspection and/or compile/read error/implement new method cycles. That sucks.
Derivation is cleaner, but it clutters the design. Each class which can run in the test framework would need to implement derive from a "Testable" interface. This is probably correct but a bit of a pain, you could end up deriving a bunch of stuff. Maybe this is where the "mixin" approach pays off.
I guess I've answered my question. Use templates only in simple cases (if at all) - derivation if the required (implicit) interface is non-trivial (or if you feel like being purist).
In that respect at least, templates feel more like C macros - you *can* do anything with them, but its a sign that your design is a bit screwed if you go overboard.
[and here's that once again with feeling (and better HTML)]
OK. Could someone please offer some informed comment on the following. (thanks in advance).
If I template a two-argument function in C++ to (e.g.) compare two instances of a class for equality (using the == operator) and print them to an ostream if they fail to match (using the << operator) [why yes, I was writing some unit testing infrastructure, why do you ask?] then:
- my template function will fail to compile if called with two instances of objects which lack the == and << operators.
- this is a broadly equivalent approach to defining a virtual base class (java interface) requiring implementation of these two operators and re-writing the template function to take pointers to the relevant base class. Users would need to derive from my base class to call my function (and hence would have to implement those two operators).
The latter approach (derivation) is more coding for the caller.
The former approach (templating) requires the coder to inspect my entire template function (or read the Fine Docs) to determine the interface s/he needs to implement to use it.
Both approaches are compile-time type safe.
Given that the two approaches are in some sense equivalent, are there good guidelines on when to use derivation instead of templates or vice versa?
PS. The equivalent for the STL would be that the list<type T> template was actually a class which manipulated objects which derive from a "Listable" interface.
OK. Could someone please offer some informed comment on the following. (thanks in advance).
If I template a two-argument function in C++ to (e.g.) compare two instances of a class for equality (using the == operator) and print them to an ostream if they fail to match (using the template was actually a class which manipulated objects which derive from a "Listable" interface.
To answer your question (redundantly, I guess) use nbd. (network block device). Linux-specific solution.
But you don't want to do that (for reasons posted elsewhere in this discussion).
You refer to this as "a raid array". You don't supply more details, which makes me suspect that your raid array isn't well understood. Which means you perhaps have RAID 5 set up, perhaps using IDE RAID and perhaps have multiple disks per IDE channel.
What you need (IDE or SCSI, don't care) is multiple disks set up with a RAID 0 configuration for speed. If you need reliability (and I assume you don't, since you are considering RAM disks) it is best added via RAID 1+0 or 0+1.
This introduces mirroring, either by mirroring your disks in pairs and then raid 0'ing those pairs together or by taking two big RAID0 devices and mirroring them. [Nice thought exercise. Why is 1+0 better than 0+1? Hint: what happens if two random disks fail.]
This will half your storage. But you said you had plenty of storage.
Solution:
Reconfigure to a more appropriate raid config (1+0, 0+1) and ensure you aren't using a really cheesy solution.
(DON'T put multiple disks on the same channel with IDE RAID! Performance will suck as the disks contend for the channel. You may say that you have an IDE raid controller with two channels, max of 4 disks and only by putting two disks on each channel. That is why those controllers suck. They are OK for mirroring. If that is the case, you will be faster overall by using software RAID over 4 disks on your 4 IDE channels (2 from your mobo, 2 from your IDE RAID solution).
Thanks for the off-the-wall idea though. Caused us all to think a bit.
mean, I understand why relatively clueless people use Word for HTML, but why the hell do they try to use it for desktop publishing, for image manipulation, even for freakin' web browsing?
:-)
Not just MS users...
*cough* emacs *cough*
OK. (So this *could* be taken as a troll, but hey - try and see if in a jovial, festive, spirit
s/./,/g?
ITYM s/\./,/g.
HTH. HAND.
Am I doing something stupid, or does Mozilla 1.0 stop rendering a page at the first control-L (page-break) character?
This causes me no end of grief since most/all/many RFCs contain embedded RFC characters - meaning I can't read them (e.g. rfc2060).
Before I create a bugzilla account and report back there, can anyone reading here tell me if I'm missing a config setting/doing something stupid/etc.
ta.
You have just described ASN.1.
People like XML because humans can read it.
It is the same reason people like the inefficient text-based encoding in email.
(That doesn't mean they are right, of course).
Hmm. Too braindead to do the calculation, but do you get a win if you have a circular track? You can go round that, accelerating away and then either let go (wheeee!) or bank off onto a straightening bit.
Anyone care to do some sums on circumference, centripetel (sp?) force (oooh ooh centrigugal/centripetal flame war please) and other interesting numbers?
ADSI edit is one way to twiddle active directory.
You can also get in over LDAP. This can be done nicely from perl with the 'Net::LDAP' module, available under the name 'perl-ldap' from CPAN and with a homepage on sourceforge.
It is a useful interface, the biggest hurdle you are likely to face is authenticating yourself properly to the directory. There may be bits and pieces of example code in the distribution, otherwise do the web search thing and check the mailing list (and archives) for answers.