Penny Arcade teaches computer science. I like it. ^_^
We haven't even posted example code yet. The PA forums programming thread has a very specific style guide for code snippets.
What was it again?
namespace PA {
namespace Examples {
namespace Author {
class tFizzBuzz
{
// Function name End
static bool IsFizz( int number ) { return (number % 5) != 0; } // of single line here
static bool IsBuzz( int number ) { return (number % 3) != 0; } // Maybe template with IsFizz
static bool IsFizzBuzz( int number ) { return IsFizz( number ) || IsBuzz( number ); }
// Maybe this should go into a templated solution, as the results can technically be
// evaluated at compile time.
}
};
} // namespace Author
} // namespace Examples
} // namespace PA
I'm helping learning!
#include <cstdio>
namespace PA {
namespace Examples {
namespace Author {
template <typename T>
class Z { public: static const typename T::type value = T::zero; };
template <typename T, typename N>
class S { public: static const typename T::type value = N::value + T::one; };
template <typename T>
struct tFizzBuzz
{
// Function name End
static bool IsFizz( typename T::type number ) { return (number % S<T, S<T, S<T, S<T, S<T, Z<T> > > > > >::value) != Z<T>::value; } // of single line here
static bool IsBuzz( typename T::type number ) { return (number % S<T, S<T, S<T, Z<T> > > >::value) != Z<T>::value; } // Maybe template with IsFizz
static bool IsFizzBuzz( typename T::type number ) { return IsFizz( number ) || IsBuzz( number ); }
// Maybe this should go into a templated solution, as the results can technically be
// evaluated at compile time. K: Yes, yes it should
};
} // namespace Author
} // namespace Examples
class _INT_TRAIT { /* int trait for templates --- Highly generic! */
public:
typedef int type;
public:
static const type zero = 0;
public:
static const type one = 1;
};
} // namespace PA
int main() {
std::printf("%d\n", PA::Examples::Author::tFizzBuzz<PA::_INT_TRAIT>::IsFizz(5));
std::printf("%d\n", PA::Examples::Author::tFizzBuzz<PA::_INT_TRAIT>::IsBuzz(5));
std::printf("%d\n", PA::Examples::Author::tFizzBuzz<PA::_INT_TRAIT>::IsFizzBuzz(15));
}
Maybe we're putting the cart before the horse - have your teachers explained to you the different between the "stack" and the "heap", and their purposes?
At the risk of starting off another multi-page rant, this is some of the unfortunate baggage that C++ comes with due to its history. Since it grew up with C (for much of its early life, you would consider using CFront to convert your C++ to C), you were able to choose between using the C libraries or the C++ libraries.
Lots of developers moving to C++ from C would stay with their familiar tools in C, and so you get this strange hybrid mix of C strings/arrays in C++ libraries that's never really been.. ummm... "exorcised". They would have taught other people to mix C/C++ together, which results in the mess that you're having to deal with today, because... unfortunately, you're likely to deal with code that does mix C and C++.
Edit: Also, the early string/vector libraries were not as good as they are today, so some old fashioned "PERFORMANCE AT ALL COSTS!!!" developers would fall back to C techniques.
I think this is the issue, he talks about the 12 ways you could do something. Some of which I look at and say, why in the world would you do that? It is frustrating, because while I could use a sledge hammer to pound a nail into the wall of my house, I have a good chance I will screw it up, and should use a tool more suited.
Thanks for the help though, I will have to try out this dynamic array stuff now. Thankfully the homework got pushed back to being due on the 28th. Oh, and if people wonder, no I did not post the specific assignment on purpose. I want help with things I don't understand, but I would like to tackle the main part myself.
Some of which I look at and say, why in the world would you do that? It is frustrating, because while I could use a sledge hammer to pound a nail into the wall of my house, I have a good chance I will screw it up, and should use a tool more suited.
This is usually a very good thing.
0
Options
GrobianWhat's on sale?Pliers!Registered Userregular
edited January 2015
To be fair to the second prof, giving someone 12 hammers to learn which one is best for which task is generally a better learning experience than just giving them one hammer and telling them "use this for nails". Or rather, they accomplish different learning goals, so it makes sense to me for the latter to be the introductory course (fast success, so better student motivation) and the former being the advanced course.
Doesn't help if it isn't explained well, though.
Also I took theoretical computer science at university, so I'm obviously biased there. We were all about building our own data structures/algorithms instead of using whatever the languages/libraries come with. Doesn't mean I still do it in my day-to-day.
Polling for events is, in general, wrong - especially in multi-threaded applications.
There are generally many ways to get event driven mechanisms.
Handling events may be more complicated, but they are much superior than nagging the CPU with, "Are we doing something yet?" "What about now?" "What about nooow?"
Edit:
Prominent exception
Situations where the answer to the poll is predominantly "yes", e.g. high performance networking drivers that are under constant heavy load.
So yes, I acknowledge that there are situations where polling is appropriate. But most commonly? No. No polling.
Does UI fall under this? I've seen polling in stuff like GTK.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
Options
KakodaimonosCode fondlerHelping the 1% get richerRegistered Userregular
Polling for events is, in general, wrong - especially in multi-threaded applications.
There are generally many ways to get event driven mechanisms.
Handling events may be more complicated, but they are much superior than nagging the CPU with, "Are we doing something yet?" "What about now?" "What about nooow?"
Edit:
Prominent exception
Situations where the answer to the poll is predominantly "yes", e.g. high performance networking drivers that are under constant heavy load.
So yes, I acknowledge that there are situations where polling is appropriate. But most commonly? No. No polling.
Corollary
When you are looking at the code for a low latency pricefeed handler that is using kernel bypass network cards, do not go through and just replace the Sleep(0) calls with Sleep(1) or Thread.Yield calls if you don't understand the differences between all those calls.
To be fair to the second prof, giving someone 12 hammers to learn which one is best for which task is generally a better learning experience than just giving them one hammer and telling them "use this for nails". Or rather, they accomplish different learning goals, so it makes sense to me for the latter to be the introductory course (fast success, so better student motivation) and the former being the advanced course.
I guess I can't argue there. I think the frustration comes from the two widely different teacher approaches. The second teacher putting up 3 ways in rapid succession with little explanation of why you would do any of them is confusing to me. Lets see if I can say this right.
You can do this
Name *myName;
cout << (*myName).first;
or
cout << myName->first;
The third way had more *'s in it, and I would have to dig through my notes. I could have gotten any of these wrong, but I know he showed three ways for the exact same thing. And left it at, it is your decision as a developer to choose what to use. But than requires certain things on assignments. So I think I got that right, but I hope anyone who knows c++ understands I'm trying to point out you can use a * or a -> to dereference. Why would I do one over the other? Style? What does the industry use? If I get someone else's code I could end up with anything I guess.
Maybe I'm just stubborn and hate doing things different that I have done on my own coding time. As if left alone, I can get a program to do exactly what it should, it just might not look the same under the hood.
(*x). is always equivalent to -> (*caveats apply for overloaded operators of course, if you're a monster). In general, you always use the -> form whenever possible because there's a simple informal rule: if you have to add extra parens there's likely a better way
But, the teacher's not wrong here, he should have explained which ones get used when, but it is important to know that the constructs are equivalent
C++ is a language (and it is not unique in this trait) where there's about a million ways to do anything, including really basic tasks, such as calling a member variable in a struct, as you've just demonstrated.
Do NOT concern yourself with which is best, just roll with it. Professors do confusing crap sometimes because they're trying to expose you to as many elements of the language as possible. I suspect your professor is not trying to teach you how to engineer software, he is trying to teach you how to read and write C++, and those two goals are NOT on the same path at all. One requires you to fabricate a bunch of examples so you can quickly make it through a bunch of unrelated features, one requires you to slowly and steadily introduce problems to be solved with familiar tools.
If you're learning C++ right now, it's not the time to think "which of these is better?" It's time to take stock and learn as much about the different things you're being exposed to as possible. Think about them, but don't stress out that you're maybe using the wrong tool for the job on your homework: of course you are. And you will be for the entire class. Then you'll take a class that asks you to do things right and you'll start putting your tools to good use.
The only operators that can't be overloaded:
.
?:
::
.*
Yes, you can overload *, ->, & to make one object pretend to be another completely different object in every way (smart pointers!). Or three completely different objects of different types!
PSA: Code School and Pluralsight are giving away 72 free hours of course access this week. As far as I can tell, all their courses are free during this time.
Polling for events is, in general, wrong - especially in multi-threaded applications.
There are generally many ways to get event driven mechanisms.
Handling events may be more complicated, but they are much superior than nagging the CPU with, "Are we doing something yet?" "What about now?" "What about nooow?"
Edit:
Prominent exception
Situations where the answer to the poll is predominantly "yes", e.g. high performance networking drivers that are under constant heavy load.
So yes, I acknowledge that there are situations where polling is appropriate. But most commonly? No. No polling.
Does UI fall under this? I've seen polling in stuff like GTK.
In general, yes, because UI is a great example for event driven programming - your buttons don't do anything until a user gives you a click on them (or mouse hovers). Your data grid doesn't update until it's got new data...
I'm sure there's some edge cases where polling is the least bad choice out of all choices, but in general, please stop with the polling.
Interesting tidbit:
Did you know, you can turn standard input into an event driven model? None of this cin.get() business.
PSA: Code School and Pluralsight are giving away 72 free hours of course access this week. As far as I can tell, all their courses are free during this time.
Most likely in a multithreaded game, one CPU will nearly always be pegged (the drawing one) and the others will be using minimal thread resources to poll other sources for data.
Things like network or input will likely sit idle most of the time.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Maybe we're putting the cart before the horse - have your teachers explained to you the different between the "stack" and the "heap", and their purposes?
If I was told, I forgot, or don't understand.
Ah. In most languages, there are two main areas of memory*, the "stack" and the "heap".
On modern Windows apps, your stack** is about 1Mb by default. Your potential heap size is a smidge short of 2Gb on 32-bit Windows***, and some large ridiculous number on 64-bit versions of Windows.
So you can appreciate that if you wanted some large data structures (e.g. things that are, say, 10Mb), you would not be able to fit them into the stack - you would have to allocate those in the heap.
So why are the stack and heap two different areas of memory, and such different sizes? Because of their purpose.
The stack is where your functions put their variables. Every time you call a function and it instantiates a variable, that's put on the stack. ****
For example:
void Example();
int main( int argc, char *argv[] )
{
int firstVariable;
// At this point, the stack looks like:
// firstVariable
// [bottom of stack]
int secondVariable;
// At this point, the stack looks like:
// secondVariable
// firstVariable
// [bottom of stack]
int thirdVariable;
// At this point, the stack looks like:
// thirdVariable
// secondVariable
// firstVariable
// [bottom of stack]
Example();
// After the function call, the stack looks like it was before the call:
// thirdVariable
// secondVariable
// firstVariable
// [bottom of stack]
}
void Example()
{
// At this point, the stack looks like:
// call-from-main-to-Example()
// thirdVariable
// secondVariable
// firstVariable
// [bottom of stack]
int fizz;
// At this point, the stack looks like:
// fizz
// call-from-main-to-Example()
// thirdVariable
// secondVariable
// firstVariable
// [bottom of stack]
int buzz;
// At this point, the stack looks like:
// buzz
// fizz
// call-from-main-to-Example()
// thirdVariable
// secondVariable
// firstVariable
// [bottom of stack]
// When any function exits, the stack is cleaned up back to where the call occurred
// In this case, fizz and buzz are both removed from the stack and no longer valid to use
}
You might not have realised it, but you've probably already encountered the term "stack" inadvertently.
For example, the term "stack overflow" occurs when you've called too many functions, and you're using up more memory than the stack has available (typically when you use recursion).
When you're debugging using Visual Studio (with breakpoints, and stepping into functions etc), you may have noticed the "call stack" window (if not, look at the menu Debug -> Windows -> Call stack - this lists the function calls on the stack).
So, in short, whenever you instantiate variables in a function, you're putting them on the stack. So when programmers say, "It's on the stack", it's not some super secret jargon or anything, it's... well, literally a variable that's been put on the stack.
Now, you might have noticed a few things:
1.) Stack variables are cleaned up at the end of their function/scope
2.) Stack space is limited compared to heap space (Mb vs Gb, or more in a 64-bit OS!)
3.) In current C++, variables that are to be allocated on the stack must have a size that is known at compile time (so no dynamically sized arrays)
So this is where the "heap" comes in:
1.) If you want a variable to outlive the end of the function, then instead of allocating from the stack, you must allocate from the heap.
2.) If you want to allocate large blocks of memory, because the heap typically has so much more memory, you typically allocate from the heap.
3.) If you want to allocate memory whose size is determined at run time, you'll need to allocate from the heap.
4.) Heap allocated variables must be cleaned up by code - unlike stack variables which implicitly get cleaned up at the end of their function/scope.
The heap is basically a big pile of available memory that the OS provides for you to use as you see fit.
There are many ways to allocate memory from the heap - the classic C "malloc()", C++ "new/new[]", OS specific functions - but the most important thing is that you must use the clean up function that matches your allocation method. For example, if you used "malloc()" to allocate memory, then you must use "free()" to deallocate it. If you used "new", then you must use "delete". If you used "new[]", then "delete[]". You cannot mix and match the various methods - think of it as each allocation having its own bookkeeping, and using the wrong clean up function screws up the bookkeeping something fierce.
In a non-trivial program, you will see variables allocated on both the stack and the heap, as well as variables that can be allocated on the stack and implicitly make use of the heap (std::vector, std::string).
So technically, what I've told you about the heap and stack has a bunch of exceptions - but in general, it's true enough to hopefully aid in understanding wtf in going on.
* In practice, your operating system/application/system may give you more 'types' of memory (e.g. memory mapped I/O, memory mapped files, hardware/peripheral memory, etc...), but ignore those for now.
** Per thread that you run.
*** By default, although this can be adjusted to about 3Gb if you want to shoot your customers in the foot.
**** Technically not always true in practice, but again, true enough when you're learning.
3.) In current C++, variables that are to be allocated on the stack must have a size that is known at compile time (so no dynamically sized arrays)
well.... you could get around that by using alloca and new placement
but that arguably doesn't count as "current C++" since alloca isn't really a standard thing
and I'm also pretty sure that means your destructor wouldn't get called for you
so I guess it's basically something you shouldn't normally be doing anyway
pretend I didn't say anything, is what I'm saying
End on
I wish that someway, somehow, that I could save every one of us
alloca has exactly one use - to allocate a variably-sized array, usually as a buffer. However, the question then becomes - if your size is expected to be large why aren't you mallocing it, if it is small why not use a fixed size? If you don't know, then you're asking to overflow your stack
PSA: Code School and Pluralsight are giving away 72 free hours of course access this week. As far as I can tell, all their courses are free during this time.
If polling is bad then what's a good way to update a number of notifications for a specific user (very similar to how Facebook works)? Just curious.
If it's a web client then you want to use socket.io and push semantics on the client side. Though I too don't really know what you do with server stuff - you're kind of stuck to some sort of polling the database unless the other components can emit events.
Egads! They're getting rid of our Keurig in the office... We're down to 5 k-cups left.
They are opting for a drip machine but the problem is that people don't know how to make coffee to save their lives and we run the issue of wasting a bunch.
Egads! They're getting rid of our Keurig in the office... We're down to 5 k-cups left.
They are opting for a drip machine but the problem is that people don't know how to make coffee to save their lives and we run the issue of wasting a bunch.
That seems dumb. What's going to end up happening is everyone is going to buy their own for their desk.
You should all get together and ask them to put it back in, and just provide your own kcups.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Honestly, K-cups are a terrible way for an office to do coffee; that's a lot of plastic and paper for every single cuppajoe. Just write up an instruction set in Python or something and hang it next to the pot.
Yeah I think they'll leave the Keurig but stop providing K-Cups. But yeah apparently people were stealing the K-Cups and it is at the point where they're just going to switch to regular coffee makers to prevent it.
Honestly, K-cups are a terrible way for an office to do coffee; that's a lot of plastic and paper for every single cuppajoe. Just write up an instruction set in Python or something and hang it next to the pot.
Well k-cups in general are a terrible way to do coffee because of waste, even in a home setting.
But better to do that then waste time for people getting pissed and antsy waiting for a new batch to be brewed, then getting more pissed because someone fucked it up, or made it too strong, or whatever.
25 cents in plastic waste might be better than $1 in payroll waste.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Honestly, K-cups are a terrible way for an office to do coffee; that's a lot of plastic and paper for every single cuppajoe. Just write up an instruction set in Python or something and hang it next to the pot.
Well k-cups in general are a terrible way to do coffee because of waste, even in a home setting.
But better to do that then waste time for people getting pissed and antsy waiting for a new batch to be brewed, then getting more pissed because someone fucked it up, or made it too strong, or whatever.
25 cents in plastic waste might be better than $1 in payroll waste.
For my home setting:
(This assumes you don't have one of those stupid new DRM Keurigs, though keeping a lid around to fool the security isn't that big a deal I guess.)
For the office, brewing a pot isn't that bad, people get used to it quick, but if you're really worried about losing that payroll $1, get a coffee service to install one of the instant machines. The one in our office has a large touch screen display with various size and strength settings, along with the ability to do everything from a standard drip to a cappuccino shot to a french vanilla whatever. It's great.
Posts
I'm done. Thanks guys. I quit programming.
I can't possibly do better than that.
If I was told, I forgot, or don't understand.
I think this is the issue, he talks about the 12 ways you could do something. Some of which I look at and say, why in the world would you do that? It is frustrating, because while I could use a sledge hammer to pound a nail into the wall of my house, I have a good chance I will screw it up, and should use a tool more suited.
Thanks for the help though, I will have to try out this dynamic array stuff now. Thankfully the homework got pushed back to being due on the 28th. Oh, and if people wonder, no I did not post the specific assignment on purpose. I want help with things I don't understand, but I would like to tackle the main part myself.
This is usually a very good thing.
Doesn't help if it isn't explained well, though.
Also I took theoretical computer science at university, so I'm obviously biased there. We were all about building our own data structures/algorithms instead of using whatever the languages/libraries come with. Doesn't mean I still do it in my day-to-day.
Does UI fall under this? I've seen polling in stuff like GTK.
Corollary
When you are looking at the code for a low latency pricefeed handler that is using kernel bypass network cards, do not go through and just replace the Sleep(0) calls with Sleep(1) or Thread.Yield calls if you don't understand the differences between all those calls.
I guess I can't argue there. I think the frustration comes from the two widely different teacher approaches. The second teacher putting up 3 ways in rapid succession with little explanation of why you would do any of them is confusing to me. Lets see if I can say this right.
You can do this
or
The third way had more *'s in it, and I would have to dig through my notes. I could have gotten any of these wrong, but I know he showed three ways for the exact same thing. And left it at, it is your decision as a developer to choose what to use. But than requires certain things on assignments. So I think I got that right, but I hope anyone who knows c++ understands I'm trying to point out you can use a * or a -> to dereference. Why would I do one over the other? Style? What does the industry use? If I get someone else's code I could end up with anything I guess.
Maybe I'm just stubborn and hate doing things different that I have done on my own coding time. As if left alone, I can get a program to do exactly what it should, it just might not look the same under the hood.
But, the teacher's not wrong here, he should have explained which ones get used when, but it is important to know that the constructs are equivalent
It's trolls all the way down.
If the project / company doesn't have strict coding styles expect to see both mixed together.
C++ is a language (and it is not unique in this trait) where there's about a million ways to do anything, including really basic tasks, such as calling a member variable in a struct, as you've just demonstrated.
Do NOT concern yourself with which is best, just roll with it. Professors do confusing crap sometimes because they're trying to expose you to as many elements of the language as possible. I suspect your professor is not trying to teach you how to engineer software, he is trying to teach you how to read and write C++, and those two goals are NOT on the same path at all. One requires you to fabricate a bunch of examples so you can quickly make it through a bunch of unrelated features, one requires you to slowly and steadily introduce problems to be solved with familiar tools.
If you're learning C++ right now, it's not the time to think "which of these is better?" It's time to take stock and learn as much about the different things you're being exposed to as possible. Think about them, but don't stress out that you're maybe using the wrong tool for the job on your homework: of course you are. And you will be for the entire class. Then you'll take a class that asks you to do things right and you'll start putting your tools to good use.
.
?:
::
.*
Yes, you can overload *, ->, & to make one object pretend to be another completely different object in every way (smart pointers!). Or three completely different objects of different types!
https://www.codeschool.com/pluralsight
In general, yes, because UI is a great example for event driven programming - your buttons don't do anything until a user gives you a click on them (or mouse hovers). Your data grid doesn't update until it's got new data...
I'm sure there's some edge cases where polling is the least bad choice out of all choices, but in general, please stop with the polling.
Interesting tidbit:
Did you know, you can turn standard input into an event driven model? None of this cin.get() business.
POSIX: Use ye classic select() call
Win32: GetStdHandle(), WaitFor*Objects(), and ReadConsoleInput() (can also give you mouse events as well, or you can just filter them out).
(I mean, seriously guys. Da fuq are you computing while the game is paused?)
Sometimes, I'm glad that we haven't really figured out how to do multithreaded programs, cuz then X-Com will churn at 800% CPU when paused.
D'oh, I was wrong. They're not all free. That's annoying.
That's generally a result of the standard game loop being
for(;;) {
ProcessInput();
ProcessPhysics();
Draw();
}
Though, even when paused it likely needs to redraw the screen unless the image is completely static
Things like network or input will likely sit idle most of the time.
Ah. In most languages, there are two main areas of memory*, the "stack" and the "heap".
On modern Windows apps, your stack** is about 1Mb by default. Your potential heap size is a smidge short of 2Gb on 32-bit Windows***, and some large ridiculous number on 64-bit versions of Windows.
So you can appreciate that if you wanted some large data structures (e.g. things that are, say, 10Mb), you would not be able to fit them into the stack - you would have to allocate those in the heap.
So why are the stack and heap two different areas of memory, and such different sizes? Because of their purpose.
The stack is where your functions put their variables. Every time you call a function and it instantiates a variable, that's put on the stack. ****
For example:
void Example(); int main( int argc, char *argv[] ) { int firstVariable; // At this point, the stack looks like: // firstVariable // [bottom of stack] int secondVariable; // At this point, the stack looks like: // secondVariable // firstVariable // [bottom of stack] int thirdVariable; // At this point, the stack looks like: // thirdVariable // secondVariable // firstVariable // [bottom of stack] Example(); // After the function call, the stack looks like it was before the call: // thirdVariable // secondVariable // firstVariable // [bottom of stack] } void Example() { // At this point, the stack looks like: // call-from-main-to-Example() // thirdVariable // secondVariable // firstVariable // [bottom of stack] int fizz; // At this point, the stack looks like: // fizz // call-from-main-to-Example() // thirdVariable // secondVariable // firstVariable // [bottom of stack] int buzz; // At this point, the stack looks like: // buzz // fizz // call-from-main-to-Example() // thirdVariable // secondVariable // firstVariable // [bottom of stack] // When any function exits, the stack is cleaned up back to where the call occurred // In this case, fizz and buzz are both removed from the stack and no longer valid to use }You might not have realised it, but you've probably already encountered the term "stack" inadvertently.
For example, the term "stack overflow" occurs when you've called too many functions, and you're using up more memory than the stack has available (typically when you use recursion).
When you're debugging using Visual Studio (with breakpoints, and stepping into functions etc), you may have noticed the "call stack" window (if not, look at the menu Debug -> Windows -> Call stack - this lists the function calls on the stack).
So, in short, whenever you instantiate variables in a function, you're putting them on the stack. So when programmers say, "It's on the stack", it's not some super secret jargon or anything, it's... well, literally a variable that's been put on the stack.
Now, you might have noticed a few things:
1.) Stack variables are cleaned up at the end of their function/scope
2.) Stack space is limited compared to heap space (Mb vs Gb, or more in a 64-bit OS!)
3.) In current C++, variables that are to be allocated on the stack must have a size that is known at compile time (so no dynamically sized arrays)
So this is where the "heap" comes in:
1.) If you want a variable to outlive the end of the function, then instead of allocating from the stack, you must allocate from the heap.
2.) If you want to allocate large blocks of memory, because the heap typically has so much more memory, you typically allocate from the heap.
3.) If you want to allocate memory whose size is determined at run time, you'll need to allocate from the heap.
4.) Heap allocated variables must be cleaned up by code - unlike stack variables which implicitly get cleaned up at the end of their function/scope.
The heap is basically a big pile of available memory that the OS provides for you to use as you see fit.
There are many ways to allocate memory from the heap - the classic C "malloc()", C++ "new/new[]", OS specific functions - but the most important thing is that you must use the clean up function that matches your allocation method. For example, if you used "malloc()" to allocate memory, then you must use "free()" to deallocate it. If you used "new", then you must use "delete". If you used "new[]", then "delete[]". You cannot mix and match the various methods - think of it as each allocation having its own bookkeeping, and using the wrong clean up function screws up the bookkeeping something fierce.
In a non-trivial program, you will see variables allocated on both the stack and the heap, as well as variables that can be allocated on the stack and implicitly make use of the heap (std::vector, std::string).
So technically, what I've told you about the heap and stack has a bunch of exceptions - but in general, it's true enough to hopefully aid in understanding wtf in going on.
* In practice, your operating system/application/system may give you more 'types' of memory (e.g. memory mapped I/O, memory mapped files, hardware/peripheral memory, etc...), but ignore those for now.
** Per thread that you run.
*** By default, although this can be adjusted to about 3Gb if you want to shoot your customers in the foot.
**** Technically not always true in practice, but again, true enough when you're learning.
well.... you could get around that by using alloca and new placement
but that arguably doesn't count as "current C++" since alloca isn't really a standard thing
and I'm also pretty sure that means your destructor wouldn't get called for you
so I guess it's basically something you shouldn't normally be doing anyway
pretend I didn't say anything, is what I'm saying
On that note, here's a humble bundle-style deal for a bunch of intro courses to backend stuff - Ruby, Python, PHP.
https://stacksocial.com/sales/python-programming-for-beginners
It's at $9.48 average to get all eight courses at the moment.
If it's a web client then you want to use socket.io and push semantics on the client side. Though I too don't really know what you do with server stuff - you're kind of stuck to some sort of polling the database unless the other components can emit events.
They are opting for a drip machine but the problem is that people don't know how to make coffee to save their lives and we run the issue of wasting a bunch.
That seems dumb. What's going to end up happening is everyone is going to buy their own for their desk.
You should all get together and ask them to put it back in, and just provide your own kcups.
Well k-cups in general are a terrible way to do coffee because of waste, even in a home setting.
But better to do that then waste time for people getting pissed and antsy waiting for a new batch to be brewed, then getting more pissed because someone fucked it up, or made it too strong, or whatever.
25 cents in plastic waste might be better than $1 in payroll waste.
For my home setting:
For the office, brewing a pot isn't that bad, people get used to it quick, but if you're really worried about losing that payroll $1, get a coffee service to install one of the instant machines. The one in our office has a large touch screen display with various size and strength settings, along with the ability to do everything from a standard drip to a cappuccino shot to a french vanilla whatever. It's great.