Using SSE on an Intel processor is not always "the fast" an optimization due to the "special cases." For example:
- Does the processor have SSE? - Is the target class guaranteed to fit inside one-page? If you can't guarantee the n-byte class fits cleanly inside a page boundary, then doing a 2^n byte copy could cause a page fault.
- What is the page length anyways? It varies - more special cases.
- What does the C/C++-standard say? Have you considered unions of structs with class wrappers? Just because any "good" programmer wouldn't do it, does not mean that these code sequences aren't used in production. MFC wraps the Windows API in an interesting ways.
- Is the operation likely to be bandwidth limited? Essentially, the main memory is bandwidth limited on a modern Intel processor. As such, when doing copies, the code with the smallest number of main-memory accesses wins. Which piece of code is fastest can be really non-obvious when caching effects and misaligned accesses are considered.
- The "string" MOV assembly instructions are so frequently used in Intel assembly, that the processor is heavily optimized to do them. This gives SSE such a minimal advantage that you need to know that the code your are writing is the special case where the SSE optimization is valid.
- Compiler/programmer debug time factor. Is this optimization so incredibly specific that it depends on classes of exactly the correct sizes? Overly specific optimizations can cause numerous problems. For instance, the optimization may be wrong. The optimization may be correct, but it induces unsuspected bugs (say in code involving specific-sized unions, structs and classes.) The optimization may be indecipherable - other programmers may waste tremendous amounts of time on subtle compiled code changes.
- Finally, is this optimization a better than other potential optimizations? There are lots of possible optimizations.
Historically, Intel would never make a 6800K processor. The hated competition (Motorola) made the 6800, and later the Motorola 68K series. I feel like an old-guy for remembering this stuff.
Bingo. There is almost no point trying to limit excess human use of antibiotics beyond current efforts, when agriculture is using them wildly. In this case, the disease is resistant to antibiotics that are mainly used for agriculture. So the problem is definitely agricultural antibiotics.
You need to cite stuff like this. Not everyone is from England. Someone from half-around the world is unlikely to even know where Rotherham even is, and if they do, they may think you are talking about the nearest Rotherham. There is more than one possibility:
- Rotherham in England (correct)
- Rotherham in New Zealand (nearest to me)
- a misspelling of Rotterdam, Netherlends (my first guess)
This sounds like a major local story, but it wasn't a big international story. Britain has had a number of sex-abuse scandals in recent years. However, you can't expect every slashdot reader to remember all of them. In fact, it would be difficult to have a photographic memory of sex-abuse cases world-wide, and remain sane.
Most brake's can't stop the engine. That's why modern engine's have engine-brake interlocks. Engine power is reduced when the brake pedal is pushed.
I had an old pickup with a stuck gas-pedal. The brakes were completely unable to stop the engine. Luckily, it was in winter, and the truck was on ice. The truck went forward until the front tires hit pavement, and then I had time to experiment. It was a rear-wheel drive vehicle and the rear set of brakes were unable to stop the rear-wheels from spinning.
Lead acid performance is terrible. The average car battery is only good for two or three full discharges. I've even observed heavy duty deep cycle batteries last 2 full discharges in cold weather.
Disclaimer: had boss who placed zero emphasis on circuit testing. Not good idea with batteries.
From your example, the hard drive is over 9,000,000 times slower. It's a big reason why virtual memory doesn't really work right anymore. Any quantity of misses, and a mechanical hard drive will not be able to handle the load. Even an SSD is dead slow in comparison to main RAM.
You have a CPU running at 3 GHz, at 3 BILLION instructions per second. And you have a hard drive with an access time of 3ms (which is... let's say faster than anything I've seen in a HDD). The CPU would have to wait for over 9,000,000 cycles before the HD could even start to answer its request.
Many internet concepts and services leading up to websites were in use in 1986.
The foundational blocks of the web were being built and developed in the 1980's:
- BBS systems offered real-time communication and interchange, but no graphics.
- Mail forwarders, mail auto-responders, UUCP and USENET offered internet connectivity, but were store and forward.
- Apple's HyperCard system was brought to market in 1987. This created a web-page like experience, however everything was centered around data files.
- The networks were available: TCP/IP links between universities existed.
- The hardware was ready: 32-bit workstations with MMUs and graphics were on the market.
In the 1990's, the web quickly developed:
- The web came on-stream in the early 1990s (1990-1992).
- By the mid-90's, 32-bit PCs were ubiquitous, and many computers could be upgraded to use the web.
- By the end of 1995, Bill Gates had his conversion: the head of Microsoft was saying the web was important.
- At the end of the 90's the basic internet architecture of Linux servers and Windows web-clients was in use everywhere.
Civil engineers design with a safety margin such that their building's don't fall down. I work with a bunch of them. Civil engineers dread the thought that their building falls down.
What does this mean in terms of software? Software crashes all the time.
Software systems tend to have really complex side effects. Suppose I design a blood pressure monitoring machine for a hospital. It and a hundred other devices let the hospital run much more efficiently. The hospital only needs 1/2 the number of nurses. Now, someone discovers a bug in security camera, penetrates the network, discovers hundreds of Windows XP Embedded devices, and turns the hospital into a malware farm. (Incidents like this have happened.)
The hospital is screwed. It can't suddenly double the number of nurses, and even if you did, the nurses are used to the automated equipment. They don't know how to fall back to the non-networked way of doing things instantly. They are out of practice.
How could an engineer sign off on a system like this?
On one hand, it is running standard and recommended software (like Windows). Software has went through the FDA approval process. However, on the flip side, the hospital is a sitting duck. These embedded devices are hopelessly insecure, and there is no way to secure them against modern network threats.
I don't think we have proper methods of describing and solving modern safety issues in embedded systems. We have no proper method of understanding safety with machines built in one country, running software written two different countries, and then running somewhere else. The safety interactions even in a relatively stand-alone machine can be very tough to understand. These network enabled threats make things really hard.
It appears that if you want people to do something useful in an unusual situation, then they need to practice. People get things really wrong in unusual situations. Automated systems screw up in unusual systems too. Airplane investigations are littered with examples of automation "helping" pilots and causing disasters. There are examples of pilots relying on automation, which didn't work and caused a disaster. There are examples of pilots getting confused, ignoring training and automation, and crashing functioning planes.
I think the only common thread is that if you want people to do something useful in an emergency situation, they need training and practice.
The user may be doing a save operation because the computer is running out of memory. This means a deep-copy may fail during the save operation. If the computer is simply out-of-memory, then the user will be left without a copy of the most recent document. If you are up against a soft-memory limit (the system is paging to disk madly), then the program will appear to stop while the deep-copy takes place. This can be a long-time. Long enough for the user to give up, end-task the application, and then lose his work.
If the data structure is trivial, then it is safe to make the assumption the computer has lots of memory. However, in this case, the save operation will likely be quick so little advantage is gained from multi-threading. If the data structure is huge, then doubling the memory requirements during saves has significant performance advantages. But it is a no-win situation. The huge-data structure situation is also when the user would benefit from the multi-threading.
Improvements over a Multi-Threaded Deep Copy Save
A better solution than doing a deep copy is to duplicate only the bits of the data structure being modified by the user. Options:
a) Under Unix/Linux, do a fork(). If the fork fails, then serially output the file. If the fork succeeds, then a different process was created with a complete copy of the data structure. Save the file in the second process, and then use any IPC mechanism to communicate success or failure back to the parent process. This is a no-cost solution, because the VM subsystem keeps track of all the duplicate and dirty pages for you.
b) Under Windows. Design a thread-safe main data structure. This is hell. Even in Java, it is hell.
Building thread safe main data structures is hard 1. Performance is lost on every data structure access because the software has to check for the thread lock. This overhead can be worse than not having the data structure at all.
2. With modern processors do delayed writes to main memory, and the delays can reach hundreds of clock-cycles. Suppose a thread-locks are placed around a non-thread safe library/data structure on a large program. How do you protect against a Write after Write bug on a multi-core CPU?
Java's thread-locks may protect your code, but you have no idea what is happening in any non-thread safe third-party libraries. At least in C and C++, the debugger will often debug into those libraries and let you know the errors in your ways. In C# with third-party ActiveX controls, or in Java with low-level libraries, you are screwed.
I'm not saying a multi-threaded save can't work. It is a beautiful thing when done right. It is just a hard thing to do. It works best when the data structures are small, simple, tight and easy to understand.
A related problem is that there is no way for the hiring manager to tell the difference between a very good programmer and a good programmer. All of the first year CS resumes say the candidates are skilled in C, Java, and a few more buzzwords. Every software project has a life-cycle, and the better programmers move between projects. This means all the experienced resumes show people with many projects. This makes it hard to tell the difference between a competent person that makes meaningful contributions then moves on, and a less competent person that is a good talker and drifts.
It's a real problem for the hiring manager. It essentially means that you can't pay more for better programmers. Economists even have terms for this. Product differentiation. If you can't show you are an A+ programmer as opposed to an A programmer or a C programmer, then it becomes difficult to make the case that the A+ programmer is worth four C programmers. It even becomes difficult to tell who the A+ programmers are. This tends to drive out experienced programmers into other careers.
This problem really affects software engineers. I can tell the difference between a skilled electrician and an unskilled electrician in minutes. Great architects win awards. Develop a great piece of real-time engineering on a safety-critical system - no one is ever going to see your work. Sure, you might save lots of lives with your code. But the hiring manager for your next job can't tell the difference.
Microsoft wrote a bunch of code, that in hindsight was a really really bad idea. I'm not really sure that the problems were all Microsoft's fault - they probably didn't invent them. They are Microsoft's fault in that they embedded the concepts into the operating system and then widely popularized them.
The big gotchas all have to do with limitations of C, and the twists used to optimize Microsoft's programming for the 8086 architecture. I'm thinking of:
char string[MAX_PATH]; What can possibly go wrong? Especially before MAX_PATH was invented.
malloc() new() and friends For any non-trivial program, it's almost impossible to get correct. They only really work for something like a C compiler which will allocate a variable amount of memory, do a task, and then end. If you miss a few free() calls along the way - they will be cleaned up when the compiler terminates.
GlobalAlloc(), LocalAlloc() and friends Just in case you couldn't make it work with malloc, try the operating system version of the call. Using OS calls really opened the window to some famous bugs - OpenSSH comes to mind.
Multi-threading in C For any non-trivial problem - it doesn't work. Firstly, for any non-simple piece of code, it is tough to do correctly. Secondly, for a trivial piece of code, like a save operation, you need to somehow make the memory being stored immutable for the duration of the save. For most save operations, this defeats the purpose, as the first thing the user wants to do after save is to change the document. Thirdly, if you really need multi-threading, there is a good chance some of your users need parallel-processing across machines. Multi-threaded code and parallel-processing code are not the same things at all.
Embedding code in data. Firstly, the x86 architecture encouraged this, by not having proper page protections. Secondly, it completely opens the system up to malicious code. ActiveX, JPEG libraries, font libraries, everywhere Microsoft had an API that embedded code in data, it was all exploited.
GM did you a favor. I have a Kia with the Microsoft system. An Apple iPhone can crash the system so hard that it needs a full reboot. You have to stop the car, turn the engine-off and restart to get the phone interface working again. The system doesn't work with Android properly either. I assume Microsoft's system must work well with a Zune or a Lumia phone, however I have never seen one to try it out.:-)
Big difference: The RaspberryPi has TTL I/O. This makes it easy to do any of a wide variety of hardware interfacing. This new board only has UART ports, which means if you want to do an easy hardware project, you need another microcontroller, tool-chain, etc.
There is a definite market for prototype devices that talk Ethernet, WiFi, UART, SPI, I2C and hardware I/O too. The Raspberry Pi does that well, and inexpensively.
The FBI busted Russian sleeper agents using the WiFi across the food-court trick.
As such, I don't think the WiFi across the food-court would help the DNC.
See the story. There are many articles on the cell. Only a few mention the WiFi link. Quite a few debate whether the agents were actually sleeper agents.
The trailers are shot before the film is. If the trailers don't fit the film as shot, its tough to include them.
Now, if the film companies actually waited for the film to be finished before advertising it, then they wouldn't get caught advertising something they couldn't deliver.
(seriously: every so often I see women using a baby carriage as a means to clear a path, pushing it into traffic to make everyone stop so she can cross. What's up with that?)
When you have a baby you turn into a sleep deprived zombie.
Slashdot Mirror
Using SSE on an Intel processor is not always "the fast" an optimization due to the "special cases." For example:
- Does the processor have SSE?
- Is the target class guaranteed to fit inside one-page? If you can't guarantee the n-byte class fits cleanly inside a page boundary, then doing a 2^n byte copy could cause a page fault.
- What is the page length anyways? It varies - more special cases.
- What does the C/C++-standard say? Have you considered unions of structs with class wrappers? Just because any "good" programmer wouldn't do it, does not mean that these code sequences aren't used in production. MFC wraps the Windows API in an interesting ways.
- Is the operation likely to be bandwidth limited? Essentially, the main memory is bandwidth limited on a modern Intel processor. As such, when doing copies, the code with the smallest number of main-memory accesses wins. Which piece of code is fastest can be really non-obvious when caching effects and misaligned accesses are considered.
- The "string" MOV assembly instructions are so frequently used in Intel assembly, that the processor is heavily optimized to do them. This gives SSE such a minimal advantage that you need to know that the code your are writing is the special case where the SSE optimization is valid.
- Compiler/programmer debug time factor. Is this optimization so incredibly specific that it depends on classes of exactly the correct sizes? Overly specific optimizations can cause numerous problems. For instance, the optimization may be wrong. The optimization may be correct, but it induces unsuspected bugs (say in code involving specific-sized unions, structs and classes.) The optimization may be indecipherable - other programmers may waste tremendous amounts of time on subtle compiled code changes.
- Finally, is this optimization a better than other potential optimizations? There are lots of possible optimizations.
Historically, Intel would never make a 6800K processor. The hated competition (Motorola) made the 6800, and later the Motorola 68K series. I feel like an old-guy for remembering this stuff.
Bingo. There is almost no point trying to limit excess human use of antibiotics beyond current efforts, when agriculture is using them wildly. In this case, the disease is resistant to antibiotics that are mainly used for agriculture. So the problem is definitely agricultural antibiotics.
You need to cite stuff like this. Not everyone is from England. Someone from half-around the world is unlikely to even know where Rotherham even is, and if they do, they may think you are talking about the nearest Rotherham. There is more than one possibility:
- Rotherham in England (correct)
- Rotherham in New Zealand (nearest to me)
- a misspelling of Rotterdam, Netherlends (my first guess)
This sounds like a major local story, but it wasn't a big international story. Britain has had a number of sex-abuse scandals in recent years. However, you can't expect every slashdot reader to remember all of them. In fact, it would be difficult to have a photographic memory of sex-abuse cases world-wide, and remain sane.
It doesn't take much to make a regular aircraft into a pilotless drone. All it requires is a parachute. This Mig flew into NATO airspace with no pilot.
Most brake's can't stop the engine. That's why modern engine's have engine-brake interlocks. Engine power is reduced when the brake pedal is pushed.
I had an old pickup with a stuck gas-pedal. The brakes were completely unable to stop the engine. Luckily, it was in winter, and the truck was on ice. The truck went forward until the front tires hit pavement, and then I had time to experiment. It was a rear-wheel drive vehicle and the rear set of brakes were unable to stop the rear-wheels from spinning.
Disclaimer: had boss who placed zero emphasis on circuit testing. Not good idea with batteries.
Many internet concepts and services leading up to websites were in use in 1986.
The foundational blocks of the web were being built and developed in the 1980's:
- BBS systems offered real-time communication and interchange, but no graphics.
- Mail forwarders, mail auto-responders, UUCP and USENET offered internet connectivity, but were store and forward.
- Apple's HyperCard system was brought to market in 1987. This created a web-page like experience, however everything was centered around data files.
- The networks were available: TCP/IP links between universities existed.
- The hardware was ready: 32-bit workstations with MMUs and graphics were on the market.
In the 1990's, the web quickly developed:
- The web came on-stream in the early 1990s (1990-1992).
- By the mid-90's, 32-bit PCs were ubiquitous, and many computers could be upgraded to use the web.
- By the end of 1995, Bill Gates had his conversion: the head of Microsoft was saying the web was important.
- At the end of the 90's the basic internet architecture of Linux servers and Windows web-clients was in use everywhere.
Civil engineers design with a safety margin such that their building's don't fall down. I work with a bunch of them. Civil engineers dread the thought that their building falls down.
What does this mean in terms of software? Software crashes all the time.
Software systems tend to have really complex side effects. Suppose I design a blood pressure monitoring machine for a hospital. It and a hundred other devices let the hospital run much more efficiently. The hospital only needs 1/2 the number of nurses. Now, someone discovers a bug in security camera, penetrates the network, discovers hundreds of Windows XP Embedded devices, and turns the hospital into a malware farm. (Incidents like this have happened.)
The hospital is screwed. It can't suddenly double the number of nurses, and even if you did, the nurses are used to the automated equipment. They don't know how to fall back to the non-networked way of doing things instantly. They are out of practice.
How could an engineer sign off on a system like this?
On one hand, it is running standard and recommended software (like Windows). Software has went through the FDA approval process. However, on the flip side, the hospital is a sitting duck. These embedded devices are hopelessly insecure, and there is no way to secure them against modern network threats.
I don't think we have proper methods of describing and solving modern safety issues in embedded systems. We have no proper method of understanding safety with machines built in one country, running software written two different countries, and then running somewhere else. The safety interactions even in a relatively stand-alone machine can be very tough to understand. These network enabled threats make things really hard.
It appears that if you want people to do something useful in an unusual situation, then they need to practice. People get things really wrong in unusual situations. Automated systems screw up in unusual systems too. Airplane investigations are littered with examples of automation "helping" pilots and causing disasters. There are examples of pilots relying on automation, which didn't work and caused a disaster. There are examples of pilots getting confused, ignoring training and automation, and crashing functioning planes.
I think the only common thread is that if you want people to do something useful in an emergency situation, they need training and practice.
The user may be doing a save operation because the computer is running out of memory. This means a deep-copy may fail during the save operation. If the computer is simply out-of-memory, then the user will be left without a copy of the most recent document. If you are up against a soft-memory limit (the system is paging to disk madly), then the program will appear to stop while the deep-copy takes place. This can be a long-time. Long enough for the user to give up, end-task the application, and then lose his work.
If the data structure is trivial, then it is safe to make the assumption the computer has lots of memory. However, in this case, the save operation will likely be quick so little advantage is gained from multi-threading. If the data structure is huge, then doubling the memory requirements during saves has significant performance advantages. But it is a no-win situation. The huge-data structure situation is also when the user would benefit from the multi-threading.
Improvements over a Multi-Threaded Deep Copy Save
A better solution than doing a deep copy is to duplicate only the bits of the data structure being modified by the user. Options:
a) Under Unix/Linux, do a fork(). If the fork fails, then serially output the file. If the fork succeeds, then a different process was created with a complete copy of the data structure. Save the file in the second process, and then use any IPC mechanism to communicate success or failure back to the parent process. This is a no-cost solution, because the VM subsystem keeps track of all the duplicate and dirty pages for you.
b) Under Windows. Design a thread-safe main data structure. This is hell. Even in Java, it is hell.
Building thread safe main data structures is hard
1. Performance is lost on every data structure access because the software has to check for the thread lock. This overhead can be worse than not having the data structure at all.
2. With modern processors do delayed writes to main memory, and the delays can reach hundreds of clock-cycles. Suppose a thread-locks are placed around a non-thread safe library/data structure on a large program. How do you protect against a Write after Write bug on a multi-core CPU?
Java's thread-locks may protect your code, but you have no idea what is happening in any non-thread safe third-party libraries. At least in C and C++, the debugger will often debug into those libraries and let you know the errors in your ways. In C# with third-party ActiveX controls, or in Java with low-level libraries, you are screwed.
I'm not saying a multi-threaded save can't work. It is a beautiful thing when done right. It is just a hard thing to do. It works best when the data structures are small, simple, tight and easy to understand.
A related problem is that there is no way for the hiring manager to tell the difference between a very good programmer and a good programmer. All of the first year CS resumes say the candidates are skilled in C, Java, and a few more buzzwords. Every software project has a life-cycle, and the better programmers move between projects. This means all the experienced resumes show people with many projects. This makes it hard to tell the difference between a competent person that makes meaningful contributions then moves on, and a less competent person that is a good talker and drifts.
It's a real problem for the hiring manager. It essentially means that you can't pay more for better programmers. Economists even have terms for this. Product differentiation. If you can't show you are an A+ programmer as opposed to an A programmer or a C programmer, then it becomes difficult to make the case that the A+ programmer is worth four C programmers. It even becomes difficult to tell who the A+ programmers are. This tends to drive out experienced programmers into other careers.
This problem really affects software engineers. I can tell the difference between a skilled electrician and an unskilled electrician in minutes. Great architects win awards. Develop a great piece of real-time engineering on a safety-critical system - no one is ever going to see your work. Sure, you might save lots of lives with your code. But the hiring manager for your next job can't tell the difference.
Microsoft wrote a bunch of code, that in hindsight was a really really bad idea. I'm not really sure that the problems were all Microsoft's fault - they probably didn't invent them. They are Microsoft's fault in that they embedded the concepts into the operating system and then widely popularized them.
The big gotchas all have to do with limitations of C, and the twists used to optimize Microsoft's programming for the 8086 architecture. I'm thinking of:
char string[MAX_PATH];
What can possibly go wrong? Especially before MAX_PATH was invented.
malloc() new() and friends
For any non-trivial program, it's almost impossible to get correct. They only really work for something like a C compiler which will allocate a variable amount of memory, do a task, and then end. If you miss a few free() calls along the way - they will be cleaned up when the compiler terminates.
GlobalAlloc(), LocalAlloc() and friends
Just in case you couldn't make it work with malloc, try the operating system version of the call. Using OS calls really opened the window to some famous bugs - OpenSSH comes to mind.
Multi-threading in C
For any non-trivial problem - it doesn't work. Firstly, for any non-simple piece of code, it is tough to do correctly. Secondly, for a trivial piece of code, like a save operation, you need to somehow make the memory being stored immutable for the duration of the save. For most save operations, this defeats the purpose, as the first thing the user wants to do after save is to change the document. Thirdly, if you really need multi-threading, there is a good chance some of your users need parallel-processing across machines. Multi-threaded code and parallel-processing code are not the same things at all.
Embedding code in data.
Firstly, the x86 architecture encouraged this, by not having proper page protections. Secondly, it completely opens the system up to malicious code. ActiveX, JPEG libraries, font libraries, everywhere Microsoft had an API that embedded code in data, it was all exploited.
The F/A-18 is flown from ships. It makes a difference when comparing mishaps per 100,000 flight hours.
GM did you a favor. I have a Kia with the Microsoft system. An Apple iPhone can crash the system so hard that it needs a full reboot. You have to stop the car, turn the engine-off and restart to get the phone interface working again. The system doesn't work with Android properly either. I assume Microsoft's system must work well with a Zune or a Lumia phone, however I have never seen one to try it out. :-)
Keep the engine stuff separate than the entertainment stuff. If you let Microsoft near your car controls, then it will be like the old Bill Gates compares Windows to a GM car joke.
Maxwell Smart would be so proud. He was the hero in that chased the enemy in a desk, powered by ink from Saudi Arabia.
Big difference: The RaspberryPi has TTL I/O. This makes it easy to do any of a wide variety of hardware interfacing. This new board only has UART ports, which means if you want to do an easy hardware project, you need another microcontroller, tool-chain, etc.
There is a definite market for prototype devices that talk Ethernet, WiFi, UART, SPI, I2C and hardware I/O too. The Raspberry Pi does that well, and inexpensively.
The FBI busted Russian sleeper agents using the WiFi across the food-court trick.
As such, I don't think the WiFi across the food-court would help the DNC.
See the story. There are many articles on the cell. Only a few mention the WiFi link. Quite a few debate whether the agents were actually sleeper agents.
The trailers are shot before the film is. If the trailers don't fit the film as shot, its tough to include them.
Now, if the film companies actually waited for the film to be finished before advertising it, then they wouldn't get caught advertising something they couldn't deliver.
Try 3 at that demo program:
#include <stdio.h>
// Insert almost anything here, use trailing \ if necessary
#include <vector>
#define bool 2
#define vector vector<int> test
int main() {
std::vector[bool];
test[0][0] = 1;
test[1][0] = 2;
printf("%d %d\n", test[0][0], test[1][0]);
return(1);
}
The beauty of C++ is that std::vector[bool] can be almost anything. See below:
#include <stdio.h>
// Insert almost anything here, use trailing \ if necessary
#include <vector>
#define bool 2
#define vector vector test
int main() {
std::vector[bool];
test[0][0] = 1;
test[1][0] = 2;
printf("%d %d\n", test[0][0], test[1][0]);
return(1);
}
I wish I didn't know enough of C++ to write the above ...
The beauty of C++ is that std::vector[bool] can be almost anything. See below:
#include
#include #define bool 2 #define vector vector test int main() { std::vector[bool]; test[0][0] = 1; test[1][0] = 2; printf("%d %d\n", test[0][0], test[1][0]); return(1); }
(seriously: every so often I see women using a baby carriage as a means to clear a path, pushing it into traffic to make everyone stop so she can cross. What's up with that?)
When you have a baby you turn into a sleep deprived zombie.
Go truly random:
head -c 80 /dev/random | base64
Grab a random sequence of characters that you think you can type reliably.