Computing desk
< July 28	<< Jun \| July \| Aug >>	July 30 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

July 29

Identi.ca and subscriptions

Alright, stupid question, but I've been trying for the past few HOURS to subscribe to people on identi.ca. I have my account setup, and all that jazz. However, now I want to subscribe to say https://twitter.com/#!/quominus. It tells me to click on the "remote" thing, and give the url. Which I do. However this leads me nowhere, and I get the error message.

 Sorry, we could not reach that address. Please make sure that the OStatus address is like nickname@example.com or http://example.net/nickname.

I've tried every variant of the url I could think of. http and https, with www. and without www., removing the "#!/" part, and all potential permuations. Nothing works. Could someone tell me what I'm doing wrong? Or at least tell me how in the #@$@#$@ world you're supposed to subscribe to people with on identi.ca??? Headbomb {talk / contribs / physics / books} 05:08, 29 July 2011 (UTC)[reply]

Identi.ca will allow you to follow anyone using another OStatus site, such as Status.net and the old Google Buzz. AFAIK, Twitter does not support OStatus. ^Avic _ennasis @ 06:15, 27 Tamuz 5771 / 29 July 2011 (UTC)

OK, then how do you subscribe to twitter feeds using identi.ca? It's possible to do it (https://identi.ca/settings/twitter). AFAIK I'm synced and all, yet I get nothing from Twitter or my twitter subsriptions. Headbomb {talk / contribs / physics / books} 07:58, 29 July 2011 (UTC)[reply]

Hmmm. I'm not sure. I've played around with this a lot now, and can't get it to work, either. My first thought was that from the phrase "Subscribe to my Twitter friends here" was that it would only search your Twitter contacts list to see if any of them were on Identi.ca, and if they were, subscribe to them locally. Doesn't seem to work that way. I have multiple twitter accounts, for which I created profiles for on Identi.ca, and even then that option doesn't work. So now I'm stumped as well. Perhaps the back-end code/twitter API has changed for this, and Identi.ca hasn't updated/isn't aware of the problem? ^Avic _ennasis @ 16:43, 27 Tamuz 5771 / 29 July 2011 (UTC)

preferred design for object-oriented aspects of c++

Hi, I'm working on a C++ program for personal interest, and (as currently planned) it uses objects that delete themselves. I know this is possible, but is it frowned upon? Also, more esoterically, the program has a class that needs to access protected data from a class "below" it in the hierarchy. In more detail, it has "class Simple" which contains "protected: simpleInteger" and "class Derived : public Simple" with additional data, and the Simple class needs to create a derived object, "Derived derivedObject" and access "derivedObject.simpleInteger". This seems to work fine when I do it in a basic test program, but is it good form in C++? The reason for doing it is I have a Tree with all sorts of Nodes (Tail nodes, Inner Nodes and Junction Nodes etc.) and I need to replace simple Nodes with Junction Nodes in some places. I could make everything a junction, but it seems like inefficient code, and would obstruct some of the polymorphism features. When turning a simple node into a junction, my current plan is to call the simple node, and get it to copy its (protected) data into the newly-created junction node's variables (the ones it inherits from the simple node class), and then get the simple node to delete itself. Is this a wise approach, or is it considered error prone? It looks dubious for an object to delete itself, and access protected variables from a lower class, but it also seems in every other way to be fairly "tight". It's been emotional (talk) 06:11, 29 July 2011 (UTC)[reply]

Objects that delete themselves are not bad. You can think of agent-based programming. The agent is an object. It runs off, does some work, reports back, and deletes itself.

Having a top-level object access data from a low-level object is bad design. A general object, like "car", shouldn't have any concept of the detail of a low-level object, like "z3_roadster". It is a one-way relationship. What you can do is have a general "extra information" field in the top-level class that may or may not be filled with something - but every extended class will have that field. Of course, general purpose fields are frowned upon because they may not be needed and serve no distinct purpose.

