Forgot your password?
typodupeerror

Comment: Re:Refutation (Score 1) 546

by physicsnick (#32432774) Attached to: GCC Moving To Use C++ Instead of C

Yes, you've managed to find workarounds to all of these issues. There are of course ways to work around them. People do use C++ to get real work done; I have used it successfully many times in the past.

The point is that you have to *know* about all of these issues in order to use just this one feature effectively, without introducing subtle bugs, performance issues, or design problems.

Your solutions will mostly work of course but they are not terribly compelling. We might as well keep going:

  • Calling arbitrary functions in constructors might work, but you can't return multiple values to use as different constructor arguments, so there are more hacks to be done there.
  • Taking a bool& is pointless; you still need a dead-state for the destructor, so you may as well make a separate method to test for the dead-state after the constructor is run. (Good style also generally dictates you should never use non-const reference parameters; use pointers for out parameters to highlight that they will be written to.)
  • Making its destructor protected prevents the class from being destroyed at all unless it is subclassed; the example GGP gave would longer work. I'm not sure what you meant be this. I do agree that documentation should suffice, but tools like -Weffc++ will still warn about it (and rightfully so.)
  • I am not sure what you mean by resource classes. All I'm saying is that if MyClass contains a pointer and you forget to create a copy constructor, the compiler will do so implicitly, and your class will break horribly somewhere down the line.

Again, these are not insurmountable issues. They are just many things you need to be aware of in order to use constructors effectively. No other language has such land mines in such a simple feature as object constructors.

Comment: Re:Safe subset (Score 1) 546

by physicsnick (#32421116) Attached to: GCC Moving To Use C++ Instead of C
There are many problems with your example.
  • You can't do non-trivial initialization in the constructor because initializer syntax is not turing complete. Most C++ style guides (such as Google's) suggest using a separate init() function, so it isn't really less lines of code.
  • A constructor can't fail without throwing an exception. Assuming you don't allow exceptions, your class now needs an internal dead state. This is the case even if you use a separate init(), because the destructor needs to know whether init() was successful (unless of course you use a separate destroy(), making this pointless.)
  • A destructor can't fail at all. There is no way to indicate failure; you can't throw an exception because the destructor might be called during stack unwinding from another exception. What if the destructor fails to flush a buffer? The C version can simply return a boolean to indicate this.
  • There is no way to indicate that MyClass should not be inherited, so to allow deletion through a base class pointer (a requirement to satisfy the Liskov substitution principle), your destructor should be virtual. This adds overhead to the class itself, and adds a lot of overhead at the call site if the runtime type cannot be statically inferred.
  • You now need implement (or at least declare private) copy constructors and operator=. Developers expect C++ objects to be copyable, and standard containers require it.

Don't you see what is going on here? Even the most trivial feature of C++, constructors, are horribly ridden with complications. C++ is a language of never-ending surprises, gotchas, land mines. It's a trap.

Comment: Re:Soem of the complaints aren't valid (Score 1) 477

by physicsnick (#30349064) Attached to: Defining Useful Coding Practices?
Unless you're coding in Java, I definitely don't agree with the Java-style getRisk(), because the 'get' is redundant. Accessor methods usually take no arguments and return a value, so the fact that they 'get' something is obvious. Google's C++ style advocates risk(), as does Apple with Objective-C (the default accessors for properties even work this way).

I would call it calcRisk() if it is not const, i.e. it modifies the Investment object somehow (and calc is common short form for calculate). If however it's a const method that just returns the risk, then putting calculate in front is unnecessary. In fact I'd argue that advertising the fact that it is calculated on the fly is a violation of encapsulation. What if you find out that calculating the risk is slow, so you'd like to pre-calculate it, and just return the stored value? calculateRisk() is now mis-named (and you get your grubby hands all over everyone's code and logs if you rename it.)

Comment: Re:Android already conver that market (Score 1) 108

by physicsnick (#29519325) Attached to: Intel To Challenge Android With Moblin For Mobile Devices

Of course, there were a lot of computer makes around in the 80s, but the other difference is that these phones today do support a common standard, mainly thanks to Java, and also due to functionality being offered on websites). It's not perfect, but it's way better than the bad old days of computing where you needed a different version for every make and model on the market. Now a single application runs on pretty much any phone.

What universe do you live in? You've obviously never been a mobile developer if you think this even remotely resembles reality. Having been a mobile developer for over 2 years, I can tell you that Java has done absolutely nothing to solve device fragmentation. The language doesn't matter; it's the libraries, of course.

Every carrier has a hundred devices, and every single device has a different bug in its implementation of MIDP. With the strict size requirements for J2ME, for all but the simplest applications you can't even attempt combined builds. You are forced to make a different build for each device. Just wait until you try something *really* broken, like say, playing audio...

And smartphones of course use different APIs. MIDP, Android and BlackBerry have entirely different windowing toolkits. How do you expect an app to be magically portable between them? Even BlackBerries, where RIM has tight control over the devices and API, exhibits lots of fragmentation between devices and OS versions. Java is quite hostile to incompatible libraries, giving classloader errors for the slightest inconsistencies. When you buy a BlackBerry app from a third party site, especially for games, you almost always need to specify the exact model of your phone.

What is needed to reduce fragmentation is a rigorous certification process to strictly enforce the requirements of the platform. Sun had their chance; they could have required extensive testing to put that J2ME/MIDP logo on a phone. Unfortunately Sun failed, and Android seems to be deliberately going down the same path. I don't see the landscape getting better any time soon.

Comment: Re:High performance of C++ equal to D??? (Score 3, Interesting) 404

by physicsnick (#26950059) Attached to: Walter Bright Ports D To the Mac

>> D did another thing right: it did not remove destructors, like Java did. Instead, when there are zero references to an object, the GC calls the destructor *immediately*, but deallocates the memory previously occupied by that object whenever it wishes (or it reuses that memory). This way RAII is possible in D, which is very useful for things like scoped thread locks.

First of all, Java does have destructors. It's called finalize().

Second of all, calling destructors on a modern GC are extremely costly. Sure, your example implementation of destructors seems simple, but it is only possible in a reference counted garbage collector, which is so primitive as to be nearly useless.

Modern Java GCs are generational copying collectors. They have a young heap, where objects are allocated, and an old heap, where objects are moved when they survive an allocation. Object retention is done by tree search from a root node.

This means you can do fun things like allocate a linked list, then drop the reference node. When a collection happens, anything living is rescued from the young heap, and then it's simply wiped clean. No computation is performed regardless of how large it is or how many links it has, because there's no such thing as deallocation on the young heap. When you drop that first link, it's like the VM doesn't even know it's there anymore; the whole list just gets overwritten on the next pass over the heap.

If, however, you write a destructor for your links (or in Java, finalize()), the destructor then needs to independantly keep track of all of your destructable objects. It needs to remember that they're there so it can call their destructor when they do not survive an allocation. Furthurmore, if you impose your hard requirement of calling the destructor immediately, then the implementation of such a collector is impossible for your language. Even a primitive mark sweep collector, or anything not reference counted is impossible.

This example is discussed in detail here:

http://www.ibm.com/developerworks/java/library/j-jtp01274.html

You should familiarize yourself with modern garbage collectors. I don't know much about D, but if D really is tied down to a reference-counting collector due to its destructor requirements, that makes it extremely unnatractive as a language. Here is more information on various collector implementations:

http://www.ibm.com/developerworks/java/library/j-jtp10283/

It's funny.  Laugh.

Bill Gates' Plan To Destroy Music, Note By Note 659

Posted by timothy
from the too-insane-to-ignore-forever dept.
theodp writes "Remember Mr. Microphone? If you thought music couldn't get worse, think again. Perhaps with the help of R&D tax credits, Microsoft Research has spawned Songsmith, software that automatically creates a tinny, childish background track for your singing. And as bad as the pseudo-infomercial was, the use of the product in the wild is likely to be even scarier, as evidenced by these Songsmith'ed remakes of music by The Beatles, The Police, and The Notorious B.I.G.."
Security

+ - Mac, BSD prone to decade old attacks 7

Submitted by BSDer
BSDer (666) writes "An Israeli security researcher published a paper few hours ago, detailing attacks against Mac, OpenBSD and other BSD-style operating systems. The attacks, says Amit Klein from Trusteer enable DNS cache poisoning, IP level traffic analysis, host detection, O/S fingerprinting and in some cases even TCP blind data injection. The irony is that OpenBSD boasted their protection mechanism against those exact attacks when a similar attack against the BIND DNS server was disclosed by the same researcher mid 2007. It seems now that OpenBSD may need to revisit their code and their statements. According to the researcher, another affected party, Apple, refused to commit to any fix timelines. It would be interesting to see their reaction now that this paper is public."
Enlightenment

+ - Film Pirates for a Better Tomorrow

Submitted by hydrarchist
hydrarchist (620533) writes "The League of Noble Peers has just released a follow-up to their documentary, Steal This Film (about piracy conflicts and culture in Sweden.) Unsurprisingly, the new documentary is called "Steal This Film 2, The Dissolving Fortress" , and tells a tale inserting wherein p2p users join a historical thread disturbing power through communications shifts throughout the ages, starting with the printing press. They're also looking for contributions, financial and in-kind, to their media effort. It is also available on the The Pirate Bay where it currently has nearly 3,500 seeds!"
Google

+ - Google Products You Forgot All About

Submitted by
Googling Yourself
Googling Yourself writes "Lifehacker has an interesting blog post on the "Top 10 Google Products You Forgot All About" that includes stalwarts like Google Trends and Google Alerts and a few others that may not be quite so familiar like Google Personals, Google's WYSIWYG web site creation tool, and Flight Simulator for Google Earth. How many of the ten do you use regularly and what other Google products do you use that everybody else has forgotten all about?"
Education

+ - One-Laptop-Per-Child application development

Submitted by Anonymous Coward
An anonymous reader writes "This OLPC (One-Laptop-Per-Child) tutorial teaches you how to develop Python activities for the XO laptop. It covers the ins and outs of Sugar (the XO user interface, or UI) and the details behind activity development. You will also learn about Python programming, Sugar application program interfaces (APIs) for Python, and platform emulation with QEMU. Learn OLPC application development and help the worlds children."
Microsoft

+ - Office 2003SP3: Old file formats, now unavailable! 3

Submitted by
time961
time961 writes "In Service Pack 3 for Office 2003, Microsoft has disabled support for many older file formats, so if you have old Word, Excel, 1-2-3, Quattro, or Corel Draw documents, watch out! They did this because the old formats are "less secure", which actually makes some sense, but only if you got the files from some untrustworthy source.

Naturally, they did this by default, and then documented a mind-bogglingly complex workaround (KB 938810) rather than providing a user interface for adjusting it, or even a set of awkward "Do you really want to do this?" dialog boxes to click through. And, of course, because these are, after all, old file formats, many users will encounter the problem only months or years after the software change, while groping around in dusty and now-inaccessible archives.

One of the better aspects of Office is its extensive compatibility mechanisms for old file formats. At least the support isn't completely gone—it's just really hard to use. Security is important, but there are better ways to fulfill this goal.

This was also covered by the Windows Secrets newsletter, although I can't find a story URL for it."
Wii

+ - Nintendo Wii Fully Hacked at 24C3, runs Homebrew->

Submitted by
cHALiTO
cHALiTO writes "From the site:
The guys over at 24C3 just demoed a Wii hack that is set to provide native Wii homebrew in the near future (not running in GC mode, and with full access to all the Wii hardware!)
They were able to find encryption and decryption keys by doing full memory dumps at runtime over a custom serial interface. Using these keys, they were able to create a Wii 'game' that ran their own code (their demo happened to show live sensor/Wiimote information, amongst a few other things).
Read here and watch video here."

Link to Original Source
Hardware Hacking

+ - The Linux Driver Project - Again

Submitted by jon_anderson_ca
jon_anderson_ca (705052) writes "TINAD (This Is Not A Dupe)... back in January, Greg Kroah-Hartman offered to write GPL device drivers for manufacturers who would release specifications to him. Apparently the response was a little overwhelming, but now Novell is sponsoring him to work full-time on driver development.

There are a hundred developers and an undisclosed number of companies in the queue... are we about to see a Linux driver renaissance?"

He keeps differentiating, flying off on a tangent.

Working...