Wednesday, September 6. 2006
Why do we keep on using C++?
Well, I don't know why you're doing it. I keep on using C++ because Amarok is written in it, which can't be changed easily. And that's about the only reason.
This morning I intended to review a code change in amarok.h, one of Amarok's central headers files. Accidentally, I pressed :w in vim, touching the file although it was not modified. The following build cycle left me ample time to shower, have breakfast, and write most of this blog entry! Just changing a single line in one of Amarok's C++ sources (heck, a single character), means a whopping 10 minutes of compiling and linking, until you actually get to see the result. Made a mistake? Oh well, fix it, and wait another 10 minutes. To summarize: Compiling is driving me nuts. I've wasted enough time for it in my life. Life's too short to wait for a freaking compiler.
Alas, there is no need for this madness. We have been given two wonderful tools, that present a true alternative for KDE application development. One is Ruby, given to us by Yukihiro Matsumoto, and the other is Korundum, by our very own Richard Dale. Using these tools, we can create applications and actually have fun doing it! Why bother with endless compile times, when we can have the same result in a much shorter time? Ruby is less performant than C++, but many programmers don't realize that this is utterly irrelevant for GUI applications, which spend 99% of their time in library calls, waiting for an event.
Two days ago I had this wonderful encounter with Gregor Karzelek in our new IRC channel #kde-ruby. He told me this:
I think this speaks for itself. I, for one, don't plan to create another KDE application in C++. I have better tools now
Did this blog spark your interest? If so, join us in #kde-ruby to learn more about Ruby and Korundum.
This morning I intended to review a code change in amarok.h, one of Amarok's central headers files. Accidentally, I pressed :w in vim, touching the file although it was not modified. The following build cycle left me ample time to shower, have breakfast, and write most of this blog entry! Just changing a single line in one of Amarok's C++ sources (heck, a single character), means a whopping 10 minutes of compiling and linking, until you actually get to see the result. Made a mistake? Oh well, fix it, and wait another 10 minutes. To summarize: Compiling is driving me nuts. I've wasted enough time for it in my life. Life's too short to wait for a freaking compiler.
Alas, there is no need for this madness. We have been given two wonderful tools, that present a true alternative for KDE application development. One is Ruby, given to us by Yukihiro Matsumoto, and the other is Korundum, by our very own Richard Dale. Using these tools, we can create applications and actually have fun doing it! Why bother with endless compile times, when we can have the same result in a much shorter time? Ruby is less performant than C++, but many programmers don't realize that this is utterly irrelevant for GUI applications, which spend 99% of their time in library calls, waiting for an event.
Two days ago I had this wonderful encounter with Gregor Karzelek in our new IRC channel #kde-ruby. He told me this:
"It is unbelievable how fast you can develop with ruby and how easy and fast you can create GUIs with korundum. i started a project for my brother a week ago and have done already about 80% of the functions and 90% of the gui. when i think how long it took my to create such things in java.."
"And for the speed: i don't know whether it really is that slower like so many say. i do think the gui of my project works quite fast. at least fast enough."
I think this speaks for itself. I, for one, don't plan to create another KDE application in C++. I have better tools now
Did this blog spark your interest? If so, join us in #kde-ruby to learn more about Ruby and Korundum.
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
For connecting some signals in Qt, sure ruby will be adequate, but I don't suggest doing anything more complex than that. Ruby IS slower than python, and python is rather slow, quite a bit slower than my script language of choice (perl).
A little story, I had written a little script in bash to split up a large directory tree into directories containing not more than 4.4GB worth of files, it was rather slow, took many minutes, even after the kernel had cached all the fine info. So I rewrite it in perl, it did a bit better, but not quite as good as I'd have liked, so I then went to rewrite it in C, after file info was cached, it took seconds.
Script languages are not good choices for writing important programs in. Little plugins and add ons maybe, but not an entire app. Just look at all the horrible VB6 apps out there.
A little story, I had written a little script in bash to split up a large directory tree into directories containing not more than 4.4GB worth of files, it was rather slow, took many minutes, even after the kernel had cached all the fine info. So I rewrite it in perl, it did a bit better, but not quite as good as I'd have liked, so I then went to rewrite it in C, after file info was cached, it took seconds.
Script languages are not good choices for writing important programs in. Little plugins and add ons maybe, but not an entire app. Just look at all the horrible VB6 apps out there.
How about writing the GUI in ruby/python/whatever, and if something is really too slow, write it in C++?
But I partially agree. Amarok is a highly complex app, that already consumes it's share of memory and processing power. I can just imagine that it would be a pig if it was written in a scripting language. All those little "just about as fast" as C++ bits add up to slowness.
But I partially agree. Amarok is a highly complex app, that already consumes it's share of memory and processing power. I can just imagine that it would be a pig if it was written in a scripting language. All those little "just about as fast" as C++ bits add up to slowness.
leo> How about writing the GUI in ruby/python/whatever, and if something is really too slow, write it in C++?
Why not just use a gui builder instead?
leo> All those little "just about as fast" as C++ bits add up to slowness.
Cept in python's and ruby's case, its about 10x slower.
Why not just use a gui builder instead?
leo> All those little "just about as fast" as C++ bits add up to slowness.
Cept in python's and ruby's case, its about 10x slower.
> Why not just use a gui builder instead?
Qt designer layouts some widgets for you, and that's it. You won't be finished with your UI after that.
You still have to set up and connect non-GUI components, do some more complex things when an action is executed, etc.
Qt designer layouts some widgets for you, and that's it. You won't be finished with your UI after that.
You still have to set up and connect non-GUI components, do some more complex things when an action is executed, etc.
Have you looked at Amarok's source? Most of it is just connecting A to B and shuffling around strings. Only a handful of classes have much in the way of loops and such. Amarok is mostly just braiding together different libraries.
My language of choice is also perl. However, as much as i prefer perl to python -- it's generally acknowledged that python is notably faster (much of it due to being stronly typed). If parrot and perl 6 come to fruition, that might change.
There are instances where perl is faster, for example it's regexp library - however, in most cases it is slower.
There are instances where perl is faster, for example it's regexp library - however, in most cases it is slower.
This has got a lot more to do with the way you all have designed amarok behidn the scenes than with C++... I'm sure if you had something as complex as amarok written in ruby/korundum you'd run into much more headaches. Regarding the header file.. just make sure every file in amarok doesn't depend on that file and you're free to make changes to it without recompiling all of amarok every time you make a change to it. This goes back to better design, perhaps instead of freaking out at C++, you might take a second to think about how amarok could be better laid out to spur development as opposed to hindering it as it seems to be at this point. 0.02
I totally agree, split things up into smaller modules if you have to. and proper dependency checking is a must, I use a little build system called CBUILD (http://awiki.tomasu.org/CBUILD). Its quite nice, pure C, no dependencies itself, and is quite flexible (sadly the docs on that wiki pager a a tad outdated).
In case you care to descend to Earth for a bit, amarok.h just has a handful of methods and is hardly ever edited. You should note that markey accidently touched the file, he didn't actually need to change anything in it.
I honestly don't think he was getting all high an mighty..
touching a file should never cause a rebuild of everything. changing a single file should rarely ever cause a rebuild of everything, unless EVERYTHING uses stuff from that file. Not just includes, but actually uses something from it. And even then, can it be split up some more?
touching a file should never cause a rebuild of everything. changing a single file should rarely ever cause a rebuild of everything, unless EVERYTHING uses stuff from that file. Not just includes, but actually uses something from it. And even then, can it be split up some more?
Er, isn't the problem here with make, rather than C++? Since make relies on comparing modification times to know when to rebuild a source tree, rather than on changes to source content, ":w"ing the file will cause the modification time on the file's inode to change, thereby triggering a rebuild . . . .
Hm, first I think we have to clear out what we want to do and what we need to do. In some cases Ruby/Python/Java/andsoon are the best choice. In other cases we should need languages like C/C++.
Ruby (at this example) is a scripting language. So the OS need a layer wich interact with the written code and the machine. In some cases this waste runtime and ressources. C/C++ is more time expansive, but runs directly in a "machine layer" because we compile it and so translate it directly for the machine (long dev-time, fast run-time).
On the other hand we develope applications wich uses ruby in a more faster way.
Its a projekt manner I think. So no language is the "better way" to create a app. Its a question of what we need and what we have to do.
But I dont think that it should be a good idea to create a application like Amarok in Ruby. In this cases (or cases like this) we should use C++ (or C) because this is for these complex apps the most effective way for the user and the system.
Ruby (at this example) is a scripting language. So the OS need a layer wich interact with the written code and the machine. In some cases this waste runtime and ressources. C/C++ is more time expansive, but runs directly in a "machine layer" because we compile it and so translate it directly for the machine (long dev-time, fast run-time).
On the other hand we develope applications wich uses ruby in a more faster way.
Its a projekt manner I think. So no language is the "better way" to create a app. Its a question of what we need and what we have to do.
But I dont think that it should be a good idea to create a application like Amarok in Ruby. In this cases (or cases like this) we should use C++ (or C) because this is for these complex apps the most effective way for the user and the system.
Change to a different make tool.
We use a lot of C++ and use SCons as the build tool. Instead looking at the timestamp SCons uses MD5 hashes to determine if rebuilds are necessary. So if you by accident touch a file the build will be finished in a very short time
We use a lot of C++ and use SCons as the build tool. Instead looking at the timestamp SCons uses MD5 hashes to determine if rebuilds are necessary. So if you by accident touch a file the build will be finished in a very short time
I don't understand how anyone can say that scripting languages, particularly Python (I don't know this for sure for Perl/Ruby) are 'slow' when things like Psyco and Pyrex exist to bring most Python programs up to within a few percent difference of C++, and I'm speaking from experience.
For instance I've been working on a Neuroevolution program for the last few years, and just for giggles I thought I'd race the Python version against the C++ version. At first the difference was staggering, about 11s in straight Python vs about 0.1s in C++. With Psyco the 11s goes down to about 0.5s, and with Pyrex I was able to bring it down to 0.15s. I would say that's pretty damn good for just throwing a few type declarations into my Python code.
Everyone knows dynamic languages are leaps and bounds more productive to program in, I just don't know why people don't accept that the performance difference is a myth now.
For instance I've been working on a Neuroevolution program for the last few years, and just for giggles I thought I'd race the Python version against the C++ version. At first the difference was staggering, about 11s in straight Python vs about 0.1s in C++. With Psyco the 11s goes down to about 0.5s, and with Pyrex I was able to bring it down to 0.15s. I would say that's pretty damn good for just throwing a few type declarations into my Python code.
Everyone knows dynamic languages are leaps and bounds more productive to program in, I just don't know why people don't accept that the performance difference is a myth now.
Let me know when the KDE and QT libs are written in Pure Python, and Perform just as good (none of this, "its only a few percent slower bull), then we can talk.
I most of the apps I ran were written in Python or Ruby, each one would have that "few percent" performance hit. It adds u very quickly.
I most of the apps I ran were written in Python or Ruby, each one would have that "few percent" performance hit. It adds u very quickly.
You could use precompiled headers, but in this case I suppose amarok.h would be the header to create the precompiled information.
If you have a versioning system, you would stop the build, get the clean version of the file and voila no more compile.
You are just looking after excuses to ditch c++, you don't like it. One man's poison is another man's drink.
If you have a versioning system, you would stop the build, get the clean version of the file and voila no more compile.
You are just looking after excuses to ditch c++, you don't like it. One man's poison is another man's drink.
Take a look at lua as a language to embed inside your C++ program, replace most of the logic, and not introduce a dependency on an external interpreter (lua can be statically linked in). In particular, it's fairly easy to migrate a C++ program piecewise to lua, moving inward from the periphery and skipping the bits that need to be blazing fast.
The "ONLY" reason to write in C++ - runtime /memory. If you have a large data sets (I work in CAD industry so we have HUGE data to analyze) nothing can be compared to C++/C. And don't start with assembler please
Phyton and etc...
C++ most efficien than I cna have access to objects in O(1) time (i'm not talking about hashing and O(1) in averrage) so I try to use a lot of stl::vectors even instead of lists.
C++ most efficien than I cna have access to objects in O(1) time (i'm not talking about hashing and O(1) in averrage) so I try to use a lot of stl::vectors even instead of lists.
We use C++ because is fast if you know how to use it. Have a look at the Pimpl idiom that might solve your problem. On the other hand, having nothing relevant (I mean one space) changed in the header file denotes also how stupid these days compilers are.
I agree completely. Software productivity in C++ is a disaster compared to the alternatives, especially when you consider that the performance benefits of using C++ are so rarely important in real applications.
The key challenge is not for developers of new projects who will rightly go for Python, Ruby, C# or Java, but for those of us stuck with large volumes of existing C++ code and need to transition relatively smoothly to something more productive. I've blogged a little of this topic at
The key challenge is not for developers of new projects who will rightly go for Python, Ruby, C# or Java, but for those of us stuck with large volumes of existing C++ code and need to transition relatively smoothly to something more productive. I've blogged a little of this topic at
Speeding up development isn't always good justification for language adoption. Example: Visual BASIC.
The problem you are likely having is linking Qt. It takes a damn long time. Compilation isn't the issue; linking is. Moving to a scripting language, as some have suggested, will allow you to speed up the gui programming and hopefully drop link times; unless you're using Qt throughout. If that's the case, sucks to be you.
Your problem with C++ is all around build time. How about looking at a solution like ccache or distcc? Or if you are in the commercial world Electric Cloud.
John.
John.
No, it's not. I've picked one problem with C++ as a means to demonstrate Ruby's advantages. But it has more advantages than this.
While people will not like what I'll say, I use FPC as a compiler to enjoy myelf, it gives me native code, and using a better language to work with.
The compiler is much faster then any c(++) based compiler, and even the binary code execute faster then gcc's as long as you do not optimize the code.
Unlink ruby and other script based language, it's easier to handle large projects, and you do not need configure scripts, and you Makefile (only if you really need it) can be very simple, because you can give instructions to your compiler at the source code, so if you link yourself to a library, you do not need to add that to your Makefile. The when you need to create a shard library, all the information exists on the source code itself.
Just try it
The compiler is much faster then any c(++) based compiler, and even the binary code execute faster then gcc's as long as you do not optimize the code.
Unlink ruby and other script based language, it's easier to handle large projects, and you do not need configure scripts, and you Makefile (only if you really need it) can be very simple, because you can give instructions to your compiler at the source code, so if you link yourself to a library, you do not need to add that to your Makefile. The when you need to create a shard library, all the information exists on the source code itself.
Just try it
Thank you very much, but I'll stay away from Pascal as far as I can. I had the pleasure to deal with it back in school, and I can assure you I don't need that again. The downfall of Pascal (who uses it these days?) was a very welcome change to me.
You can design big c++ projects to avoid dependencies. Give classes abstract interfaces to avoid dependencies on the concrete classes with implemention details that might need to change. It tough to start thinking about this stuff when you already have a big project that takes an hour to compile tho.
Perhaps you should indeed switch to a more user friendly language. If your code is anything like the grammar used in the above post, I can see why you're having problems in C.
Nothing you mentioned is a problem with the C++ language.
To start, touching the file with vim should make no difference. Why would you recompile anything based on its Last Modified time?
Secondly, I suggest reading your compilers manual, and learning how to link object code manually. To save you from having to recompile your entire project whenever you make a change. (There's a reason the Linux kernel isn't all in 1 source file, remember that abundance of .o files you found when learning the 'cd' command?)
Thirdly, there exist tools specifically to aid with GUI design, to save people from reinventing the wheel every time they wish to make something useful. Use them, Love them.
One of the primary reasons C++ is still in widespread use, is because written correctly, it has the best balance you can currently find between performance and development speed. Another, is the fact that so many people know how to use it. It's most certainly not suitable for everyone, or every purpose.
Ruby/Python are also great languages with their own pros and cons. But there's no need to jump on the Web 2.0 AJAX RailsDiggLover2000 bandwagon and start criticizing the language for your shortcomings as a software developer.
Any malice displayed in this post is purely intentional.
Nothing you mentioned is a problem with the C++ language.
To start, touching the file with vim should make no difference. Why would you recompile anything based on its Last Modified time?
Secondly, I suggest reading your compilers manual, and learning how to link object code manually. To save you from having to recompile your entire project whenever you make a change. (There's a reason the Linux kernel isn't all in 1 source file, remember that abundance of .o files you found when learning the 'cd' command?)
Thirdly, there exist tools specifically to aid with GUI design, to save people from reinventing the wheel every time they wish to make something useful. Use them, Love them.
One of the primary reasons C++ is still in widespread use, is because written correctly, it has the best balance you can currently find between performance and development speed. Another, is the fact that so many people know how to use it. It's most certainly not suitable for everyone, or every purpose.
Ruby/Python are also great languages with their own pros and cons. But there's no need to jump on the Web 2.0 AJAX RailsDiggLover2000 bandwagon and start criticizing the language for your shortcomings as a software developer.
Any malice displayed in this post is purely intentional.
I'm willing to bet you haven't masterminded any projects as succesful as Amarok.
As unecessary as I feel it is, I must also comment that most of your points about development are correct, but are also fucking obvious and you really don't seem to be as talented as you think you are.
I can't believe you know nothing about build systems that you think modification times are not the normal way to judge the file requires a rebuild. I can't believe you think it is practical to build objects manually. I can't believe you think KDE people don't use GUI tools to simplify GUI design. I can't believe you don't understand that sometimes files have to be included everywhere (amarok.h contains #define VERSION "1.4.2", and other vital macros that change hardly ever), and that this creates a dependency you can't solve even if you're Linus fucking Torvalds.
Mostly I can't believe you are so full of yourself that you chose to write such outrageous and insulting things when you don't even understand the situation properly. Taking cheap stabs at a German's English grammar just prove you have no real ammunition with which to attack.
Jeff McJefferson, I'm going to google for you, and I sincerely hope that what I find makes me laugh. You are a fucking wanker and I hope you get run over by a bus.
Please die, thanks very much, yours with malice,
Max Howell
As unecessary as I feel it is, I must also comment that most of your points about development are correct, but are also fucking obvious and you really don't seem to be as talented as you think you are.
I can't believe you know nothing about build systems that you think modification times are not the normal way to judge the file requires a rebuild. I can't believe you think it is practical to build objects manually. I can't believe you think KDE people don't use GUI tools to simplify GUI design. I can't believe you don't understand that sometimes files have to be included everywhere (amarok.h contains #define VERSION "1.4.2", and other vital macros that change hardly ever), and that this creates a dependency you can't solve even if you're Linus fucking Torvalds.
Mostly I can't believe you are so full of yourself that you chose to write such outrageous and insulting things when you don't even understand the situation properly. Taking cheap stabs at a German's English grammar just prove you have no real ammunition with which to attack.
Jeff McJefferson, I'm going to google for you, and I sincerely hope that what I find makes me laugh. You are a fucking wanker and I hope you get run over by a bus.
Please die, thanks very much, yours with malice,
Max Howell
Indeed, my response was so typical Intraweb, I'm not sure what got me so sparked. I apologise.
In defense of the project, I'm hardly involved anymore so my comments aren't representative of the active developers.
In defense of the project, I'm hardly involved anymore so my comments aren't representative of the active developers.
Sometimes my colleague can be quite rowdy.
In his defense, he doesn't use Amarok, KDE or Linux (Lunix is the diet coke of unices), and was following a hyper-link from a social networking internet news world wide web homepage.
The person in question also uses D and OCaml, disputing the claims that C++ is at fault for mein blogfuhrer's original problem.
How long did you spend on the red herring.
In his defense, he doesn't use Amarok, KDE or Linux (Lunix is the diet coke of unices), and was following a hyper-link from a social networking internet news world wide web homepage.
The person in question also uses D and OCaml, disputing the claims that C++ is at fault for mein blogfuhrer's original problem.
How long did you spend on the red herring.
"Lunix [sic] is the diet coke of unices"
So it doesn't rot your teeth, give you diabetes, and taste overly sweet like the other unices? I'll take it.
So it doesn't rot your teeth, give you diabetes, and taste overly sweet like the other unices? I'll take it.
I'm pretty sure the fully sugared Unixes have the same make systems.
I suppose the fact that folks from some social networking site are coming on here would explain why some of these responses have been completely ignorant and in this case nationalistic.
And I, an active Amarok developer, endorse the hilarious response of Max.
I suppose the fact that folks from some social networking site are coming on here would explain why some of these responses have been completely ignorant and in this case nationalistic.
And I, an active Amarok developer, endorse the hilarious response of Max.
"There's a reason the Linux kernel isn't all in 1 source file, remember that abundance of .o files you found when learning the 'cd' command?"
No, actually. I learned the 'cd' command on some variant of DOS 18 years ago, so it would have been hard to find Linux kernel files on there. And I've never used 'cd' to find .o files. I use 'ls' for that (or maybe 'find' or 'locate' and all of those possibly in conjunction with 'grep'). But then, to each his own. Have fun finding those files with 'cd'.
No, actually. I learned the 'cd' command on some variant of DOS 18 years ago, so it would have been hard to find Linux kernel files on there. And I've never used 'cd' to find .o files. I use 'ls' for that (or maybe 'find' or 'locate' and all of those possibly in conjunction with 'grep'). But then, to each his own. Have fun finding those files with 'cd'.
To improve builds, use ccache, it can integrate transparently into a gcc based build system and avoid recompilations if the content of the files are the same. It'll do this across multiple build trees, substituting cached object files wherever safely possible. I use it along with distcc, which makes compiles much speedier!
Woah comments!
I'm writing a few apps with Digital Mars d. For me one of the best things with d is all "headers" are precompiled objects. Build times are very quick.
Shame we couldn't port Qt easily. d is already pretty mature and would be a viable choice, if it's ever viable to choose a language that people don't have a compiler installed by default for.
The only solution I see for amarok is precompiled headers + a special developers makefile which doesn't generate libamarok.so, I started making one but lost interest when I had created a pch that created strange compile errors. Obviously people working on the media device stuff would have to use the normal build system, but for the rest of us, it would be better.
For Amarok 2 we can reconsider the mistakes.
Finally I have to give credit to MS, their compiler and build system is much faster at compiling and linking than gcc. And the error messages are generally less cryptic too. Shame Visual Studio is 20 years behind kdevelop.
I'm writing a few apps with Digital Mars d. For me one of the best things with d is all "headers" are precompiled objects. Build times are very quick.
Shame we couldn't port Qt easily. d is already pretty mature and would be a viable choice, if it's ever viable to choose a language that people don't have a compiler installed by default for.
The only solution I see for amarok is precompiled headers + a special developers makefile which doesn't generate libamarok.so, I started making one but lost interest when I had created a pch that created strange compile errors. Obviously people working on the media device stuff would have to use the normal build system, but for the rest of us, it would be better.
For Amarok 2 we can reconsider the mistakes.
Finally I have to give credit to MS, their compiler and build system is much faster at compiling and linking than gcc. And the error messages are generally less cryptic too. Shame Visual Studio is 20 years behind kdevelop.
10 minutes to build amarok?????!!!! I need 5 (3800+ amd64 dual core proccessor). But, if you are developing, why not do a makefile and make things depend to others, if you have code object (*.o) already compiled, if you modify parts, make can only compile and link the modified part...
Ok, so while you were building amarok on your pretty computer didnīt you notice it **has** a Makefile????
Some comments on this post make me think the posters for some reason believe Amarok was written by ignorants.
When you see a very successful project (like Amarok) which is as good or better as all other similar projects, think about it... donīt you expect it to be written by people who HAVE A CLUE?
Kids these days
Some comments on this post make me think the posters for some reason believe Amarok was written by ignorants.
When you see a very successful project (like Amarok) which is as good or better as all other similar projects, think about it... donīt you expect it to be written by people who HAVE A CLUE?
Kids these days
Of course NOT! How could I believe that the most excellent program to manage and play music is written by ignorants? I only wanted to say this, but not to harm anybody (sorry if it's this case).
I only wanted to say this, but not to harm anybody (sorry if it's this case).
uh, VB is still the most popular language on the planet, and VB.NET fixes issues the old VB6 had. So I think parroting 1990s usenet talking points about VB is pretty clueless.
VB and VB.NET have flaws still, of course, but ease of use is not one of them.
VB and VB.NET have flaws still, of course, but ease of use is not one of them.
Over the years I've developed many GUIs with Delphi and have found it both fun and extremely productive. What makes it especially powerful is the vast array of attachable components and dlls available for it. It comes in a Linux version called Kylix too. And it has built in database capability. There is also a dedicated user base online who will help with problems. Compile times are generally seconds and not minutes. I don't know how they do their compiles so fast, but that has been an advantage of Borland's compilers from the very beginning. Of course Delphi uses Object-Oriented Pascal, and for some that is a disadvantage. But Object-Oriented Pascal is a big improvement over vintage Pascal, and it supports many of the advanced features of C++.
My first programming language was C++ using C++ Builder. It was a nice environment indeed.
It's frightens me that you blame C++ for what is really a problem of organising your source code.
How can a scripting language make this better? The language itself is not the problem.
It seems to me that you need to understand and organise the dependencies in your source code. C++ was created to handle large projects. But even the best tool in the world can be misused.
The real computer is between your ears.
How can a scripting language make this better? The language itself is not the problem.
It seems to me that you need to understand and organise the dependencies in your source code. C++ was created to handle large projects. But even the best tool in the world can be misused.
The real computer is between your ears.
You also have eyes on your head to read with!
He accidently touched a header that is imported throughout Amarok. The header has stuff that is changed hardly ever. There is nothing wrong with it.
He accidently touched a header that is imported throughout Amarok. The header has stuff that is changed hardly ever. There is nothing wrong with it.
Ever heard of "touch" ?
$ touch --help
Usage: touch [OPTION]... FILE...
Update the access and modification times of each FILE to the current time.
Mandatory arguments to long options are mandatory for short options too.
-a change only the access time
-c, --no-create do not create any files
-d, --date=STRING parse STRING and use it instead of current time
-f (ignored)
-m change only the modification time
-r, --reference=FILE use this file's times instead of current time
-t STAMP use [[CC]YY]MMDDhhmm[.ss] instead of current time
--time=WORD change the specified time:
WORD is access, atime, or use: equivalent to -a
WORD is modify or mtime: equivalent to -m
--help display this help and exit
--version output version information and exit
Note that the -d and -t options accept different time-date formats.
If a FILE is -, touch standard output.
Report bugs to .
$
$ touch --help
Usage: touch [OPTION]... FILE...
Update the access and modification times of each FILE to the current time.
Mandatory arguments to long options are mandatory for short options too.
-a change only the access time
-c, --no-create do not create any files
-d, --date=STRING parse STRING and use it instead of current time
-f (ignored)
-m change only the modification time
-r, --reference=FILE use this file's times instead of current time
-t STAMP use [[CC]YY]MMDDhhmm[.ss] instead of current time
--time=WORD change the specified time:
WORD is access, atime, or use: equivalent to -a
WORD is modify or mtime: equivalent to -m
--help display this help and exit
--version output version information and exit
Note that the -d and -t options accept different time-date formats.
If a FILE is -, touch standard output.
Report bugs to .
$
Ruby is broken by now
i like that ruby thing but, by now it know nothing about unicode. Slices of strings just don't work!
citing:
"While you can’t use Unicode strings with ruby, you can store UTF-8 encoded data in your 8-bit strings. However some of the String methods assume a single byte encoding and therefore return wrong results."
http://wiki.rubyonrails.org/rails/pages/HowToUseUnicodeStrings
Best Regards
Martin Ponce
i like that ruby thing but, by now it know nothing about unicode. Slices of strings just don't work!
citing:
"While you can’t use Unicode strings with ruby, you can store UTF-8 encoded data in your 8-bit strings. However some of the String methods assume a single byte encoding and therefore return wrong results."
http://wiki.rubyonrails.org/rails/pages/HowToUseUnicodeStrings
Best Regards
Martin Ponce
This has been fixed in the latest Ruby I believe. I've certainly seen code on a blog somewhere that added full good UTF support to Ruby's string and I think this has been commited.
The header file contains your programmers interface anyway, so in theory you should define that before you start to code the implementation and not touch it continuously during implementation.
Hi, i'm having the same problem with kboard (kboard.sf.net), and i recommed you for instance to use
touch file -r old_file
to set the date of file to the same as old_file, to avoid having to recompile everything.
I sometimes to this also when i modified a header and i KNOW that i did no change that break ABI (this is dangerous and will work only if you know what you are doing).
Now, what really kills me is link time, to use C++ we would really need an incremental linker
touch file -r old_file
to set the date of file to the same as old_file, to avoid having to recompile everything.
I sometimes to this also when i modified a header and i KNOW that i did no change that break ABI (this is dangerous and will work only if you know what you are doing).
Now, what really kills me is link time, to use C++ we would really need an incremental linker
make -t should touch all your files (maybe only the Makefile targets), so at least for typo and commenting you can use it and your whole tree won't be rebuilt.
Poor workmen always blame their tools
Amarok is way too slow, too bloated and unstable in my experience.
Rather than keep adding new features, how about optimising the code and making it rock solid?
Also why are you using VI and not KDevelop? I like Vi and it's really fast, but there's always a chance that an incorrect keystroke could delete some valuable work.
Amarok is way too slow, too bloated and unstable in my experience.
Rather than keep adding new features, how about optimising the code and making it rock solid?
Also why are you using VI and not KDevelop? I like Vi and it's really fast, but there's always a chance that an incorrect keystroke could delete some valuable work.
Amarok Links
Calendar
Quicksearch
Categories
Syndicate This Blog
Blog Administration
We Listen To...
Powered by
