This is reminiscent of the "negative billing" scams, whee if you don't opt out, you're automatically going to be subscribed for $EXTRA_CRAP_SERVICE_I_DONT_WANT at $X_MORE_PER_MONTH.
Because I can keep track of my memory allocations and frees. I learned long ago, the hard way, to make sure my mallocs match up with my frees, and to make sure I knew who "owns" what.
And sometimes I just like the idea of being able to take a nice chunk of ram, and sometimes look at it as a series of raw bytes, and sometimes as an array, and sometimes as something else. Back when I was writing assembler, everything was just memory anyways:-)
In comparison, std::aut_ptr sucks. For me. YMMV, and you're welcome to your opinion. I'm just saying the "textus receptus" that the STL is the greatest thing since sliced bread, has resulted in the dumbing down of a certain species of programmers, who can use the stl but are lost without it.
smart pointers, weak pointers, etc., bring their own problems. Just keep track of it in the first place. Design for it. Account for it. Test for it. You're going to need to anyway, so why not keep the code simple...
There are plenty of times when the stl simply isn't needed. People will drag the whole thing in because they want to parse out an initialization file. How dumb can you get? If you can't write a simple ini file parser yourself, you should go back to school. This is one of those things that can be done in a few lines of c, never mind c++.
2 years ago, when I argued that we should remove it because it was still a performance hit. Proved it, removed it, converted the code to standard c99, not c++.
And if, for some strange reason, you want to refer to inexistent indexes, std::map::operator[] will allow you to do that, and create a default value under that index when you first access it.
... and having that ability that adds checking overhead on EVERY access. Want to try again?
I used to share this sentiment. And then I met their majority C equivalent, the same people who only know C but cannot program in C either.
I certainly won't disagree with you there... the only thing that helps is curiosity. Curious people, with any language, will take the time to see what works, to test it themselves, to break things and find out why it broke, and to challenge presumptions.
Give two people a compiler and 10 years - the curious person will be the one you want if you need any sort of optimization, because they'll know not only what works but why - and also be ready to try something different because times change since they last hit the text books.
Why not test it yourself? I did, but I've come to realize that the only way for people to actually believe it is to get off their behinds and test it for themselves. Otherwise, it's too easy to dismiss.
It's the same as everyone who claims java is "almost as fast as c" when in a lot of cases it is piss-poor. Test it.
variable-length arrays were a surprise to me too. I had been looking for the quickest way to do an in-memory search to find keys so I could look up the associated pointer, and as we all know, c doesn't have variable-length arrays... but c99 does. Use -std=c99 on the compiler line.
What this means is that you can treat your chunk of ram as contiguous, and realloc to grow it, and if you try to do an array access past the "old" bound, you no longer throw an exception. So your initial array allocation (in my case, 1024 elements) could grown (again, in my case, to a million) and still work.
Doing a bsearch on that is dirt quick. Being able to refer to any element, even those beyond the original length, using standard array notation, is just SO nice.
A variable length array, which is a C99 feature, is an array of automatic storage duration whose length is determined at run time.
If the size of the array is indicated by * instead of an expression, the variable length array is considered to be of unspecified size. Such arrays are considered complete types, but can only be used in declarations of function prototype scope.
A variable length array and a pointer to a variable length array are considered variably modified types. Declarations of variably modified types must be at either block scope or function prototype scope. Array objects declared with the extern storage class specifier cannot be of variable length array type. Array objects declared with the static storage class specifier can be a pointer to a variable length array, but not an actual variable length array. The identifiers declared with a variably modified type must be ordinary identifiers and therefore cannot be members of structures or unions. A variable length array cannot be initialized.
A variable length array can be the operand of a sizeof expression. In this case, the operand is evaluated at run time, and the size is neither an integer constant nor a constant expression, even though the size of each instance of a variable array does not change during its lifetime.
A variable length array can be used in a typedef expression. The typedef name will have only block scope. The length of the array is fixed when the typedef name is defined, not each time it is used.
Now don't tell me that isn't sweet! For some algorithms, it's a real game-changer, making them so much simpler to implement - and explain to others - that you never want to go back.
It's not that simple. Several European countries have followed our lead, and if Facebook doesn't comply, they face sanctions - and as we've seen in the news lately, that includes having their plug pulled in various countries, which certainly will affect both their revenue and their valuation.
What's Facebook worth if Canada, Europe, and chunks of South America all pull the plug? Way less than half, because the "network effect" cuts both ways.
It opens the doors for competitors that have better privacy policies, and are available in more countries.
By the time they finish compiling, they'll be dead.
Templates look ugly for a reason. They are ugly.
They're a shortcut. Funny thing is, the same people who go all gaga over them go "OMG the pre-processor is the devil!" for those of us who make extensive use of the pre-processor.
We may have gained a lot in the last couple of decades, but those early Borland compilers (Turbo C, Turbo Pascal, Turbo Asm, Borland C++) were just so righteous!
Using STL frees you from having to do manual memory management
Here, let me fix that for you:
Using c++ might free you from having to do manual memory management - just make sure you type a free for every malloc, and that your free gets called when the object goes out of scope (usually in the destructor). Then as the stack pointer gets unwound, the destructor calls your free.
Have an explicit contract with any other objects or code that uses data this object has allocated - which you should be doing anyway or your code will be thrown out by the next person who has to maintain it.
Quite simply because STL is the embodiment of several decades of algorithms and data structures research work. In many cases, use of STL results in near optimal code. In raw C, you're left to yourself to write your own collections and algorithms. You have to try pretty hard to surpass the performance of STL. Do you want compiler developers to constantly reinventing wheels or actually improving the compiler?
Since this is Troll Tuesday I'll be blunt - that's absolute horsheshit!
In testing, performance can be 4x SLOWER with the stl than by using c99. Variable-length arrays combined with bsearch make for one of the fastest look-up "containers" going - way faster than any stl algorithm.
c++ has its uses. It has nice features. The stl, on the other hand, is visually offensive. I bought the hardcover TR1 spec, read it twice, and consider it a waste of time and money. For what most people need, if they can't write their own classes, there's enough generic code that they can modify to achieve their goals.
On top of which, object-oriented programming is a paradigm, not a language feature. You can do OOP in c just fine by passing an explicit "this" as the first parameter in any function you want to act like a method call. You can even do OOP in assembler - Borland had some nice material on that.
Use c++ for encapsulation, for references, for the syntactic sugar - but not because the stl will make it run faster - it won't.
You should have hired someone from 20 years ago. They would have told you the difference in encoding between a soft carriage return and a hard carriage return, and all the other old-time specs that made ASCII so great. and the encoding was simple enough to detect - either 7-bit clean or 8-bit.
Really? I can't think of many. The length of the screen would prohibit the use of simple rails that slide out of the body of the phone... they'd be much longer than the phone's width
The problem may also be with perl. Unicode support is not always as advertized. I've had to write code in c to remove some of the more exotic unicode characters that perl choked on.
Combine it with an expanded ansi screen driver (more color range) for nice color "text graphics", and the ability to switch the color palette to something that gets rid of that ugly cyan and magenta, and you're good to go.
But of course once you do that, it's "too" universal - there's no reason that people would prefer your version over anyone else's.
Re:It just proves today's Apple customers are chea
on
Why Apple Is So Sticky
·
· Score: 1
Of course it also works the other way around - once bitten, twice shy. People who haven't bought an iPhone have other options that are just as good, but less iApple-y, and people who found that most of the $100 of downloaded content is either crap, or something they can do without, there's a better version on the "other" platforms, or that it's just obsolete, will realize that their $100 "investment" is really only $20.
If you're relying on people not junking an "investment" that's worth less than $100 as the way to keep them tied to you, you're doomed to competitors offering something better for free.
Slashdot Mirror
It could be worse
'Jennifer' Usher, and Usher's journal. My own personal cyber-stalker :-)
This is reminiscent of the "negative billing" scams, whee if you don't opt out, you're automatically going to be subscribed for $EXTRA_CRAP_SERVICE_I_DONT_WANT at $X_MORE_PER_MONTH.
Seriously, Yahoo, sharing is not always a 'Good Thing' Some things are better kept private
And sometimes I just like the idea of being able to take a nice chunk of ram, and sometimes look at it as a series of raw bytes, and sometimes as an array, and sometimes as something else. Back when I was writing assembler, everything was just memory anyways :-)
In comparison, std::aut_ptr sucks. For me. YMMV, and you're welcome to your opinion. I'm just saying the "textus receptus" that the STL is the greatest thing since sliced bread, has resulted in the dumbing down of a certain species of programmers, who can use the stl but are lost without it.
smart pointers, weak pointers, etc., bring their own problems. Just keep track of it in the first place. Design for it. Account for it. Test for it. You're going to need to anyway, so why not keep the code simple ...
There are plenty of times when the stl simply isn't needed. People will drag the whole thing in because they want to parse out an initialization file. How dumb can you get? If you can't write a simple ini file parser yourself, you should go back to school. This is one of those things that can be done in a few lines of c, never mind c++.
2 years ago, when I argued that we should remove it because it was still a performance hit. Proved it, removed it, converted the code to standard c99, not c++.
Much faster.
I certainly won't disagree with you there ... the only thing that helps is curiosity. Curious people, with any language, will take the time to see what works, to test it themselves, to break things and find out why it broke, and to challenge presumptions.
Give two people a compiler and 10 years - the curious person will be the one you want if you need any sort of optimization, because they'll know not only what works but why - and also be ready to try something different because times change since they last hit the text books.
Why not test it yourself? I did, but I've come to realize that the only way for people to actually believe it is to get off their behinds and test it for themselves. Otherwise, it's too easy to dismiss.
It's the same as everyone who claims java is "almost as fast as c" when in a lot of cases it is piss-poor. Test it.
The stl has overhead, plain and simple. I've tested it and seen the difference. Have you? It's why the first thing I do with stl code is replace it.
variable-length arrays were a surprise to me too. I had been looking for the quickest way to do an in-memory search to find keys so I could look up the associated pointer, and as we all know, c doesn't have variable-length arrays ... but c99 does. Use -std=c99 on the compiler line.
What this means is that you can treat your chunk of ram as contiguous, and realloc to grow it, and if you try to do an array access past the "old" bound, you no longer throw an exception. So your initial array allocation (in my case, 1024 elements) could grown (again, in my case, to a million) and still work.
Doing a bsearch on that is dirt quick. Being able to refer to any element, even those beyond the original length, using standard array notation, is just SO nice.
http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlcpp8a.doc/language/ref/variable_length_arrays.htm
Now don't tell me that isn't sweet! For some algorithms, it's a real game-changer, making them so much simpler to implement - and explain to others - that you never want to go back.
It's not that simple. Several European countries have followed our lead, and if Facebook doesn't comply, they face sanctions - and as we've seen in the news lately, that includes having their plug pulled in various countries, which certainly will affect both their revenue and their valuation.
What's Facebook worth if Canada, Europe, and chunks of South America all pull the plug? Way less than half, because the "network effect" cuts both ways.
It opens the doors for competitors that have better privacy policies, and are available in more countries.
Geek insult - "go template yourself."
By the time they finish compiling, they'll be dead.
Templates look ugly for a reason. They are ugly.
They're a shortcut. Funny thing is, the same people who go all gaga over them go "OMG the pre-processor is the devil!" for those of us who make extensive use of the pre-processor.
We may have gained a lot in the last couple of decades, but those early Borland compilers (Turbo C, Turbo Pascal, Turbo Asm, Borland C++) were just so righteous!
c++ programmers who don't know c all that well (and there are LOTS of them - maybe even the majority) are not the best.
Here, let me fix that for you:
Using c++ might free you from having to do manual memory management - just make sure you type a free for every malloc, and that your free gets called when the object goes out of scope (usually in the destructor). Then as the stack pointer gets unwound, the destructor calls your free.
Have an explicit contract with any other objects or code that uses data this object has allocated - which you should be doing anyway or your code will be thrown out by the next person who has to maintain it.
Since this is Troll Tuesday I'll be blunt - that's absolute horsheshit!
In testing, performance can be 4x SLOWER with the stl than by using c99. Variable-length arrays combined with bsearch make for one of the fastest look-up "containers" going - way faster than any stl algorithm.
c++ has its uses. It has nice features. The stl, on the other hand, is visually offensive. I bought the hardcover TR1 spec, read it twice, and consider it a waste of time and money. For what most people need, if they can't write their own classes, there's enough generic code that they can modify to achieve their goals.
On top of which, object-oriented programming is a paradigm, not a language feature. You can do OOP in c just fine by passing an explicit "this" as the first parameter in any function you want to act like a method call. You can even do OOP in assembler - Borland had some nice material on that.
Use c++ for encapsulation, for references, for the syntactic sugar - but not because the stl will make it run faster - it won't.
You should have hired someone from 20 years ago. They would have told you the difference in encoding between a soft carriage return and a hard carriage return, and all the other old-time specs that made ASCII so great. and the encoding was simple enough to detect - either 7-bit clean or 8-bit.
Three off the top of my head:
The problem may also be with perl. Unicode support is not always as advertized. I've had to write code in c to remove some of the more exotic unicode characters that perl choked on.
Turn your laptop sideways and rotate the on-screen display. Today's wide-screen laptops have to be better at something!
It's called ASCII. And it's great!
Combine it with an expanded ansi screen driver (more color range) for nice color "text graphics", and the ability to switch the color palette to something that gets rid of that ugly cyan and magenta, and you're good to go.
But of course once you do that, it's "too" universal - there's no reason that people would prefer your version over anyone else's.
Of course it also works the other way around - once bitten, twice shy. People who haven't bought an iPhone have other options that are just as good, but less iApple-y, and people who found that most of the $100 of downloaded content is either crap, or something they can do without, there's a better version on the "other" platforms, or that it's just obsolete, will realize that their $100 "investment" is really only $20.
If you're relying on people not junking an "investment" that's worth less than $100 as the way to keep them tied to you, you're doomed to competitors offering something better for free.
What the heck, do it anyway - the USPTO doesn't give a **** about prior art - they're like Mikey, they'll eat anything you stick in front of them! After all, they patented the comb-over., the cry-no-more that gags a baby, human car wash, pet petter, boob tube and insect balls
No, but in Canada they can call it the "eh pad", eh?