What you're calling "ultimate capacity", you mean "energy density". Which is borderline irrelevant for fixed installations. The main factors for fixed installations is price per watt hour and longevity. SCES has longevity in spades. It's generally expensive because traditional superconductor materials are expensive and have extreme cooling requirements. But if both of these go away, then the situation is totally different.
I was thinking more along the lines of as an electrical substation out in the desert buffering solar facilities or in the middle of a field buffering wind turbines, not something sitting in people's backyards. But yes, point well taken, the problem with a system with extremely high power density is, well, it can release energy extremely fast;)
As for cooling, remember that we're talking about room temperature superconductors here.:)
Just did... looks like my estimate of "a million lines" for Xorg was a bit off. It's "only" half a million lines of code (481739), plus 88k lines of comments and 87k blank lines, in 1476 files.
The nice potential about a carbon-based superconductor would be the possibility that it could be produced very cheaply. Your raw materials are not a price-limiting factor - think "plastic". Thus there's the potential to be way cheaper than copper, yet superconducting. That would be a total game changer to say the least. Lower distribution costs, way more power to the home, far easier to do long-distance transmission, all electric motors being superconducting motors, nearly lossless electronic devices, potential for major improvements in computer performance, cheap maglev, and on and on. There's good reason why affordable room-temperature superconductors are one of the holy grails of modern technology. There's even a type of energy storage system you can make with superconductors - one of the highest power density and efficiency energy storage methods known to man. The energy density will probably always be too low for electric vehicles, but if room temperature superconductors were cheap, that could be amazing for fixed-installation applications.
Seriously, I'd really love to go in myself and fix the bug that's currently preventing me from using GLX, but I wouldn't even know where to begin. I think Xorg is seriously understaffed in terms of volunteers compared to the scale of the project - it looks like most bug reports don't get responses for months or years, if ever.
Template metaprogramming has a use, but generally only in libraries or certain edge cases. But unless you're in that particular use case that needs it, don't use it. And the thing is, people don't use it unless they need to. When was the last time you pulled up a random C++ program off the net and found it full of template metaprogramming? To me that's happened precisely zero times.
If you want to talk about the ability to make programs convoluted messes, macro metaprogramming is by the way far, far worse. And unlike template metaprogramming, I've actually run into that far too often, people who think they're being clever and saving time by macroing the program into a disaster zone. And if you *want* to be evil, my god, can you ever...
The whole point of C++ is things like lazy, bug-free memory management.
Nobody is forcing you to make custom objects. But for getenv("DEITY")'s sake, use STL instead of rolling your own data structures unless you absolutely have to.
And you would call it how? If you would simply call it "start_do_something(local_arg1, local_arg2)", then it's not threaded and doesn't even come close to meeting the spec.
This is a really basic use case here. You've got a single line of code with a couple arguments and want to run it in the background. How much more basic can you get than that? In C++11 it's a single simple line of code. In C it's anything but.
I'm still waiting for someone to *actually* implement the spec in C. We're talking about implementing a single line of C++11, a line involving a commonly desirable task, in C. How hard could this be if C is any sort of half-decent language at all? I even gave you a sample program to put it in (see below).
The problem is that threading isn't trivial in C like it is in C++11, and thus most programmers avoid it unless they absolutely have to deal with it. Which leads to underperforming and hang-prone programs, a problem that's only going to get worse with time.
Sorry, didn't notice you'd taken up the AC's argument. So are you saying that you don't agree with their sarcasm about the capabilities of STL? Do you accept that STL provides great benefits at avoiding reinventing the wheel and thus introducing bugs? Do you agree that anyone randomly trying to reimplement even a basic subset of std::vector (one of the most basic of STL tasks) would in all likelyhood:
1)...find it's not some "trivial" task, relative to simply just calling "std::vector<datatype>"? 2)...find that they don't exceed its performance, and may well come in slower, esp. if they don't spend a long time tuning it? 3)...probably introduce bugs in certain edge cases that they don't catch right away?
These are the reasons that we don't reinvent the wheel.
One of the suggestions I made is the very thing that C does (an "initialize" or "create" function), so if you don't think that looks pretty, then you won't find the C versions pretty either. And I personally find "if (X)" using an explicit bool operator quite pretty, although I personally have no problem with exceptions.
Also, if the constructor failed because of lack of memory, where is it going to store the flag that it failed ?
Are you talking about stack or heap memory failure? If you're talking heap (say, a failure of a "new" call), then the answer is, "As a basic member variable in the class (struct), exactly the same as C data structures do". If you're talking about not having enough memory to create the class on the stack, then you wouldn't have enough memory to create the C equivalent on the stack either.
Right, because the computer world hasn't been facing an overabundance of bugs in code related to memory mismanagement, insufficient threading, improper code duplication, and buggy implementations of common data structures?
There's some descriptions and sample code above, but I'll break it down.
std::thread(): This declares a std::thread object, which is a c++11 thread-launching object. Its constructor here takes an argument of a function.
[&](){... code here... }: This declares a lambda, which is basically an inline function. We could of course declare a function further up, then pass that to the std::thread, but that'd take more code, and more importantly, the declaration would be far from where it's actually being used, which is bad coding style. So we use a lambda to declare it right where we use it. The first part between the brackets declares what variables will be "captured", aka, made usable inside the lambda. So you could say [a,b,c] for variables [a,b,c]. & means "everything". The () is just like for any function - there's no arguments, so it's just (). The brackets are, again, just like with any other function - they enclose code..detach(): We're telling our newly created thread to detach.
gcc actually just wraps the c++11 code into pthreads, so it works exactly the same way - you even still have to link in -lpthread. But it's far easier in C++11, especially once you get away from trivial cases. And this is actually just the beginning of what you can do - there's also futures, for example, that let you do stuff like:
auto a = std::async(std::launch::async, [](){ return waste_time(1.0); }); auto b = std::async(std::launch::async, [](){ return waste_time(2.0); }); printf("Result: %f\n", a.get() + b.get());
The printf won't evaluate until both the first and second waste_time functions are done evaluating and have returned a value, but it doesn't make them evaluate in a particular order. If you wanted you could take std:async a step further and wrap it into an object that overloads common operators with an automatic call to get(), and thus you could have something like:
auto a = my_async([](){ return waste_time(1.0); }); auto b = my_async([](){ return waste_time(2.0); }); printf("Result: %f\n", a + b);
Oh, and just to let you know, even your minimal example that doesn't come close to meeting the specs cheats on not declaring the pthread_t (you can't declare it inline) and has a bug in the declaration of func (should return void*). (we'll just take it for granted that that thread_1_stuff, thread_2_stuff, arg, and #include <pthread.h> exist, since the equivalents are assumed in my example)
I'll go ahead and help you out on meeting the specs provided by giving you a realistic sample program (I'll skip file error checking for simplicity; all of the other code is plain C). Replace the C++11 code with the C equivalent.
void do_something(float a, float b) {// Let's waste some time to simulate a time-intensive task.
float c = 0;
int i;
for (i = 0; i < 10000000; i++)
c = c * b + a;
printf("%f, %f: %f\n", a, b, c); }
int main(int argc, char** argv) {
FILE* fp = fopen(argv[1], "r");
while (!feof(fp))
{
float a, b;
fscanf(fp, "%f, %f\n", &a, &b);
std::thread([a,b](){ do_something(a, b); }).detach();// REPLACE ME
}
while (1)
sleep(1); }
Surely that's a trivial task, right? You just need to replace one line, after all. Go for it.
First off, in what freaking style guide is it acceptable to declare a function and a three-command main function all on one line? Inline lambdas are perfectly fine style, that's pretty much what they're there for, but what you did isn't even close to acceptable style.
Secondly, that's not what I asked of you. I did not say "create the simplest pthread example you possibly could". I'll repeat what I asked of you:
1) a thread, that 2) runs a function called do_something, that 3) takes two arguments, that 4) are varialbes local to the function that spawns the thread, with 5) no restrictions that the thread may only have one instance at a time, and 6) runs detached
No problem, we'll make it easy on you - just implement the basic subset - creation, initialization, push_back, indexing, and erasure.
Surely since vector is one of the most basic, common types in C++, and you saw fit to put the words "powerful features" in quotes (meaning that you think that the features are trivial), this task must be a breeze for you, right? So go on, give me your quickly written bug-free implementation that performs better than std::vector. And remember, all I have to type is "std::vector<datatype>", so this must be a breeze, right?
There's several ways. One is exceptions, which you already said you don't like. Another is to pass by reference (or pointer, if you prefer) a success flag into the constructor. Another is to use a factory method to build the object. Another is to have a queriable flag built into the object. You can even implement such a flag by having the object able to evaluate as boolean ("explicit operator bool() const { return success_flag; }"), so you can do "if (X x) {.... }". There's countless ways, all the way up to and including the standard approach in pure C, having a "create" or "initialize" function that does the work that can fail. It's all about your personal preferences.
To a degree, but the vast majority of what you'll see only requires understanding a few concepts over basic C (objects, iterators, templates, etc), the rest is no more RTFM than what you'd see from any C library. C++11 introduces a few concepts (lambdas, for example), but again, the vast majority of the new stuff is no more RTFM than any old C library. You see someone use a... oh, let's say std::shared_ptr, and you don't have any experience with it? You just look up, the same as you'd do if you saw someone using a C package that you weren't familiar with - say, if you read code and someone was using a FcMatrix and you'd never programmed with Fontconfig.
Right. Because bug-free automatic memory management is silly, who would want that? Who would want inline threading when you can write a page of pthread code every time you want a thread? Why would anyone want templates when they can copy-paste and modify/maintain the same code a 20 times? Who doesn't want to have to reimplement every type of data structure known to man, each time introducing the risk of bugs? I could go on, there's so many reasons why there's "no reason or excuse to use C++"!
"Complexities" vs. "Powerful features". Okay, I'll bite. Implement an equivalent to std::vector (one of the most basic and commonly used STL objects) in C for me. Make it 100% bug free and perform better than std::vector. Go.
(Because if I want something like that, all I have to type is "std::vector<datatype>". Oooh, so damned complex, I'm trembling even thinking about it!)
Anyone know what the efficiencies are on these sorts of "tabletop" laser particle accelerators versus say a linac? I'm curious as to whether it'd make an effective "tabletop" spallation neutron source - protons in the range of a couple hundred MEv to a few GEv are ideal for that purpose. (yes, I know this one is an electron accelerator, but ultrashort laser pulses can also accelerate protons, although I don't know if you can hit the same sorts of energies).
Your proof that C++ is in general slower than C is....?
STL is generally quite optimized (more than most C programmers will do with their home-rolled reinventions of the wheel), and templates allow code to be built automatically then and optimized by the compiler, which is why for example std::sort is faster than qsort().
Your "complex class heirarchies" suggests that you seem to just think of C++ as "C with objects". You can write excellent C++ code making use of all sorts of powerful C++ features without ever rolling an object of your own.
Neither does C++ force objects on you. Your approach is quite reasonable.
I came to give up my antipathy toward objects and come to love them when coding in LPC for an LP mud. In LPC, each file you make is an object (written in LPC, which is very much like regular C), and it corresponds to a physical object in the game. So among the many functions you can call are those which set your name, your short and long descriptions, and add various callback functions for when people try to interact with you in various ways. All objects have inventory, and generally exist inside another object, all of which can be queried. Your object call any function on any other object. Your player object is, yet again, another object. "Wizards" (coders) manually call functions on other objects.The net result is this really intuitive "I'm just interacting with other physical things" style of coding and debugging.
It also made for very good "code wars" with other wizards. Example: it was common for wizards to create "dest tools", objects that when called would destruct a player's object, forcing them out of the game and to have to reconnect, as a punishment. Usually these were done with artsy flourishes and leadups. One wizard I knew wrote a dest involving him picking a rose, playing "she loves me, she loves me not" with it, and when the last petal is plucked ("She loves me not"), the target would get dested.
Tired of him using it on me, I wrote a counter dest, which when I saw his dest, I would call it on him. It would then destroy all objects in his inventory (including any dest tools, thus stopping his dest) and put an object in his inventory that would eat all of his commands so he couldn't counter me or or quit out. My parody dest would then commence, involving a giant ogre playing "She loves me, she loves me not" with the target's limbs while they cry out in pain, before discarding the torso and destructing their player object.
So said wizard took to using an instant dest, so that I wouldn't have time to call my tool. So I took to creating a tool that would make itself invisible, leap into the wizard's inventory and wait for them to issue their dest command, block it, then trigger my dest. It became an arms race, leading to tools that would monitor one's inventory (and later, their room) for sneaky invisible objects and destroy them, to tools to try to sneak past these, and so forth. Once I accidentally nearly took out the MUD in the process - I was testing in the login room and a tool went awry, dested me, fell to the ground, and dested everyone that logged in. I could upload new code to the MUD via FTP to try to correct it, but without being able to log in, I had no way to execute it. The day was saved when I uploaded a file into another coder's home directory (the only one still logged in, in a different room) with a name like "PLEASE_DO_NOT_LOG_OUT_URGENT_READ_THIS.txt" explaining the situation and how to remedy it; he luckily noticed the file and fixed the problem.
Nobody said you have to learn everything - its not like C++ is all-or-nothing. It's precisely the opposite, it's a grab-bag of tools and you can use whichever ones you want. But you should at least learn the ones that apply to what you're doing. Using strings? Learn std::string. Using a variable-length array? Learn std::vector or similar. Using smart pointers? Learn std::shared_ptr. Just learn the part that applies to whatever you're using, it's just RTFM. There's only a few basic concepts you'll need to understand.
Slashdot Mirror
What you're calling "ultimate capacity", you mean "energy density". Which is borderline irrelevant for fixed installations. The main factors for fixed installations is price per watt hour and longevity. SCES has longevity in spades. It's generally expensive because traditional superconductor materials are expensive and have extreme cooling requirements. But if both of these go away, then the situation is totally different.
I was thinking more along the lines of as an electrical substation out in the desert buffering solar facilities or in the middle of a field buffering wind turbines, not something sitting in people's backyards. But yes, point well taken, the problem with a system with extremely high power density is, well, it can release energy extremely fast ;)
As for cooling, remember that we're talking about room temperature superconductors here. :)
Just did... looks like my estimate of "a million lines" for Xorg was a bit off. It's "only" half a million lines of code (481739), plus 88k lines of comments and 87k blank lines, in 1476 files.
The nice potential about a carbon-based superconductor would be the possibility that it could be produced very cheaply. Your raw materials are not a price-limiting factor - think "plastic". Thus there's the potential to be way cheaper than copper, yet superconducting. That would be a total game changer to say the least. Lower distribution costs, way more power to the home, far easier to do long-distance transmission, all electric motors being superconducting motors, nearly lossless electronic devices, potential for major improvements in computer performance, cheap maglev, and on and on. There's good reason why affordable room-temperature superconductors are one of the holy grails of modern technology. There's even a type of energy storage system you can make with superconductors - one of the highest power density and efficiency energy storage methods known to man. The energy density will probably always be too low for electric vehicles, but if room temperature superconductors were cheap, that could be amazing for fixed-installation applications.
All million lines of it ;)
Seriously, I'd really love to go in myself and fix the bug that's currently preventing me from using GLX, but I wouldn't even know where to begin. I think Xorg is seriously understaffed in terms of volunteers compared to the scale of the project - it looks like most bug reports don't get responses for months or years, if ever.
Whoops, broken link: "my god, can you ever..."
Template metaprogramming has a use, but generally only in libraries or certain edge cases. But unless you're in that particular use case that needs it, don't use it. And the thing is, people don't use it unless they need to. When was the last time you pulled up a random C++ program off the net and found it full of template metaprogramming? To me that's happened precisely zero times.
If you want to talk about the ability to make programs convoluted messes, macro metaprogramming is by the way far, far worse. And unlike template metaprogramming, I've actually run into that far too often, people who think they're being clever and saving time by macroing the program into a disaster zone. And if you *want* to be evil, my god, can you ever...
The whole point of C++ is things like lazy, bug-free memory management.
Nobody is forcing you to make custom objects. But for getenv("DEITY")'s sake, use STL instead of rolling your own data structures unless you absolutely have to.
And you would call it how? If you would simply call it "start_do_something(local_arg1, local_arg2)", then it's not threaded and doesn't even come close to meeting the spec.
This is a really basic use case here. You've got a single line of code with a couple arguments and want to run it in the background. How much more basic can you get than that? In C++11 it's a single simple line of code. In C it's anything but.
I'm still waiting for someone to *actually* implement the spec in C. We're talking about implementing a single line of C++11, a line involving a commonly desirable task, in C. How hard could this be if C is any sort of half-decent language at all? I even gave you a sample program to put it in (see below).
The problem is that threading isn't trivial in C like it is in C++11, and thus most programmers avoid it unless they absolutely have to deal with it. Which leads to underperforming and hang-prone programs, a problem that's only going to get worse with time.
Sorry, didn't notice you'd taken up the AC's argument. So are you saying that you don't agree with their sarcasm about the capabilities of STL? Do you accept that STL provides great benefits at avoiding reinventing the wheel and thus introducing bugs? Do you agree that anyone randomly trying to reimplement even a basic subset of std::vector (one of the most basic of STL tasks) would in all likelyhood:
1) ...find it's not some "trivial" task, relative to simply just calling "std::vector<datatype>"? ...find that they don't exceed its performance, and may well come in slower, esp. if they don't spend a long time tuning it? ...probably introduce bugs in certain edge cases that they don't catch right away?
2)
3)
These are the reasons that we don't reinvent the wheel.
One of the suggestions I made is the very thing that C does (an "initialize" or "create" function), so if you don't think that looks pretty, then you won't find the C versions pretty either. And I personally find "if (X)" using an explicit bool operator quite pretty, although I personally have no problem with exceptions.
Are you talking about stack or heap memory failure? If you're talking heap (say, a failure of a "new" call), then the answer is, "As a basic member variable in the class (struct), exactly the same as C data structures do". If you're talking about not having enough memory to create the class on the stack, then you wouldn't have enough memory to create the C equivalent on the stack either.
Right, because the computer world hasn't been facing an overabundance of bugs in code related to memory mismanagement, insufficient threading, improper code duplication, and buggy implementations of common data structures?
You don't have to learn anything to keep using printf in C++. Why would you think that you did?
There's some descriptions and sample code above, but I'll break it down.
std::thread(): This declares a std::thread object, which is a c++11 thread-launching object. Its constructor here takes an argument of a function.
[&](){ ... code here ... }: This declares a lambda, which is basically an inline function. We could of course declare a function further up, then pass that to the std::thread, but that'd take more code, and more importantly, the declaration would be far from where it's actually being used, which is bad coding style. So we use a lambda to declare it right where we use it. The first part between the brackets declares what variables will be "captured", aka, made usable inside the lambda. So you could say [a,b,c] for variables [a,b,c]. & means "everything". The () is just like for any function - there's no arguments, so it's just (). The brackets are, again, just like with any other function - they enclose code. .detach(): We're telling our newly created thread to detach.
gcc actually just wraps the c++11 code into pthreads, so it works exactly the same way - you even still have to link in -lpthread. But it's far easier in C++11, especially once you get away from trivial cases. And this is actually just the beginning of what you can do - there's also futures, for example, that let you do stuff like:
auto a = std::async(std::launch::async, [](){ return waste_time(1.0); });
auto b = std::async(std::launch::async, [](){ return waste_time(2.0); });
printf("Result: %f\n", a.get() + b.get());
The printf won't evaluate until both the first and second waste_time functions are done evaluating and have returned a value, but it doesn't make them evaluate in a particular order. If you wanted you could take std:async a step further and wrap it into an object that overloads common operators with an automatic call to get(), and thus you could have something like:
auto a = my_async([](){ return waste_time(1.0); });
auto b = my_async([](){ return waste_time(2.0); });
printf("Result: %f\n", a + b);
Usually, though (IMHO) futures are overkill.
Oh, and just to let you know, even your minimal example that doesn't come close to meeting the specs cheats on not declaring the pthread_t (you can't declare it inline) and has a bug in the declaration of func (should return void*). (we'll just take it for granted that that thread_1_stuff, thread_2_stuff, arg, and #include <pthread.h> exist, since the equivalents are assumed in my example)
I'll go ahead and help you out on meeting the specs provided by giving you a realistic sample program (I'll skip file error checking for simplicity; all of the other code is plain C). Replace the C++11 code with the C equivalent.
Surely that's a trivial task, right? You just need to replace one line, after all. Go for it.
First off, in what freaking style guide is it acceptable to declare a function and a three-command main function all on one line? Inline lambdas are perfectly fine style, that's pretty much what they're there for, but what you did isn't even close to acceptable style.
Secondly, that's not what I asked of you. I did not say "create the simplest pthread example you possibly could". I'll repeat what I asked of you:
std::thread([&](){ do_something(local_arg1, local_arg2); }).detach();
That is, I asked you to create:
1) a thread, that
2) runs a function called do_something, that
3) takes two arguments, that
4) are varialbes local to the function that spawns the thread, with
5) no restrictions that the thread may only have one instance at a time, and
6) runs detached
Go.
No problem, we'll make it easy on you - just implement the basic subset - creation, initialization, push_back, indexing, and erasure.
Surely since vector is one of the most basic, common types in C++, and you saw fit to put the words "powerful features" in quotes (meaning that you think that the features are trivial), this task must be a breeze for you, right? So go on, give me your quickly written bug-free implementation that performs better than std::vector. And remember, all I have to type is "std::vector<datatype>", so this must be a breeze, right?
There's several ways. One is exceptions, which you already said you don't like. Another is to pass by reference (or pointer, if you prefer) a success flag into the constructor. Another is to use a factory method to build the object. Another is to have a queriable flag built into the object. You can even implement such a flag by having the object able to evaluate as boolean ("explicit operator bool() const { return success_flag; }"), so you can do "if (X x) { .... }". There's countless ways, all the way up to and including the standard approach in pure C, having a "create" or "initialize" function that does the work that can fail. It's all about your personal preferences.
To a degree, but the vast majority of what you'll see only requires understanding a few concepts over basic C (objects, iterators, templates, etc), the rest is no more RTFM than what you'd see from any C library. C++11 introduces a few concepts (lambdas, for example), but again, the vast majority of the new stuff is no more RTFM than any old C library. You see someone use a... oh, let's say std::shared_ptr, and you don't have any experience with it? You just look up, the same as you'd do if you saw someone using a C package that you weren't familiar with - say, if you read code and someone was using a FcMatrix and you'd never programmed with Fontconfig.
Right. Because bug-free automatic memory management is silly, who would want that? Who would want inline threading when you can write a page of pthread code every time you want a thread? Why would anyone want templates when they can copy-paste and modify/maintain the same code a 20 times? Who doesn't want to have to reimplement every type of data structure known to man, each time introducing the risk of bugs? I could go on, there's so many reasons why there's "no reason or excuse to use C++"!
"Complexities" vs. "Powerful features". Okay, I'll bite. Implement an equivalent to std::vector (one of the most basic and commonly used STL objects) in C for me. Make it 100% bug free and perform better than std::vector. Go.
(Because if I want something like that, all I have to type is "std::vector<datatype>". Oooh, so damned complex, I'm trembling even thinking about it!)
Anyone know what the efficiencies are on these sorts of "tabletop" laser particle accelerators versus say a linac? I'm curious as to whether it'd make an effective "tabletop" spallation neutron source - protons in the range of a couple hundred MEv to a few GEv are ideal for that purpose. (yes, I know this one is an electron accelerator, but ultrashort laser pulses can also accelerate protons, although I don't know if you can hit the same sorts of energies).
Your proof that C++ is in general slower than C is....?
STL is generally quite optimized (more than most C programmers will do with their home-rolled reinventions of the wheel), and templates allow code to be built automatically then and optimized by the compiler, which is why for example std::sort is faster than qsort().
Your "complex class heirarchies" suggests that you seem to just think of C++ as "C with objects". You can write excellent C++ code making use of all sorts of powerful C++ features without ever rolling an object of your own.
Neither does C++ force objects on you. Your approach is quite reasonable.
I came to give up my antipathy toward objects and come to love them when coding in LPC for an LP mud. In LPC, each file you make is an object (written in LPC, which is very much like regular C), and it corresponds to a physical object in the game. So among the many functions you can call are those which set your name, your short and long descriptions, and add various callback functions for when people try to interact with you in various ways. All objects have inventory, and generally exist inside another object, all of which can be queried. Your object call any function on any other object. Your player object is, yet again, another object. "Wizards" (coders) manually call functions on other objects.The net result is this really intuitive "I'm just interacting with other physical things" style of coding and debugging.
It also made for very good "code wars" with other wizards. Example: it was common for wizards to create "dest tools", objects that when called would destruct a player's object, forcing them out of the game and to have to reconnect, as a punishment. Usually these were done with artsy flourishes and leadups. One wizard I knew wrote a dest involving him picking a rose, playing "she loves me, she loves me not" with it, and when the last petal is plucked ("She loves me not"), the target would get dested.
Tired of him using it on me, I wrote a counter dest, which when I saw his dest, I would call it on him. It would then destroy all objects in his inventory (including any dest tools, thus stopping his dest) and put an object in his inventory that would eat all of his commands so he couldn't counter me or or quit out. My parody dest would then commence, involving a giant ogre playing "She loves me, she loves me not" with the target's limbs while they cry out in pain, before discarding the torso and destructing their player object.
So said wizard took to using an instant dest, so that I wouldn't have time to call my tool. So I took to creating a tool that would make itself invisible, leap into the wizard's inventory and wait for them to issue their dest command, block it, then trigger my dest. It became an arms race, leading to tools that would monitor one's inventory (and later, their room) for sneaky invisible objects and destroy them, to tools to try to sneak past these, and so forth. Once I accidentally nearly took out the MUD in the process - I was testing in the login room and a tool went awry, dested me, fell to the ground, and dested everyone that logged in. I could upload new code to the MUD via FTP to try to correct it, but without being able to log in, I had no way to execute it. The day was saved when I uploaded a file into another coder's home directory (the only one still logged in, in a different room) with a name like "PLEASE_DO_NOT_LOG_OUT_URGENT_READ_THIS.txt" explaining the situation and how to remedy it; he luckily noticed the file and fixed the problem.
Nobody said you have to learn everything - its not like C++ is all-or-nothing. It's precisely the opposite, it's a grab-bag of tools and you can use whichever ones you want. But you should at least learn the ones that apply to what you're doing. Using strings? Learn std::string. Using a variable-length array? Learn std::vector or similar. Using smart pointers? Learn std::shared_ptr. Just learn the part that applies to whatever you're using, it's just RTFM. There's only a few basic concepts you'll need to understand.