What you can do, which is better, is have a constructor for the junction node that takes a simple node as a parameter. The constructor will copy the values as necessary. There is an issue you need to keep an eye on... if you try to use a simple node for copying and, at the same time, you tell it to delete itself, you are in a race to see if the copy completes before the delete starts. You don't want to do that. I've seen worse. I saw a method that deleted "this" before calling "return" and the student simply couldn't comprehend why it caused a segmentation fault. -- kainaw ™ 13:03, 29 July 2011 (UTC)[reply]

It's fine to delete this as long as you don't subsequently use it. Returning from a method doesn't use this. The rest of your last paragraph makes no sense to me either. There's no race in copy_data(); delete this; return;. -- BenRG (talk) 22:34, 30 July 2011 (UTC)[reply]

It doesn't appear that you've graded many C++ programming class homework programs. Try this: delete this; return new SomeObject(this);. It actually does work - sometimes - but it also throws a segmentation fault - usually. -- kainaw ™ 02:59, 31 July 2011 (UTC)[reply]

You said "I saw a method that deleted 'this' before calling 'return' and the student simply couldn't comprehend why it caused a segmentation fault." That still doesn't make any sense. The actual problem with this code is that it uses this after deleting the object it points to. It would still be wrong if you omitted the return keyword. It would be right if you assigned new SomeObject(this) to a temporary local before the delete and returned it after. The return has nothing to do with it.

I still don't know what you meant by "if you try to use a simple node for copying and, at the same time, you tell it to delete itself, you are in a race to see if the copy completes before the delete starts". It sounds like you're talking about multithreaded code, but that would have no relevance to the original question. The other possibility is that you think that object copying happens asynchronously, in which case please read the sequence point article. -- BenRG (talk) 10:16, 31 July 2011 (UTC)[reply]

I have never been much of a C++ programmer, but I have done quite a lot of programming in C, C#, and Java, both at university and at various jobs. Am I correct in understanding that delete this; makes the current object, and any of its fields, unusable, but everything other in the whole world remains fully usable? JIP | Talk 22:48, 30 July 2011 (UTC)[reply]

delete does two things: it calls a destructor (computer science) (a type-specific function that typically destroys any subobjects recursively) and then performs a (close equivalent to) free(). --Tardis (talk) 02:09, 31 July 2011 (UTC)[reply]

Thanks for the quality answer. Can anyone give me a code fragment that would cause the aforementioned segmentation fault? When I do it, the computer is happy to "delete this" and then return, so long as the function returns void. Even then, I've managed to immediately access the recently-deleted data, just to see if it could be done, even though I know it is a programming error in meaningful use. It's been emotional (talk) 01:07, 30 July 2011 (UTC)[reply]

Kainaw is wrong about that. See this C++ FAQ entry for more information. The "conversion" you're doing doesn't convert the original object in place—you have to update all pointers to point to the newly created object—so I'm not sure that it ought to be a method on the old object, but if that arrangement makes sense in context then I think it's fine. You might consider using a constructor Derived::Derived(Simple const& other) : Simple(other) {} to do the actual copying. -- BenRG (talk) 22:34, 30 July 2011 (UTC)[reply]

The OO part of my brain (which is used to implicit, garbage-collected, deletions as in java/python) has a question. If I understand this correctly, this means a program that does

  Foobar f = new Foobar(); 
  int a = f.doStuff(); // where doStuff destroys its object
  int b = f.doStuff();

will produce unspecified behaviour for the 2nd doStuff() call (including returning nonsense or SEGVing), because while f is still a nonzero pointer (meh, reference) its no longer a valid pointer. That is, in fancier terms, that the language doesn't enforce a contract that just because I have a nonzero valid (strong) reference to an object doesn't mean that reference will remain valid until I invalidate it, but that any method I call on that ref can break it, and that the responsibility is mine in reading the contract of each method to see that it doesn't? If that's the case, can I ask: although the language allows this, whyever would you want to code this way? It seems like a style likely to produce hard-to-diagnose runtime weirdnesses. Is there any pragmatic reason why one wouldn't code Foobar to contain a single data field (a ref to the working Foobar data, which could be deleted once the Foobar was used up. and that member then nulled), so that if a subsequent call to doStuff was made the field could be checked == null, and an exception thrown (Foobar_invalid_state_exception)? -- Finlay McWalter ☻ Talk 23:03, 30 July 2011 (UTC)[reply]

