(Architecturally, it's also better - being based on deb packages instead of RPMs).
I keep hearing this, and I can't see why. I have maintained some Maemo.deb packages for a few years, and before that, quite a few RPM packages for another Linux distribution. I don't really see how one of the package managers is clearly better than the other.
No, no. C is an enabling language, that's right. C++ is a bewildering language, overloaded with features that, taken together, make it ridiculously complicated and unintuitive.
One problem with C++ is, there are too many "don't do this" rules to remember. If you should not do these things, why were they made available in the first place?
But when it's "done right" like you said, correct C++-style coding in C++ makes for absolute control over resource (de)allocation - and this is applicable not only for memory but other types of shared, limited resources as well. Very elegant, and very useful at times. I regret that in Java there are no destructors, but then again in Java you have no control over destruction of objects. This is convenient but limited. C++ provides control.
This control is not absolute. Try static non-POD objects, possibly containing dynamically allocated data, and referencing one another. For more fun, try to have some of these objects live in dynamically loaded modules which are then unloaded.
They are not yet standardized, meaning that you can't use the same family of pointers between code using Boost and, say, Qt-based code. Not to mention that many smartasses who think they are experts in C++ invent their very own smart pointer classes.
There is a multitude of smart pointer classes in any chosen family, breeding confusion and mistakes.
Nevertheless, there are too few smart pointer classes to provide good granularity on performance. Shared pointers in both TR1 and Qt are thread-safe, meaning that they waste CPU time on things like memory barriers in single-threaded programs.
Smart pointers are problematic to use in function parameter signatures, because they feature templated implicit type conversions which screw up overload resolution (playing C++ features against each other is an exciting game in general). This means that most interface designers prefer to either pass objects by plain old pointer/reference, resulting in unnecessary copying, or resort to "lightweight" handle classes wrapping opportunistically shared data structures. Not smart, huh?
But this is all corollary to the main thing: RAII is a solution to a language design problem.
Note that he was shutting down an annoying newbie who suggested something like reworking the git codebase to use "nice abstractions" to solve no real problem. C++ advocacy on the net seems to be dominated by such newbies, or then they are the gurus who know obscure C++ quirks inside out and have written a book on that.
I live in an apartment in Finland, and our parking lot is fitted with engine block heater plugs already. But yeah, reserved parking space can be scarce.
Re:No amount of documentation ...
on
Autotools
·
· Score: 1
For instance, instead of making a C program which outputs values with printf, make it so that the values are used as initializers for static data. Then use the cross-compiling toolchain's "nm" utility to extract the values from the compiled object file. You don't have to run a program to know how wide a (void *) is. Just do "static char size_of_void_star[sizeof (void *)]". Compile it, and then interrogate the.o to discover what is the content of the size of the data region named by size_of_void_star!
I think you have just outlined a reason why people decided to create pseudo-target environments like Scratchbox where you can run a tool or a test program you've just built, rather than mess with anything like what you suggest. Consequently, autotools work just fine in Scratchbox, OBS, and any other build systems that offer target emulation.
Re:FOR ALL AUTOTOOLS "REPLACEMENTS"
on
Autotools
·
· Score: 1
In other words, programs should not build natively on Windows
No, they only need shell+make+gcc, which projects like Cygwin and mingw32 have provided for years. Scons and Cmake require a much taller stack to port AFAIK.
Either your build machine is too slow/overloaded, or the source tree is unusably large and complex anyway, so it needs splitting to smaller, saner projects. What can a non-nested configure script even do for more than five minutes? You can also look for unnecessary checks in configure.ac; IIRC recent autoconfs check some smallish list of libc functions by default. I don't know why do even that, but it never held me back for any significant time to have these checks running. Look at any "utility" macros usually copied ad-hoc from some other project and left to rot. These tend to be sloppily written, use macros from obsolete versions of autoconf or automake, and do some misguided things; it's these macros that give autoconf a bad name.
Over a span of about two years -- and I think three "minor" (1.x) releases of automake -- the approved way of conditionally linking object files changed twice.
You mean like this stopped working: if ENABLE_FOO mytarget_LDADD += libbar.a endif
if ENABLE_BAR mytarget_LDADD += libbar.a endif
I assumed you would build plugins into convenience libraries first, because it's an expected way to lay things out with automake; it also allows easy conversion to libtool usage, should you decide you need it (e.g. if you want those modules to be loadable after all).
Re:Autotools do not need a book
on
Autotools
·
· Score: 1
From my experience so far, most of what people dislike about using autotools come from Automake. But Automake is of course completely optional to use, and Autoconf - which provides most of the benefits - was made to be standalone. If you have a system with existing makefiles, it makes a lot of sense to simply use Autoconf to configure the app and the makefiles and leave Automake alone.
That's until you go into building shared libraries for multiple platforms. Then automake and libtool are your saviors. Also, I find automated header dependency tracking nice to use.
Only when someone tries to launch a competing fashion accessories product line under that name, solely to garner interest on the confusion/controversy.
I don't think there was much confusion in her home market back in 1998, which BTW predates the trademark registration for fashion purposes by Ivana Trump.
Let's just take ekiga as an example, though any gnome app will do.
The state machine is tightly coupled with the UI just like a Windows application. As a result making it use multiple CPUs properly or reusing the code for anything other than another Gnome application is impossible. Not surprisingly it triggers races in underlying (similarly badly coded) libraries like there is no tomorrow. Same for having the UI stripped away. This is impossible.
That's why GNOME has switched to Empathy, just another GNOME app but done right.
Right on. The side-by-side DLL installation technique has been available for a while in Windows, but the idea has yet to down on many application vendors to use it.
Finland is in the same league as California in total area and has only a fifth of Californias population density. Even the "densely populated" south is still empty by Japanese standards. Public transport throughout the country still works. Less populated areas are naturally harder to reach but it's possible.Whether ultra-high-speed trains are feasible with these population numbers is another thing altogether.
Well, the Finnish railway company (yes, it's the state-owned company) chose to buy tilting trains rather than build dedicated high-speed lines. So we get the maximum speeds of mere 220 km/h. But you're right: the public transport in Finland is ubiquitous and very efficient. You have to live out in the sticks to really need a car. This doesn't mean that cars are in any way unpopular, but having a choice to not use a car is good.
Slashdot Mirror
(Architecturally, it's also better - being based on deb packages instead of RPMs).
I keep hearing this, and I can't see why. I have maintained some Maemo .deb packages for a few years, and before that, quite a few RPM packages for another Linux distribution. I don't really see how one of the package managers is clearly better than the other.
I especially liked the tidbit on how MeeGo "made almost no headway after several years."
The reality says that it was announced in February this year, and is near its first platform release with Nokia contributions and touch support.
3) I know how to package DEBs. Not true for RPM.
And this is somehow one of the reasons why Nokia is wrong?
No, no. C is an enabling language, that's right. C++ is a bewildering language, overloaded with features that, taken together, make it ridiculously complicated and unintuitive.
One problem with C++ is, there are too many "don't do this" rules to remember. If you should not do these things, why were they made available in the first place?
But when it's "done right" like you said, correct C++-style coding in C++ makes for absolute control over resource (de)allocation - and this is applicable not only for memory but other types of shared, limited resources as well. Very elegant, and very useful at times. I regret that in Java there are no destructors, but then again in Java you have no control over destruction of objects. This is convenient but limited. C++ provides control.
This control is not absolute. Try static non-POD objects, possibly containing dynamically allocated data, and referencing one another. For more fun, try to have some of these objects live in dynamically loaded modules which are then unloaded.
It bans the use of exceptions in the only language I have seen that does it right.
You don't say. But to their defence, they also ban the use of exceptions in C++, and for very good reasons.
Problems with "smart" pointers:
But this is all corollary to the main thing: RAII is a solution to a language design problem.
Note that he was shutting down an annoying newbie who suggested something like reworking the git codebase to use "nice abstractions" to solve no real problem. C++ advocacy on the net seems to be dominated by such newbies, or then they are the gurus who know obscure C++ quirks inside out and have written a book on that.
I live in an apartment in Finland, and our parking lot is fitted with engine block heater plugs already. But yeah, reserved parking space can be scarce.
For instance, instead of making a C program which outputs values with printf, make it so that the values are used as initializers for static data. Then use the cross-compiling toolchain's "nm" utility to extract the values from the compiled object file. You don't have to run a program to know how wide a (void *) is. Just do "static char size_of_void_star[sizeof (void *)]". Compile it, and then interrogate the .o to discover what is the content of the size of the data region named by size_of_void_star!
I think you have just outlined a reason why people decided to create pseudo-target environments like Scratchbox where you can run a tool or a test program you've just built, rather than mess with anything like what you suggest. Consequently, autotools work just fine in Scratchbox, OBS, and any other build systems that offer target emulation.
In other words, programs should not build natively on Windows
No, they only need shell+make+gcc, which projects like Cygwin and mingw32 have provided for years.
Scons and Cmake require a much taller stack to port AFAIK.
Builds that take half an hour just to "configure"
Either your build machine is too slow/overloaded, or the source tree is unusably large and complex anyway, so it needs splitting to smaller, saner projects. What can a non-nested configure script even do for more than five minutes?
You can also look for unnecessary checks in configure.ac; IIRC recent autoconfs check some smallish list of libc functions by default. I don't know why do even that, but it never held me back for any significant time to have these checks running.
Look at any "utility" macros usually copied ad-hoc from some other project and left to rot. These tend to be sloppily written, use macros from obsolete versions of autoconf or automake, and do some misguided things; it's these macros that give autoconf a bad name.
Over a span of about two years -- and I think three "minor" (1.x) releases of automake -- the approved way of conditionally linking object files changed twice.
You mean like this stopped working:
if ENABLE_FOO
mytarget_LDADD += libbar.a
endif
if ENABLE_BAR
mytarget_LDADD += libbar.a
endif
I assumed you would build plugins into convenience libraries first, because it's an expected way to lay things out with automake; it also allows easy conversion to libtool usage, should you decide you need it (e.g. if you want those modules to be loadable after all).
From my experience so far, most of what people dislike about using autotools come from Automake. But Automake is of course completely optional to use, and Autoconf - which provides most of the benefits - was made to be standalone. If you have a system with existing makefiles, it makes a lot of sense to simply use Autoconf to configure the app and the makefiles and leave Automake alone.
That's until you go into building shared libraries for multiple platforms. Then automake and libtool are your saviors. Also, I find automated header dependency tracking nice to use.
Only when someone tries to launch a competing fashion accessories product line under that name, solely to garner interest on the confusion/controversy.
I don't think there was much confusion in her home market back in 1998, which BTW predates the trademark registration for fashion purposes by Ivana Trump.
Ivana Trump regards her name as a trademark, too.
What's to stop people just dumping it on the street at night? Who's going to drive it all the way to a special place and pay for the privilege?
Include a redeemable deposit in the price, to be collected at waste reception points. This works with bottles and cans in EU.
Let's just take ekiga as an example, though any gnome app will do.
The state machine is tightly coupled with the UI just like a Windows application. As a result making it use multiple CPUs properly or reusing the code for anything other than another Gnome application is impossible. Not surprisingly it triggers races in underlying (similarly badly coded) libraries like there is no tomorrow. Same for having the UI stripped away. This is impossible.
That's why GNOME has switched to Empathy, just another GNOME app but done right.
q since that makes no sense
Will it help if I add just one more letter?
Right on. The side-by-side DLL installation technique has been available for a while in Windows, but the idea has yet to down on many application vendors to use it.
A coat hanger would be still better.
Finland is in the same league as California in total area and has only a fifth of Californias population density. Even the "densely populated" south is still empty by Japanese standards. Public transport throughout the country still works. Less populated areas are naturally harder to reach but it's possible.Whether ultra-high-speed trains are feasible with these population numbers is another thing altogether.
Well, the Finnish railway company (yes, it's the state-owned company) chose to buy tilting trains rather than build dedicated high-speed lines. So we get the maximum speeds of mere 220 km/h. But you're right: the public transport in Finland is ubiquitous and very efficient. You have to live out in the sticks to really need a car. This doesn't mean that cars are in any way unpopular, but having a choice to not use a car is good.
* Environmentalists will shit when they see the carbon produced in the process
These must be quite ignorant environmentalists. The carbon in biomass is fixed for short time periods, so burning it is still carbon-neutral.
I actually got my Wave invite in good time. Never used the chance to try it, as I didn't see a need.