As someone else pointed out with a slightly tongue in cheek quote, if you aren't totally on the ball you end up creating unexpected copies of your objects.
I've been programming in C++ daily for years, and I've never
seen this bug. Not even in beginner's code.
I've seen void f(string s); when void f(const string& s);
would have been more efficient, but never an actual harmful copy.
If I don't want a type to be copyable, I forbid copying.
This is just silly, you can write C programs in C++, and since the back end is usually shared you will end up with identical code. At most you can say that some of the C99 performance features have not yet found their way into C++, but that would go the opposite way of what you suggest. They used to be equally fast, but it has now (temporarily) become possible to write faster code in C.
The idea in this case is, I guess, to compare the idiomatic solution to
a problem in C to the idiomatic solution in C++.
std::copy versus memcpy(),
iostreams versus fgets() and so on.
Anything else would be pretty pointless.
Servlets compared to CGI
Have no idea.
All I know is, web interfaces (like the one I'm typing this into) are slow and brittle.
Not necessarily , all I'm saying is that the STL can introduce bugs of its own that can be a lot harder to find than old style buffer overruns so its not a solution that will get rid of obscure coding (as opposed to logic) bugs.
STL doesn't introduce bugs, you do.
Never place objects which don't meet the minimum requirements for being placed in STL containers into STL containers, and you'll be fine.
(If we're talking buffer overruns, aren't we talking about strings and std::vector, anyway?)
Today, what some programmers do is to do FREE(lp); where FREE() is a macro or something that does if (a) { free(a); a=NULL; }. This prevents double frees, and ensures that future use of the pointer will predictably die with a null pointer exception.
Yeah, right. How often do you think a is the only
reference to that memory in the program? If you do have a problem,
it's likely to be in some completely different part of the code, where
there's an alias for a, with a completely different lifetime.
Nothing you can do to a will change that.
(And really, what's the if(a) part all about?
free(3) has accepted NULL pointers for the last twenty years or so.)
Re:Unix console text editors are annoying
on
The Birth of vi
·
· Score: 3, Interesting
Another problem with vi (and maybe others) is their growing dependancies on system libraries. I recently tried and install of vi which complained of a gtk dependancy; sheesh. This one [0] is from an embedded arm system (debian). Why do I need gpm when running vi?
You mean libgpmg1. That's not related to GTK in any way (thank god).
Personally, I am happy with nvi(1), "a 'bug-for-bug compatible' clone of the original BSD vi". No strange dependencies there.
But then I use emacs for all longer editing sessions.
That depends on what market we are talking about. Open sourcing Java will make a MASSIVE difference in terms of Java's appeal to the open source development community. Whether this translates to more Java software or not I don't know [...]
I doubt it.
There's an awful lot of Kool-Aid you have to drink to become a Java programmer.
Java isn't a language, it's a family of platforms.
For a Unix person like myself, something like Python will always win over Java,
precisely because it doesn't attempt to be a platform.
In fact, Python tries to provide the Unix APIs in a convenient and
straightforward way. The same goes for all relevant task-specific libraries.
(And if you don't like Python, there are a handful of other popular, free
languages at an abstraction level higher than Java,
which share the same platform-agnostic approach.)
And meanwhile, Java is stuck on its own little island,
and the beaches and the surfing aren't better there than anywhere else.
I built an Athlon64 machine a while back and put Debian Etch on it, and it's awesome.
You have to use the testing or unstable branches to get AMD64 support until the 4.0 release, but testing (Etch) has been working perfectly for me.
Debian Sarge for x86_64 is perfectly well supported;
you don't have to run testing/unstable.
With very little work, I've even been able to get the few 32-bit apps I need to work. Without a chroot I have Opera (with Flash), the 32-bit proprietary video codecs, and a few others working perfectly.
Without a chroot? How?
Opera is my only problem -- I don't want to bother with chroot environments, so
I'm stuck with the statically linked 32-bit version.
The Opera people don't make it a priority to release a 64-bit version, unfortunately.
The title should be 10 Good Unix Hints. Not Habits.
Yes -- and habits is what people desperately need.
The people I know primarily need three habits:
RTFM when they don't understand something;
adjusting their behavior based on the FM;
and managing their use of the current directory
(i.e. you don't have to cd into a directory to use a file which lives there).
When I first got into programming in 1972, I never heard of a "Hello, World" program. In the 70s, I suspect it was more common to write a first program that printed out your name.
The classic first BASIC program on micros in the 1980s, too.
I wonder when they originated.
Or where. Things were already fragmented back then.
In the Unix community, maybe?
And yes, the Wikipedia article blames Kernighan, in 1972.
After all, if you know how to program, then the language with which you program doesn't matter. I would argue that if you cannot learn a new programming language for base use in, say, a week, you don't know how to program. (By base use I mean the basics - not the little tricky subtleties that every language has.)
And you obviously don't mean the underlying concepts
that make any important language unique and useful, either.
I recognize that there are more useful skills than knowing a language,
and that you shouldn't learn The One Language and then live out your career
in fear that it will become a useless skill...
But I can guarantee that even with a small, elegant and extremely
high-level language (say, Python) you will write significantly better programs after
eighteen months than you did at twelve months.
Generally speaking, bloat is a consequence of (poorly used) OO languages, bringing in tons of code to do one or two silly things out of a module. A basic C program compiles to a fews tens of K (or less), a basic C++ program compiles to many megabytes, and it just gets worse from there. These things can be managed, but few people bother.
I can't agree. You might bring in some extra code with iostreams and with the templated
containers, but not a lot -- and you do benefit from it.
If we're speaking bloat, I think the two major factors are:
solving simple problems in extremely convoluted, overly generic ways
solving problems that aren't that important to the users,
i.e. adding bells and whistles
Only the first of them is related to object-oriented programming,
and not all of us are afflicted by that kind of thinking.
Unless things have changed in the council over the last 10 years I would imagine they are just as incompetent at anything they turn there hand to. I think it was only last week that we heard the manager of the streetlighting division...
"Panic on the streets of Birmingham", eh?
Great, now I'll be humming Smiths songs for the rest of the evening.
Really, if all you want is your customers or prospects be able to reach you through a website, got yourself a contact form.. No way for a harvester to get your email address that way, and people usually don't mind filling in a contact form..
I mind.
Offering a contact form and nothing else tells me
that they aren't interested in me being able to
maintain my normal email workflow,
keep a copy of the message I sent,
Cc people,
being able to track the mail by Message-ID,
being able to sign the message, and so on.
Offering a web form and an obfuscated mail address and an apology
is enough to keep me happy though.
You now have
Transistors;
Digital Logic;
Machine Code;
Compilers;
C Code Family;
Dynamic Languages / Visual Languages;
What next...
In 20 years time nobody will be pissing around with C code or Java or or Lisp ( ok maybe lisp) except for historical/maintaince reasons.
All those things were available 20--35 years ago.
If nothing revolutionary has happened 1970--2006,
what makes you so sure it it will happen in 2006--2025?
Fred Brooks' "No Silver Bullet" theory seems as plausible as ever, IMHO.
Knuth is great for his theoretical work, but I don't know if he'd rank up there as an important programmer. Although I suppose someone could make an argument for it based on his work on TeX.
Which is exactly what I'll do.
TeX, MetaFont and family are major works.
Apart from the huge impact and scope of the project,
some of the algorithms therein were groundbreaking.
Design patterns is a book about Object Oriented design, aimed at the C++/Java level of abstraction.
Well, it's about generalization, loose coupling and that kind of stuff.
Lots of polymorphism.
Orthogonal to algorithm work, and not always something you want to
invest programming time and CPU cycles info.
After trying dozens of languages, I still return to C++, and I still think it is my favorite strongly typed language (yeah, I know, nobody can agree on strongly typed, but you know what I mean).
You mean "my favorite statically typed language".
And yes, I know what you mean.
The fact that you can't use all of DbC specifications, doens't mean that using a macro/asserts in C++ won't have any utility.
I suspect that you can
do some, but not all, of the Meyer design-by-contract stuff by using clever
template programming.
The Boost people have a collection of assertions, but I don't know whether there's
anything DBC-related. If there isn't, there should be.
The C assert() macro should be avoided in C++ code -- destructors will not be executed when an assert() fails.
I love Linux, and I wish it all the success in the world, but it just doesn't feel as snappy to me as windows 2000/XP. Seems like lost mouse-clicks and slow window redraws are a large part of the problem. Perhaps the problem lies with X, or with my own warped sense of perception... who knows?
Seems to me it lies at your side, because lost events and slow redraw is something
I experience frequently in Windows 2000, and never in Linux.
And I regularly use an old 180 MHz PC with Linux.
Mein Kampf is legal to own in Germany, and existing copies may be traded. However, the Bavarian state government owns the copyright and does not allow printing of new editions in Germany. The state government has also attempted to block publication in other European countries, but without success.
I was under the impression that they succeeded fairly well,
but I see my local public library has a recent Swedish edition.
There was a lot of noise about it in the press here a few years ago.
I feel sorry for the person that picks an OS dependent on a corporation for its existence. When there is only one "Sun" to nourish your OS "ecology" it is much more likely to wither away - eventually. I picked an popular open source OS for this very reason. RedHat may die but it will take a unprecedented disaster to also kill off Ubuntu, Debian, Slackware (especially Slackware), SUSE Linux, etc.. My intellectual investment is safest with Linux.
This is UNIX! You're supposed to be able to take your ecology
with you to Linux, or Solaris, or OpenBSD, or wherever.
With some pain, admittedly---but little more pain than if you're migrating
from, say, RedHat to Debian.
Huh? Not "gtk-key-theme" but "gtk-key-theme-name"?
Is this some sly Lewis Carroll reference on their part or what?
$ fortune -m "Haddocks' Eyes"
... the GTK+/GNOME people decided to change this as part of the quest to make GNOME more "user-friendly". Ironically, the users they strive to befriend are Windows users rather than long-time Unix / GNU users...
Slashdot Mirror
I've seen void f(string s); when void f(const string& s); would have been more efficient, but never an actual harmful copy. If I don't want a type to be copyable, I forbid copying.
The idea in this case is, I guess, to compare the idiomatic solution to a problem in C to the idiomatic solution in C++. std::copy versus memcpy(), iostreams versus fgets() and so on. Anything else would be pretty pointless.
All I know is, web interfaces (like the one I'm typing this into) are slow and brittle.
STL doesn't introduce bugs, you do. Never place objects which don't meet the minimum requirements for being placed in STL containers into STL containers, and you'll be fine. (If we're talking buffer overruns, aren't we talking about strings and std::vector, anyway?)
Yeah, right. How often do you think a is the only reference to that memory in the program? If you do have a problem, it's likely to be in some completely different part of the code, where there's an alias for a, with a completely different lifetime. Nothing you can do to a will change that.
(And really, what's the if(a) part all about? free(3) has accepted NULL pointers for the last twenty years or so.)
You mean libgpmg1. That's not related to GTK in any way (thank god).
Personally, I am happy with nvi(1), "a 'bug-for-bug compatible' clone of the original BSD vi". No strange dependencies there. But then I use emacs for all longer editing sessions.
You forgot the best reason: ncurses will optimize your I/O for you. "Is there already an 'a' at (10, 15)? Then don't render it again".
I doubt it. There's an awful lot of Kool-Aid you have to drink to become a Java programmer. Java isn't a language, it's a family of platforms. For a Unix person like myself, something like Python will always win over Java, precisely because it doesn't attempt to be a platform. In fact, Python tries to provide the Unix APIs in a convenient and straightforward way. The same goes for all relevant task-specific libraries. (And if you don't like Python, there are a handful of other popular, free languages at an abstraction level higher than Java, which share the same platform-agnostic approach.)
And meanwhile, Java is stuck on its own little island, and the beaches and the surfing aren't better there than anywhere else.
It's never a good sign when a program advertises the language it's written in by adopting the language's initial letter for its own name ...
Debian Sarge for x86_64 is perfectly well supported; you don't have to run testing/unstable.
Without a chroot? How? Opera is my only problem -- I don't want to bother with chroot environments, so I'm stuck with the statically linked 32-bit version. The Opera people don't make it a priority to release a 64-bit version, unfortunately.
Yes -- and habits is what people desperately need. The people I know primarily need three habits: RTFM when they don't understand something; adjusting their behavior based on the FM; and managing their use of the current directory (i.e. you don't have to cd into a directory to use a file which lives there).
The classic first BASIC program on micros in the 1980s, too.
Or where. Things were already fragmented back then. In the Unix community, maybe?
And yes, the Wikipedia article blames Kernighan, in 1972.
And you obviously don't mean the underlying concepts that make any important language unique and useful, either.
I recognize that there are more useful skills than knowing a language, and that you shouldn't learn The One Language and then live out your career in fear that it will become a useless skill ...
But I can guarantee that even with a small, elegant and extremely
high-level language (say, Python) you will write significantly better programs after
eighteen months than you did at twelve months.
I can't agree. You might bring in some extra code with iostreams and with the templated containers, but not a lot -- and you do benefit from it.
If we're speaking bloat, I think the two major factors are:
Only the first of them is related to object-oriented programming, and not all of us are afflicted by that kind of thinking.
I mind. Offering a contact form and nothing else tells me that they aren't interested in me being able to maintain my normal email workflow, keep a copy of the message I sent, Cc people, being able to track the mail by Message-ID, being able to sign the message, and so on. Offering a web form and an obfuscated mail address and an apology is enough to keep me happy though.
All those things were available 20--35 years ago. If nothing revolutionary has happened 1970--2006, what makes you so sure it it will happen in 2006--2025?
Fred Brooks' "No Silver Bullet" theory seems as plausible as ever, IMHO.
Which is exactly what I'll do. TeX, MetaFont and family are major works. Apart from the huge impact and scope of the project, some of the algorithms therein were groundbreaking.
Well, it's about generalization, loose coupling and that kind of stuff. Lots of polymorphism. Orthogonal to algorithm work, and not always something you want to invest programming time and CPU cycles info.
You mean "my favorite statically typed language". And yes, I know what you mean.
I suspect that you can do some, but not all, of the Meyer design-by-contract stuff by using clever template programming. The Boost people have a collection of assertions, but I don't know whether there's anything DBC-related. If there isn't, there should be.
The C assert() macro should be avoided in C++ code -- destructors will not be executed when an assert() fails.
Seems to me it lies at your side, because lost events and slow redraw is something I experience frequently in Windows 2000, and never in Linux. And I regularly use an old 180 MHz PC with Linux.
I was under the impression that they succeeded fairly well, but I see my local public library has a recent Swedish edition. There was a lot of noise about it in the press here a few years ago.
This is UNIX! You're supposed to be able to take your ecology with you to Linux, or Solaris, or OpenBSD, or wherever. With some pain, admittedly---but little more pain than if you're migrating from, say, RedHat to Debian.
Huh? Surely Kerberos is more complex than plain LDAP authentication?
Huh? Not "gtk-key-theme" but "gtk-key-theme-name"? Is this some sly Lewis Carroll reference on their part or what?
$ fortune -m "Haddocks' Eyes"
Lusers.