Well, C++ programmers do avoid explicit heap allocation for that reason, and maybe it is a mistake to suggest that a beginner use new and delete in any circumstances. C++ objects behave like Java int, not Java Integer. When you write x = y; that makes x a copy of y, not an alias to the same object. Foobar f; constructs a Foobar on the stack, which is destroyed when the lexical scope of the declaration is exited, never before or after that. Containers like vector that can hold unbounded amounts of data can also be instantiated on the stack. Presumably the implementation is doing heap allocation behind the scenes, but it behaves from the outside as if all of the data was on the stack. It's not hard to write sophisticated C++ programs without ever using new and delete.

If you do write new Foobar then a Foobar object is constructed on the heap and a Foobar* value that points to it is returned to you (so you should have written Foobar* f = new Foobar();). You have to deallocate the object at some point with delete, unless you don't mind its hanging around until program termination, and the effect of using a pointer to an object after deleting it is undefined. So, yes, you have to be careful. A wrapper that nulls the pointer after deleting the object doesn't solve your problem because other pointers to the object might survive. If you know that no other pointers exist then the object probably didn't need to be on the heap in the first place. If you want to allow copying of the pointer with aliasing semantics (Java-like behavior), then it's probably better to use a shared_ptr<Foobar>, which maintains a refcount and deletes the object when it goes to zero. -- BenRG (talk) 10:16, 31 July 2011 (UTC)[reply]

USB

What is Wireless USB? How it works? — Preceding unsigned comment added by 59.99.152.172 (talk) 06:32, 29 July 2011 (UTC) [reply]

Does Wireless USB help? ^Avic _ennasis @ 06:35, 27 Tamuz 5771 / 29 July 2011 (UTC)

Failing hard drive and silent data corruption

Compared to normal, healthy hard drives, how likely is it for a failing hard drive to cause silent data corruption? I am talking about hard drives in typical desktop systems (7200 RPM drives connected to PCs running Windows through the SATA interface, with data backed up regularly to external drives). 118.96.157.169 (talk) 11:53, 29 July 2011 (UTC)[reply]

This links to a "study of 1.53 million disk drives over a period of 41 months [that] found 400,000 silent errors." Perhaps parity checks and other error correction mean that many of these are silently corrected. AndrewWTaylor (talk) 12:05, 29 July 2011 (UTC)[reply]

Cannot download Greasemonkey

https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/ When I try to download it, there's an error message saying that "The addon could not be downloaded because of a connection failure on addons.mozilla.org". This has hapened all afternoon. Is it just me? 92.29.113.104 (talk) 17:40, 29 July 2011 (UTC)[reply]

Seems to be working now. 92.29.113.104 (talk) 22:38, 29 July 2011 (UTC)[reply]

C (graphics)

how to work out on a project like simulation of global system for mobile with the help of graphics using c-language? — Preceding unsigned comment added by Maniiisha (talk • contribs) 18:46, 29 July 2011 (UTC)[reply]

It is very unclear what you are looking for. If you want to simulate GSM with a network simulator, it's unclear why you would need graphics at all. If you are seeking to program a network simulator, I wonder why you would even use the C programming language: you may find better infrastructure in MATLAB. Most network-engineers who work at this layer of simulation have no need for graphics. For example, here is MobSim, a GSM network simulator. It does have a graphical interface (implemented in Motif/C++).

On the other hand, your question might be interpreted to mean that you want to design a graphical application for a GSM-capable device, and run it on a simulated GSM-capable device. If that is the case, you should investigate the Android SDK or Xcode with the iOS SDK, which provide simulators for major commercial GSM-capable devices. You can program in C for the iOS platform or for Android, but both environments provide more utilities if you work in a higher-level language (e.g., Objective-C or Java). Paticularly for graphics, you will program in the context of a system graphics library - CoreAnimation/CoreGraphics for iOS or Android Graphics.

The most common utility for programming graphics in the C language is the OpenGL API and library. This has essentially nothing to do with GSM technology. Nimur (talk) 19:22, 29 July 2011 (UTC)[reply]