I too have a mother... And now a wife. I say this to state that I'm not oblivious. I just have my limits to spoon feeding. I tend to teach to fish, not give away the fish. True, this sometimes isn't the easiest road for me, but done just right, with care and love, it works better than repeating the same thing over and over and over and over.
Bottom line, people who are unwilling to learn how to do the things they want to do, are making you do it for them. Most know not to ask me questions to which they don't want answers since often it's a lesson, and I have no problem with that. They wrongly expect things to be simple. I make sure they know it isn't without some sort of education in the matter.
I'm aware I sound rather harsh and unforgiving in these posts. I assure you that on a personal level (the level at which I'm engaged when helping someone like my wife) I'm not all that awful to get along with. As I hope you know, these are my views and opinions. Real life tends to find a middle ground.
First, the terms aren't made up, they are just simple English words that are descriptive of what one would actually see on the screen (you can replace "start" with "windows button" if you wish -- it won't make any difference, you'll still have to say "it's that thing in the bottom left corner," -- the term doesn't matter). It is beyond me what you would think a bar is in the context of looking at a computer screen, which plainly shows a bar running across the entire bottom edge. Even more frustrating is that it's the only thing that looks like any sort of "bar". Second, the same people that have problem understanding plain English are infinitely hopeless in understanding the actual UI vocabulary we have invented.
I present to you my reasoning behind my original comment: It does NOT matter which term you will actually use when speaking to such a person. They will not parse any of them at all. The biggest problem is that it's all a metaphor, and at best, this metaphor is a poor one.
They will. It is inevitable that the one who sees reality before that reality is here will suffer most in his lifetime. The realist will not tell you what you want to hear. Only in retrospect is wisdom truly appreciated.
Then you are incompetent in simple English. It is the bar on which you find start. How is "bar" associated with "Start" confusing? What could someone possibly think when they hear that combination of words other than the frigging 'bar' on which you find 'start.'
Only if you purposely misinterpret and misrepresent my statement. I did not ask you to stop anything, or for anyone to *do* anything. I said that it is ridiculous to do it. You can try to tell me what to think, sure. I will just ignore you. That's all you should have ever taken away from that. Building up some straw-man about liberal thinking just severs to muddy the waters for those that are easily distracted by nonsense.
who are you to decide what's right and what's wrong
I think a better, and more appropriate question is, "Who are THEY to decide what's right and what's wrong?"
Yes, it's their country, and it's their laws, sure, I give them that. But that does not stipulate that their reach is endless and that there's no point in which no one should give a shit what they think is right. Censorship is one such item that is completely beyond their reach. It is ridiculous for any one person to tell what another person should or should not watch/hear/think. It's stupid and it's DOOMED to fail all the time, and it does, and we see it time and time again. Stupid. It's stupid to insist that it's necessary for anything. It's stupid to think to yourself that it's anything but another example of "do it my way or else!" that we all got to love in our kindergarten days.
My point was that "reparations" are not a solution. As the saying goes, give them a finger, they will bite the hand off.
Displacing millions of people again is not a solution. That will still leave millions of people quite pissed and potent to violence.
The only viable next step is to put down the weapons and co-exist. Period.
I'm quite sure that only one side is ready for it. Asking that side to just give everything up, get up and move because their grandparents may have wronged or did something to their own grandparents is naive, childish, and down right primitive, as it goes against everything a civilized thinking human being would want. Its that tribal way of thinking that is tearing the middle east apart. The sad thing is, is that tribal conflict isn't limited to Israel, as Arabs, in general, have a hard time getting along with other Arabs on many other issues. It's not exactly unheard of them massacring each other just the same.
I will admit to being a self proclaimed C++ enthusiast. But I've never gotten that sense from professional C++ enthusiasts. (I'm speaking about people who enjoy the feel of C++ not the people who have to use it because of some external influence and would jump ship if they could). The sense I did get though is that the farther you are on the learning curve of the language, the more you start thinking in terms of "code generation" (realized by template meta programming techniques). The best parallel I found for this in the C community is the lex/yacc code generators. I think this happens because often there are better ways to express the problem domain than the traditioal "step by step, this is how the computer will do it" way of general programming languages such as C. C++ just takes this mode of thinking a step further by providing the tools necessary to augment generating C type code.
Things like methds and overloading are done by passing function pointers around as data.
In assembler, if I understand correctly, the only difference between code and data is the policy set by the OS on that page of memory...
Hell, even if what I just said is blatantly wrong, have you ever seen an apache module? C is not an OO language what so ever (doesn't prevent the techniques, it simply doesn't help at all), and yet function pointers are passed around like there's no tomorrow. I suspect that this quite common in the C world.
My specific point is this: Every single paradigm and language can be viewed as 'mixing them up' based on how you are presenting the concept (your reference to the implementation details of a compiler). That doesn't make your point invalid, it's just an illustration that it's not really necessary to emphasize that it happens under the hood. It muddied the water a bit even, since you're implying that there are languages/paradigms that do not do this at all.
WTF are you talking about??? In my statistically insignificant personal experience that hasn't been the case for nearly 3 years at least. What on earth are you installing? Or did you stray too far from the bridge?
The OS is FREE in that you have FREEDOM to do with it as you please (almost, since you cannot remove that FREEDOM if you decide to give OS to someone else down the line).
Because reparations have worked SOOOOO well in the past there. Are you failing to note that every time that has been tried, these "peace loving" assholes started killing even more?? When would you say "enough is enough"?
What you've described has little to do with the "zero overhead excuse" that I had made for _C++_ (not C). You're describing decisions made on the computational model that is meant to be an abstraction over assembly. The compiler isn't checking this for C because of the mapping these constructs have to the hardware. Registers, in of themselves, have no sign. The meaning of a sign bit is determined by the operations applied. The flexibility allows one to use C (and C++) to generate the proper assembly instructions of their choice by carefully controlling the operations applied.
That said, in C++ the use of the unsigned variants should be limited in the first place, and isolated to libraries, just like pointers. An exception being when you're dealing with strictly binary data, and all you are concerned with are bit patterns. In that case, use only unsigned and refrain from doing any unrelated to binary math operations.
Not only will you help keep your concerns separate, you will also shoot yourself in the foot less. On top of that you won't cripple the expressive power of the language, making it a lesser tool for everyone.
This isn't at all contrary to the zero overhead philosophy. You can get what you're talking about, and it does not have to be part of the language. You're talking about run-time routines. Those can be injected quite easily using that very same language (C++).
The problem is that it is against the philosophy of the language. That being "Zero overhead: If you don't use it, you don't pay for it". If that was not in place, the language would not be in use today. The C programmers were the ones to pick it up, and they wouldn't have had it not been for this strict philosophy.
For the life of me I can't understand why you'd *want* to do that. Just to prove a point? You're deliberately pushing a round peg into a square hole here.
That is simply not true. Flexible use of pointers allows for very advanced in scope libraries. I'm arguing that the restriction should not come from the language, but from discipline. Application code should never use a raw pointer (other than converting a const char* literal to an std::string). We didn't stop building bridges when someone fell off. We put guard rails and relied on people's common sense. This never deterred a determined jumper.
While I agree with your sentiment, I whole hardheartedly disagree with the premise that code is anything like mathematical formula. On the surface of it, code is based on mathematical notation, but it expresses concepts in a very different context. It is like the difference between physics and architecture. Physics are physics, you can figure them out, or not comprehend them, but they are what they are. Architecture is based on physics in a very real sense. But you can't "figure out" architecture, its a matter of taste combined with what works, mixed in with tricks of the trade learned so far along with "accepted (in your area) best practices".
You do realize that the only relevant piece of information are only in the last 2 lines?
"/usr/include/c++/4.3/bits/stl_map.h:92: instantiated from here../test.cpp:11: error: ‘testObj::~testObj()’ is private/usr/include/c++/4.3/bits/stl_pair.h:73: error: within this context/usr/include/c++/4.3/ext/new_allocator.h: In member function ‘void __gnu_cxx::new_allocator::destroy(_Tp*) [with _Tp = std::pair]’:/usr/include/c++/4.3/ext/new_allocator.h:118: note: synthesized method ‘std::pair::~pair()’ first required here"
You'd think, after seeing this happen around 5 times you'd know where to start looking, geez.
On a more to the point note: Templates, being what they are, can either allow what they allow, or give better error messages, but not both. Having a construct that can only be validated during instantiation is a double edge sword. Powerful if you can tame the beast. Dangerous and difficult if you cannot.
Concepts would have alleviated some of these issues at the price of tightening the requirement set, presenting its own set of trade offs.
Slashdot Mirror
I too have a mother... And now a wife. I say this to state that I'm not oblivious. I just have my limits to spoon feeding. I tend to teach to fish, not give away the fish. True, this sometimes isn't the easiest road for me, but done just right, with care and love, it works better than repeating the same thing over and over and over and over.
Bottom line, people who are unwilling to learn how to do the things they want to do, are making you do it for them. Most know not to ask me questions to which they don't want answers since often it's a lesson, and I have no problem with that. They wrongly expect things to be simple. I make sure they know it isn't without some sort of education in the matter.
I'm aware I sound rather harsh and unforgiving in these posts. I assure you that on a personal level (the level at which I'm engaged when helping someone like my wife) I'm not all that awful to get along with. As I hope you know, these are my views and opinions. Real life tends to find a middle ground.
No I'm not :). At least that isn't my only reason.
First, the terms aren't made up, they are just simple English words that are descriptive of what one would actually see on the screen (you can replace "start" with "windows button" if you wish -- it won't make any difference, you'll still have to say "it's that thing in the bottom left corner," -- the term doesn't matter). It is beyond me what you would think a bar is in the context of looking at a computer screen, which plainly shows a bar running across the entire bottom edge. Even more frustrating is that it's the only thing that looks like any sort of "bar". Second, the same people that have problem understanding plain English are infinitely hopeless in understanding the actual UI vocabulary we have invented.
I present to you my reasoning behind my original comment: It does NOT matter which term you will actually use when speaking to such a person. They will not parse any of them at all. The biggest problem is that it's all a metaphor, and at best, this metaphor is a poor one.
Yup :)
They will. It is inevitable that the one who sees reality before that reality is here will suffer most in his lifetime. The realist will not tell you what you want to hear. Only in retrospect is wisdom truly appreciated.
Then you are incompetent in simple English. It is the bar on which you find start. How is "bar" associated with "Start" confusing? What could someone possibly think when they hear that combination of words other than the frigging 'bar' on which you find 'start.'
Only if you purposely misinterpret and misrepresent my statement. I did not ask you to stop anything, or for anyone to *do* anything. I said that it is ridiculous to do it. You can try to tell me what to think, sure. I will just ignore you. That's all you should have ever taken away from that. Building up some straw-man about liberal thinking just severs to muddy the waters for those that are easily distracted by nonsense.
who are you to decide what's right and what's wrong
I think a better, and more appropriate question is, "Who are THEY to decide what's right and what's wrong?"
Yes, it's their country, and it's their laws, sure, I give them that. But that does not stipulate that their reach is endless and that there's no point in which no one should give a shit what they think is right. Censorship is one such item that is completely beyond their reach. It is ridiculous for any one person to tell what another person should or should not watch/hear/think. It's stupid and it's DOOMED to fail all the time, and it does, and we see it time and time again. Stupid. It's stupid to insist that it's necessary for anything. It's stupid to think to yourself that it's anything but another example of "do it my way or else!" that we all got to love in our kindergarten days.
My point was that "reparations" are not a solution. As the saying goes, give them a finger, they will bite the hand off.
Displacing millions of people again is not a solution. That will still leave millions of people quite pissed and potent to violence.
The only viable next step is to put down the weapons and co-exist. Period.
I'm quite sure that only one side is ready for it. Asking that side to just give everything up, get up and move because their grandparents may have wronged or did something to their own grandparents is naive, childish, and down right primitive, as it goes against everything a civilized thinking human being would want. Its that tribal way of thinking that is tearing the middle east apart. The sad thing is, is that tribal conflict isn't limited to Israel, as Arabs, in general, have a hard time getting along with other Arabs on many other issues. It's not exactly unheard of them massacring each other just the same.
I will admit to being a self proclaimed C++ enthusiast. But I've never gotten that sense from professional C++ enthusiasts. (I'm speaking about people who enjoy the feel of C++ not the people who have to use it because of some external influence and would jump ship if they could). The sense I did get though is that the farther you are on the learning curve of the language, the more you start thinking in terms of "code generation" (realized by template meta programming techniques). The best parallel I found for this in the C community is the lex/yacc code generators. I think this happens because often there are better ways to express the problem domain than the traditioal "step by step, this is how the computer will do it" way of general programming languages such as C. C++ just takes this mode of thinking a step further by providing the tools necessary to augment generating C type code.
Things like methds and overloading are done by passing function pointers around as data.
In assembler, if I understand correctly, the only difference between code and data is the policy set by the OS on that page of memory...
Hell, even if what I just said is blatantly wrong, have you ever seen an apache module? C is not an OO language what so ever (doesn't prevent the techniques, it simply doesn't help at all), and yet function pointers are passed around like there's no tomorrow. I suspect that this quite common in the C world.
My specific point is this: Every single paradigm and language can be viewed as 'mixing them up' based on how you are presenting the concept (your reference to the implementation details of a compiler). That doesn't make your point invalid, it's just an illustration that it's not really necessary to emphasize that it happens under the hood. It muddied the water a bit even, since you're implying that there are languages/paradigms that do not do this at all.
WTF are you talking about??? In my statistically insignificant personal experience that hasn't been the case for nearly 3 years at least. What on earth are you installing? Or did you stray too far from the bridge?
The OS is FREE in that you have FREEDOM to do with it as you please (almost, since you cannot remove that FREEDOM if you decide to give OS to someone else down the line).
Because reparations have worked SOOOOO well in the past there. Are you failing to note that every time that has been tried, these "peace loving" assholes started killing even more?? When would you say "enough is enough"?
This doesn't make it successful, now a whole bunch of people know he's full of shit.
augh... just augh.
My wife has a good 5 inches on me (height).
In what universe???
What you've described has little to do with the "zero overhead excuse" that I had made for _C++_ (not C). You're describing decisions made on the computational model that is meant to be an abstraction over assembly. The compiler isn't checking this for C because of the mapping these constructs have to the hardware. Registers, in of themselves, have no sign. The meaning of a sign bit is determined by the operations applied. The flexibility allows one to use C (and C++) to generate the proper assembly instructions of their choice by carefully controlling the operations applied.
That said, in C++ the use of the unsigned variants should be limited in the first place, and isolated to libraries, just like pointers. An exception being when you're dealing with strictly binary data, and all you are concerned with are bit patterns. In that case, use only unsigned and refrain from doing any unrelated to binary math operations.
Not only will you help keep your concerns separate, you will also shoot yourself in the foot less. On top of that you won't cripple the expressive power of the language, making it a lesser tool for everyone.
This isn't at all contrary to the zero overhead philosophy. You can get what you're talking about, and it does not have to be part of the language. You're talking about run-time routines. Those can be injected quite easily using that very same language (C++).
The problem is that it is against the philosophy of the language. That being "Zero overhead: If you don't use it, you don't pay for it". If that was not in place, the language would not be in use today. The C programmers were the ones to pick it up, and they wouldn't have had it not been for this strict philosophy.
For the life of me I can't understand why you'd *want* to do that. Just to prove a point? You're deliberately pushing a round peg into a square hole here.
That is simply not true. Flexible use of pointers allows for very advanced in scope libraries. I'm arguing that the restriction should not come from the language, but from discipline. Application code should never use a raw pointer (other than converting a const char* literal to an std::string). We didn't stop building bridges when someone fell off. We put guard rails and relied on people's common sense. This never deterred a determined jumper.
So people are using a tool (IDE) that isn't capable of presenting the information to the user that is clearly there? Perhaps a new tool is in order?
While I agree with your sentiment, I whole hardheartedly disagree with the premise that code is anything like mathematical formula. On the surface of it, code is based on mathematical notation, but it expresses concepts in a very different context. It is like the difference between physics and architecture. Physics are physics, you can figure them out, or not comprehend them, but they are what they are. Architecture is based on physics in a very real sense. But you can't "figure out" architecture, its a matter of taste combined with what works, mixed in with tricks of the trade learned so far along with "accepted (in your area) best practices".
"/usr/include/c++/4.3/bits/stl_map.h:92: instantiated from here ../test.cpp:11: error: ‘testObj::~testObj()’ is private /usr/include/c++/4.3/bits/stl_pair.h:73: error: within this context /usr/include/c++/4.3/ext/new_allocator.h: In member function ‘void __gnu_cxx::new_allocator::destroy(_Tp*) [with _Tp = std::pair]’: /usr/include/c++/4.3/ext/new_allocator.h:118: note: synthesized method ‘std::pair::~pair()’ first required here"
You'd think, after seeing this happen around 5 times you'd know where to start looking, geez.
On a more to the point note: Templates, being what they are, can either allow what they allow, or give better error messages, but not both. Having a construct that can only be validated during instantiation is a double edge sword. Powerful if you can tame the beast. Dangerous and difficult if you cannot.
Concepts would have alleviated some of these issues at the price of tightening the requirement set, presenting its own set of trade offs.