XNA is not "Xbox/PC"! XNA is Xbox/Windows. It's not Microsoft trying to be cross-platform; quite the opposite! It's Microsoft trying to be proprietary and lock out Linux, Mac, and the other consoles in one fell swoop.
At Gamefest 2005, they said they'd support all consoles with XNA - if other console manufacturers would let them. So no, it's not them trying to be proprietary.
Why not start doing good things for computing for a change? MS has been the biggest roadblock in software evolution to date and nothing can change that if Microsoft doesnt start to behaive like grownups.
Oooh... I have to ask... just what, precisely,. do you think they've prevented from happening in computing and software evolution? What do you think we'd have right now if they hadn't been around? Flying cars?
While I tend to agree with you, a friend of mine who is a shrink told me that in the very instant a person says 'I'm gonna kill that bastard' or something like it, he/she would actually be capable of performing the act. Of course, for most people it passes rapidly
I'd personally bet money that caffeine (and nicotine, and other stimulants) increase the risk of cancer simply by increasing metabolic activity in cells - activity goes up, cell division goes up, and so the probability of creating rogue cells increases.
I'd actually go further to say that within the next 10 years we'll discover that nearly all forms of cancer are caused by human papilloma viruses and/or retroviruses and bacterial infections which suppress normal anti-oncogene expression (such as gene P53) - and that there will be a major push to find ways to disable these viruses. It has already been found to be the case with cervical cancer; I'm willing to bet money that it'll be found to be the case with all forms of cancer.
When I was 15, I got myself a SAM Coupe home computer (this was the UK, and yes, no-one has ever heard of it).
I'd been programming before then on the BBC Micro, ZX81, Commodore 16 and ZX Spectrum +2... (I was programming a BBC Micro at school when I was 5, and I got my ZX81 when I was 6, and wrote a pacman-like cops & robber's game - the only flaw was that it was impossible to catch the robber - because he moved in lockstep with you). On the Spectrum, I wrote a tile-based game called "amazed in a maze in a mazda", which was a cross between bomberman and minesweeper, as well as a few tape loader tricks that did interesting things like countdowns while the something loaded. On the C16, I wrote a few BASIC games - nothing special.
But when I was 15, I got this computer, and started coding for it... ended up writing all kinds of flashy demos... and wrote a fader routine for and helped debug a port of Prince of Persia.
Since then, I worked on ports of Zub and Bubble Bobble (both never completed, but Zub was mostly done - flawed compression routines killed my source code, and Bubble Bobble was unfortunately stored on tape, so one day the tape glitched and I lost it), port of Lemmings, Exodus (a SmashTV rip off), port of Populous, Parallax (a sideways scrolling shooter). There were all kinds of other bits and pieces and projects, which I finished to various levels of completion.
Because of what I was doing on the SAM Coupe, I got a regular column in Your Sinclair magazine - a games and tech mag in the UK for the Spectrum and SAM home computers (although the SAM only came along at the end).
All of this took a back seat for a while when I went to college, and did a physics degree. I almost dropped my degree and went to go work for High Voltage software in Chicago doing GameGear games, but something stopped me (glad it did too - getting a visa with no degree can be painful in the US).
For a while I worked as a software consultant for a small firm, then got moved to the US working in their newly acquired Mainframe Capacity Planning division. That went south quickly when the parent company went bust, and I went to work for Microsoft on.NET. After that, I ended up at Sierra, working on genealogy, printing and photo editing software.
Sierra died, laying off people (it would be another 2 and a half years before it died entirely), so I ended up working at a small startup in Seattle working on Mass Spectrometers. That also died after 3 years...... and now, I'm at Surreal Software working on Suffering: The Ties That Bind, as a lead engineer in their advanced technology group.
So somehow I went full circle, and ended up back in the games industry. The hours can be long (the past three months were hell - I lived at the office only going home to sleep and eat) - but on the whole, I love the people I work with, the things I'm working on... it's all worth it in the end.
My thoughts exactly. On the other hand, what's with the menu displayed below the tabs? It makes no sense because the menu structure is app-specific, not tab-specific.
actually, the menu structure is tab specific, because IE is an active document container, and as such those menu items can be changed by the contents of the tab.
Except for one minor difference that you failed to note. In the Java Server I'm suggesting, the security settings are built into the shipped copy. There's NO CONFIGURATION to do! With IIS, you have to explicitly set the system permissions. That's always a good idea, but how many admins fail to take this basic precaution?... unless you're running Windows Server 2003, of course, in which case it's the default.
No, you wouldn't. The grandparent stated that there was a flaw in IIS where the URL was decoded a second time and used without security checking. That broke IIS's security. Java's Security Manager sits outside the program's security and checks on EVERY file access in the system. In an OS setting, the server could come pre-packaged with Security Manager rules saying that files outside directory WEBAPPS cannot be accessed. If such a bug exists in this mythical application, IT WOULD BE IMPOSSIBLE TO EXPLOIT!... and setting security on the file system so that INETSRV_ANONYMOUS (or whatever the IIS account is) only had access to places it's meant to fixes the problem, without the need for a security manager. If you were talking about anything other than filesystem protection, you might possibly have a case - but in this case you don't.
This is where Java's security model would have gotten in the way. When the file open request was received, it would have said "You don't have access to these directories, go away!" and it would have failed to open/run the file. Of course, that takes a token security system to implement, but Java is particularly well suited to this, as are many other managed code environments.:-)
If you're running IIS as the internet account instead of as local system, then you can get the same effect just by correctly administrating your system, and locking the internet account out of the parts of your filesystem it's not supposed to have access to.
Java's security model doesn't help you at all here.
I get the usual "the file is in use" error when I try it on NTFS (XP).
That's because of 2 things:
1. You need to have Admin rights to perform a "replace file on reboot" operation. 2. You can't delete/replace file on reboot from Explorer. You have to do it from code. You know, the kind of code that people like Installshield write.
Seriously - I just don't get the benefits to the registry. It's hidden, arcane, and prone to failure.
It also makes you require installers and such, that are totally avoided on other OSs - and can be on Windows.
Programs that use config files are great - you can just copy the program folder to a new PC and run the exe. That's it, all your settings migrate etc...
The files are much more user editable - anyone who can use a text editor can easily change settings in an ini file, and it's easy to backup in case you really screw up. The registry requires a "special" program, and regedit isn't exactly the nicest editor I've ever used. It's somewhat more difficult to back up, and finding thigs seems like a real adventure for me. And storing things in the registry makes you also need transfer programs and uninstallers - as opposed to simply copy + paste or delete the folder.
Plenty of complex programs work fine with config files - see the proxomitron, Opera, and I believe FireFox. Why oh why can't we get rid of it already?
Benefits of the registry: 1. Applications can find their config information without needing to know the install path of the application. 2. Config information can be easily secured, down to the individual key/value pair if necessary. 3. Easy monitoring of changes to registry values as they are updated - again, down to the key/value pair. 4. The registry splits config information into per-user and per-machine info, without it being necessary to figure out where the user's home directory is. 5. It's used by COM to allow you to figure out which objects are installed on the system, without needing to know their name, install path, or any other information. All you need is their IID. 6. It has a certain amount of type-safety built in. (Config files don't). 7. It's more efficient to use than config files; you don't need to read the entire file in and parse its values every time anything in it changes - you just mess with the values you need to mess with. 8. There is a standardized API to access it. 9. Can be used to store binary config data as well as text.... and a minor side benefit: 10. Not designed for users to mess with, so they can't enter invalid data into it (unless they're really determined). Which means you can add verification and other UI logic to the parameters before the parameters are stored out. You don't get this with config files.
You've already mentioned a lot of the disadvantages (lack of config migration support being the biggy), so I'll leave it at that.
I think they are referring to the fact that I had to reboot Windows today to install freakin' ZipGenius...a fucking archive program.
Never heard of it. Which maybe... just maybe... means that it might not necessarily be written by anybody who has any clue what they're doing. Which would explain the pointless reboots.
Just a hunch there, skippy. You don't need to reboot to install a simple archiver application, if you write your installer correctly.
On OSX, I force quit something, and it's gone in a half second. On Linux, I kill -9 something, it's gone in the next screen refresh. On Windows, I ctrl-alt-delete, end process, wait, repeat, repeat, repeat, repeat, wait, click "yes, really kill it", repeat, wait, wait as progress bar fills in, repeat, and it's gone. Or not. Yeah, obviously this is NOT Windows' fault!
You're not doing an End Process. You're doing an End Task. End Task tries to shut down the app in an orderly fashion. End Process shuts it down immediately regardless. Go to the processes tab instead of the applications tab to kill the process.
Transparency . . . Icons that preview the docs . . . sounds like KDE circa 2002. Really impressive, MS.
Transparency's been in Windows since Windows 98 - and more robustly since Windows 2000 (which came out in 1999).
Was it used for much?
Not really. It's used for much more stuff in XP. But it's only recently that video cards have become powerful enough across the board that they can do this kind of thing without massively impacting performance.
There is no heavy lifting in Unix
cat filexyz >/dev/eth0 That's the part that's hard in Windows, getting Windows not to try and treat the input as data and wrap a "valid" header around the packet. As for 2 lines of C depends if you count all the #include's and main() and....
In other words, no, that's not C code. That's shell script. We're talking about programming, not kiddy toys.
Windows programmers write their code with the intent to hurriedly slap together something that sorta kinda works under most sets of circumstances, but has plenty enough eye candy to wow the typical customer who only is smart enough to see GUI-skin deep. Often the software is deliberately written to just to "grease a squeaky wheel" for solving a short term need, and the only long-range planning ever done is to see how many times you can get the customer to repeatedly re-purchase the whole nine yards every 18 months. Also, Windows programmers have a penchant for writing code that only they can understand... to help bolster their own job security since their position will be outsourced in a heartbeat if the company can get away with it. Everything in the Windows world seems centered around a cultural core of pure temporariness. Both the code and the programmer are 100% disposeable. And come to think of it, all too often so is the employer (any typical ISV company) themselves. Windows software companies come and go like thunderstorms in Oklahoma.
Wow. Talk about an overgeneralization with a stupidly broad brush.
If any of my guys wrote code for job security, I'd ask them to rewrite it. If they persisted, I'd fire them. End of story.
I'll give you a great example. A program to send an arbitrary packet (that is manual control of headers and data) out the network card either TCP or UDP. 2 lines in Unix hundreds of lines in Windows.
2 lines of what?
If you can do that in 2 lines of C in Unix, I'll be impressed.
Note: You're not allowed to shell out and spawn another app to do the heavy lifting - or I could do the same thing. In Windows.
Apparently you have no experience with the UNIX way.
What you don't seem to know is that MS Windows is utterly missing the wonderful collection of little tools available on every UNIX platform (Well, without installing cygwin -- but that's UNIX, right?). Each little tool does one little job, and does it well, and all of the tools can be connected in standard ways. So, I *can* use C++ or C or PERL or Python, but I don't *have* to -- many times all I need is sh and that wonderful collection of utilities...
Writing a shell script is not programming. Just FYI.
Actually you only have to fetch one word (4 bytes) in SMTP to get the four-character command and the three-plus-one-character response code. This makes the switch code for the DFA easy. ... except you still have to read the email addresses etc. that go along with that. So sure, you can read the 4CC in, but what about the rest?
Which does the job? Assuming you're using a good OO language where you can simply change an identifier in a place or two and switch from one to the other, there's better things to do then pull up the O() notation for each operation you'll perform and calculating the number of searches relative to number of insertions relative to deletions to determine whether a balanced tree with fast searches and slow insertions is "better" than a slow search but fast insertion/deletion list. Or maybe you want a B* tree? Well, you'll figure it out someday, but right now the rest of the program isn't writing itself.
Or maybe you just learn which does what, and choose the right design from the get-go, and modify your assumptions only as part of an optimization pass?
BTW: I don't know of any OO languages where you can willy-nilly swap out identifiers to switch from one to the other; there's always gotchas with the design where you can't.
Makes me wonder why nobody made a (length prefixed unicode) lib, with the same api semantics that could convert ascii and allocate/free easily.
Actually, ATL comes pretty close to this with its CString class, if you combine it with the Cx2x (CW2T, CW2A, etc) classes. It's also nice and lightweight... which is a plus.
You should optimize a system (be it a program, a network protocol, or any combination thereof) only after it is working perfectly. I do not think that, for example, SMTP is perfect -- it will have to go through more improvements before we can say "SMTP is done."
First rule of optimization: DON'T!
There's a difference between blind optimization, and choosing the correct algorithm or data structure for the job.
For example, you wouldn't choose not to use a tree structure because that's more optimized than a list, would you?
In a conversation about programming mistakes, that would seem to be a potentially huge one. Just trust the sender that the TCP packet you just recieved really is 8T, or perhaps 1 byte? The marginal benefits in terms of memory access would seem to be heavily outweighed by the potential for buffer overflows, memory wasting, etc
An option available as part of the HTTP 1.1 spec is for servers to send documents wrapped in gzip. This suffers the same potential problems you're discussing. So do GIF files, JPEG files, etc. The problems are similar no matter what you do - except in the case of ASCII you're trading fixed buffer lengths for minimal decoding penalty.
Slashdot Mirror
XNA is not "Xbox/PC"! XNA is Xbox/Windows. It's not Microsoft trying to be cross-platform; quite the opposite! It's Microsoft trying to be proprietary and lock out Linux, Mac, and the other consoles in one fell swoop.
At Gamefest 2005, they said they'd support all consoles with XNA - if other console manufacturers would let them. So no, it's not them trying to be proprietary.
Why not start doing good things for computing for a change? MS has been the biggest roadblock in software evolution to date and nothing can change that if Microsoft doesnt start to behaive like grownups.
Oooh... I have to ask... just what, precisely,. do you think they've prevented from happening in computing and software evolution? What do you think we'd have right now if they hadn't been around? Flying cars?
While I tend to agree with you, a friend of mine who is a shrink told me that in the very instant a person says 'I'm gonna kill that bastard' or something like it, he/she would actually be capable of performing the act. Of course, for most people it passes rapidly
Your friend is wrong.
I'd personally bet money that caffeine (and nicotine, and other stimulants) increase the risk of cancer simply by increasing metabolic activity in cells - activity goes up, cell division goes up, and so the probability of creating rogue cells increases.
I'd actually go further to say that within the next 10 years we'll discover that nearly all forms of cancer are caused by human papilloma viruses and/or retroviruses and bacterial infections which suppress normal anti-oncogene expression (such as gene P53) - and that there will be a major push to find ways to disable these viruses. It has already been found to be the case with cervical cancer; I'm willing to bet money that it'll be found to be the case with all forms of cancer.
But that's just a hunch.
When I was 15, I got myself a SAM Coupe home computer (this was the UK, and yes, no-one has ever heard of it).
.NET. After that, I ended up at Sierra, working on genealogy, printing and photo editing software.
... and now, I'm at Surreal Software working on Suffering: The Ties That Bind, as a lead engineer in their advanced technology group.
;-)
I'd been programming before then on the BBC Micro, ZX81, Commodore 16 and ZX Spectrum +2... (I was programming a BBC Micro at school when I was 5, and I got my ZX81 when I was 6, and wrote a pacman-like cops & robber's game - the only flaw was that it was impossible to catch the robber - because he moved in lockstep with you). On the Spectrum, I wrote a tile-based game called "amazed in a maze in a mazda", which was a cross between bomberman and minesweeper, as well as a few tape loader tricks that did interesting things like countdowns while the something loaded. On the C16, I wrote a few BASIC games - nothing special.
But when I was 15, I got this computer, and started coding for it... ended up writing all kinds of flashy demos... and wrote a fader routine for and helped debug a port of Prince of Persia.
Since then, I worked on ports of Zub and Bubble Bobble (both never completed, but Zub was mostly done - flawed compression routines killed my source code, and Bubble Bobble was unfortunately stored on tape, so one day the tape glitched and I lost it), port of Lemmings, Exodus (a SmashTV rip off), port of Populous, Parallax (a sideways scrolling shooter). There were all kinds of other bits and pieces and projects, which I finished to various levels of completion.
Because of what I was doing on the SAM Coupe, I got a regular column in Your Sinclair magazine - a games and tech mag in the UK for the Spectrum and SAM home computers (although the SAM only came along at the end).
All of this took a back seat for a while when I went to college, and did a physics degree. I almost dropped my degree and went to go work for High Voltage software in Chicago doing GameGear games, but something stopped me (glad it did too - getting a visa with no degree can be painful in the US).
For a while I worked as a software consultant for a small firm, then got moved to the US working in their newly acquired Mainframe Capacity Planning division. That went south quickly when the parent company went bust, and I went to work for Microsoft on
Sierra died, laying off people (it would be another 2 and a half years before it died entirely), so I ended up working at a small startup in Seattle working on Mass Spectrometers. That also died after 3 years...
So somehow I went full circle, and ended up back in the games industry. The hours can be long (the past three months were hell - I lived at the office only going home to sleep and eat) - but on the whole, I love the people I work with, the things I'm working on... it's all worth it in the end.
Roll on Next Gen.
My thoughts exactly. On the other hand, what's with the menu displayed below the tabs? It makes no sense because the menu structure is app-specific, not tab-specific.
actually, the menu structure is tab specific, because IE is an active document container, and as such those menu items can be changed by the contents of the tab.
Placement still sucks ass though.
Except for one minor difference that you failed to note. In the Java Server I'm suggesting, the security settings are built into the shipped copy. There's NO CONFIGURATION to do! With IIS, you have to explicitly set the system permissions. That's always a good idea, but how many admins fail to take this basic precaution? ... unless you're running Windows Server 2003, of course, in which case it's the default.
No, you wouldn't. The grandparent stated that there was a flaw in IIS where the URL was decoded a second time and used without security checking. That broke IIS's security. Java's Security Manager sits outside the program's security and checks on EVERY file access in the system. In an OS setting, the server could come pre-packaged with Security Manager rules saying that files outside directory WEBAPPS cannot be accessed. If such a bug exists in this mythical application, IT WOULD BE IMPOSSIBLE TO EXPLOIT! ... and setting security on the file system so that INETSRV_ANONYMOUS (or whatever the IIS account is) only had access to places it's meant to fixes the problem, without the need for a security manager. If you were talking about anything other than filesystem protection, you might possibly have a case - but in this case you don't.
This is where Java's security model would have gotten in the way. When the file open request was received, it would have said "You don't have access to these directories, go away!" and it would have failed to open/run the file. Of course, that takes a token security system to implement, but Java is particularly well suited to this, as are many other managed code environments. :-)
If you're running IIS as the internet account instead of as local system, then you can get the same effect just by correctly administrating your system, and locking the internet account out of the parts of your filesystem it's not supposed to have access to.
Java's security model doesn't help you at all here.
I get the usual "the file is in use" error when I try it on NTFS (XP).
That's because of 2 things:
1. You need to have Admin rights to perform a "replace file on reboot" operation.
2. You can't delete/replace file on reboot from Explorer. You have to do it from code. You know, the kind of code that people like Installshield write.
Seriously - I just don't get the benefits to the registry. It's hidden, arcane, and prone to failure.
... and a minor side benefit:
It also makes you require installers and such, that are totally avoided on other OSs - and can be on Windows.
Programs that use config files are great - you can just copy the program folder to a new PC and run the exe. That's it, all your settings migrate etc...
The files are much more user editable - anyone who can use a text editor can easily change settings in an ini file, and it's easy to backup in case you really screw up. The registry requires a "special" program, and regedit isn't exactly the nicest editor I've ever used. It's somewhat more difficult to back up, and finding thigs seems like a real adventure for me. And storing things in the registry makes you also need transfer programs and uninstallers - as opposed to simply copy + paste or delete the folder.
Plenty of complex programs work fine with config files - see the proxomitron, Opera, and I believe FireFox. Why oh why can't we get rid of it already?
Benefits of the registry:
1. Applications can find their config information without needing to know the install path of the application.
2. Config information can be easily secured, down to the individual key/value pair if necessary.
3. Easy monitoring of changes to registry values as they are updated - again, down to the key/value pair.
4. The registry splits config information into per-user and per-machine info, without it being necessary to figure out where the user's home directory is.
5. It's used by COM to allow you to figure out which objects are installed on the system, without needing to know their name, install path, or any other information. All you need is their IID.
6. It has a certain amount of type-safety built in. (Config files don't).
7. It's more efficient to use than config files; you don't need to read the entire file in and parse its values every time anything in it changes - you just mess with the values you need to mess with.
8. There is a standardized API to access it.
9. Can be used to store binary config data as well as text.
10. Not designed for users to mess with, so they can't enter invalid data into it (unless they're really determined). Which means you can add verification and other UI logic to the parameters before the parameters are stored out. You don't get this with config files.
You've already mentioned a lot of the disadvantages (lack of config migration support being the biggy), so I'll leave it at that.
I think they are referring to the fact that I had to reboot Windows today to install freakin' ZipGenius...a fucking archive program.
Never heard of it. Which maybe... just maybe... means that it might not necessarily be written by anybody who has any clue what they're doing. Which would explain the pointless reboots.
Just a hunch there, skippy. You don't need to reboot to install a simple archiver application, if you write your installer correctly.
On OSX, I force quit something, and it's gone in a half second. On Linux, I kill -9 something, it's gone in the next screen refresh. On Windows, I ctrl-alt-delete, end process, wait, repeat, repeat, repeat, repeat, wait, click "yes, really kill it", repeat, wait, wait as progress bar fills in, repeat, and it's gone. Or not. Yeah, obviously this is NOT Windows' fault!
You're not doing an End Process. You're doing an End Task. End Task tries to shut down the app in an orderly fashion. End Process shuts it down immediately regardless. Go to the processes tab instead of the applications tab to kill the process.
Transparency . . . Icons that preview the docs . . . sounds like KDE circa 2002. Really impressive, MS.
Transparency's been in Windows since Windows 98 - and more robustly since Windows 2000 (which came out in 1999).
Was it used for much?
Not really. It's used for much more stuff in XP. But it's only recently that video cards have become powerful enough across the board that they can do this kind of thing without massively impacting performance.
I think he was very much on the mark, in every respect
And your experience of windows developers comes from where, exactly? Or are you parroting someone else's tripe?
There is no heavy lifting in Unix ....
cat filexyz >/dev/eth0
That's the part that's hard in Windows, getting Windows not to try and treat the input as data and wrap a "valid" header around the packet. As for 2 lines of C depends if you count all the #include's and main() and
In other words, no, that's not C code. That's shell script. We're talking about programming, not kiddy toys.
Windows does threads far better than it does procs. Unix does threads the same as it does procs. Unix does procs as well as Windows does threads
If that's truly the case, then why is there this whole move to the next-gen threading system under Linux called NPTL?
Article I'm looking at here says that the two benefits are "POSIX compliance and a performance boost".
Windows programmers write their code with the intent to hurriedly slap together something that sorta kinda works under most sets of circumstances, but has plenty enough eye candy to wow the typical customer who only is smart enough to see GUI-skin deep. Often the software is deliberately written to just to "grease a squeaky wheel" for solving a short term need, and the only long-range planning ever done is to see how many times you can get the customer to repeatedly re-purchase the whole nine yards every 18 months. Also, Windows programmers have a penchant for writing code that only they can understand... to help bolster their own job security since their position will be outsourced in a heartbeat if the company can get away with it. Everything in the Windows world seems centered around a cultural core of pure temporariness. Both the code and the programmer are 100% disposeable. And come to think of it, all too often so is the employer (any typical ISV company) themselves. Windows software companies come and go like thunderstorms in Oklahoma.
Wow. Talk about an overgeneralization with a stupidly broad brush.
If any of my guys wrote code for job security, I'd ask them to rewrite it. If they persisted, I'd fire them. End of story.
I'll give you a great example. A program to send an arbitrary packet (that is manual control of headers and data) out the network card either TCP or UDP. 2 lines in Unix hundreds of lines in Windows.
2 lines of what?
If you can do that in 2 lines of C in Unix, I'll be impressed.
Note: You're not allowed to shell out and spawn another app to do the heavy lifting - or I could do the same thing. In Windows.
Apparently you have no experience with the UNIX way.
What you don't seem to know is that MS Windows is utterly missing the wonderful collection of little tools available on every UNIX platform (Well, without installing cygwin -- but that's UNIX, right?). Each little tool does one little job, and does it well, and all of the tools can be connected in standard ways. So, I *can* use C++ or C or PERL or Python, but I don't *have* to -- many times all I need is sh and that wonderful collection of utilities...
Writing a shell script is not programming. Just FYI.
Actually you only have to fetch one word (4 bytes) in SMTP to get the four-character command and the three-plus-one-character response code. This makes the switch code for the DFA easy. ... except you still have to read the email addresses etc. that go along with that. So sure, you can read the 4CC in, but what about the rest?
Which does the job? Assuming you're using a good OO language where you can simply change an identifier in a place or two and switch from one to the other, there's better things to do then pull up the O() notation for each operation you'll perform and calculating the number of searches relative to number of insertions relative to deletions to determine whether a balanced tree with fast searches and slow insertions is "better" than a slow search but fast insertion/deletion list. Or maybe you want a B* tree? Well, you'll figure it out someday, but right now the rest of the program isn't writing itself.
Or maybe you just learn which does what, and choose the right design from the get-go, and modify your assumptions only as part of an optimization pass?
BTW: I don't know of any OO languages where you can willy-nilly swap out identifiers to switch from one to the other; there's always gotchas with the design where you can't.
Makes me wonder why nobody made a (length prefixed unicode) lib, with the same api semantics that could convert ascii and allocate/free easily.
Actually, ATL comes pretty close to this with its CString class, if you combine it with the Cx2x (CW2T, CW2A, etc) classes. It's also nice and lightweight... which is a plus.
You should optimize a system (be it a program, a network protocol, or any combination thereof) only after it is working perfectly. I do not think that, for example, SMTP is perfect -- it will have to go through more improvements before we can say "SMTP is done."
First rule of optimization: DON'T!
There's a difference between blind optimization, and choosing the correct algorithm or data structure for the job.
For example, you wouldn't choose not to use a tree structure because that's more optimized than a list, would you?
Or maybe you would...
In a conversation about programming mistakes, that would seem to be a potentially huge one. Just trust the sender that the TCP packet you just recieved really is 8T, or perhaps 1 byte? The marginal benefits in terms of memory access would seem to be heavily outweighed by the potential for buffer overflows, memory wasting, etc
An option available as part of the HTTP 1.1 spec is for servers to send documents wrapped in gzip. This suffers the same potential problems you're discussing. So do GIF files, JPEG files, etc. The problems are similar no matter what you do - except in the case of ASCII you're trading fixed buffer lengths for minimal decoding penalty.