The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
Shut down, move it to a different USB port, and reboot.
If that doesn't work, go do Device Manager and uninstall the driver, then refresh the Device Manager to reinstall it (on Weven, "Scan for Changes").
If that doesn't work, run a disc scan, to look for/repair bad sectors.
If it's still no good, then look for any software that you installed when you first got the device (if anything), and: - Check each executable and DLL in its installation directory for dependencies (Dependency Walker is good for this), making a note of any that are outside of the device's proprietary directory (e.g. in the Windows dir/system dir/shared dirs).
- Uninstall the software, making sure that the proprietary directory it was installed to is really gone (i.e. delete it manually, if it's still there).
- Check any of the dependencies to files in other directories. If the files were made by the company that made the device. rename them (as long as the device wasn't made by Microsoft).
- You can get rid of any registry entries, too, if you do that kind of thing (if you've never edited a Win registry, leave it).
If that doesn't fix it, you'll probably have to settle for getting some new hardware.
I wanna be a eunuchs developer! Pass me a bread knife!
I have been turning away from .Net lately and looking for alternatives. I don't want to have to rewrite everything when a certain company heads into a different direction once more.
My answer is C++. I always liked its flexibility to allow you to do very low level programming just as well as very high level programming. And today I stumbled over this video[^], in which Bjarne Stroustrup answers two simple questions.
Now I know why I like C++ so much. Thanks, Bjarne.
I like C++, but I don't like what it's turning into (and how many code designs insist on the most complicated implementations.) Moreover, just because something could be represented as an object and in a hierarchy doesn't mean that it should be.
That's not limited to C++. I have encountered four different types, what architecture and class design are concerned:
1) Archi... what? (perfect chaos)
2) Get the job done and worry about future problems when they arise.
3) Must use every pattern in the book at least once in every project. And at least one or two of my own.
4) Software as a religion, with the one and only way to do things. All others lead straight to hell. (Strict order, but absolutely helpless when something happens that is not dealt with in their particular bible)
I attempt to live C++ actually. I use to be in C programming. There was nothing about objection, overload etc. Now I do work in C++, during for 4 months I can used to program with it. Can somebody give some advises how to learn C++ or how can I get much progress ASAP ? Thanks
1) Learn C, especially how to write functions. A C++ object's methods work very much like C functions. You will be able to use your experience with C here.
2) Learn about object orientation by understanding the concept. The way the concepts are implemented in C++ (or any other language) are secondary at the moment. Begin with understanding what an object actually is: A data structure with attached functions to allow safe manipulation of the data inside that structure.
3) Learn the difference between a class (the definition) and objects (individual instances of a class). That will lead you to learning about the basic lifecycle of an object. Allocation of memory and automatic execution of the constructor when you create a new object with 'new', and automatic execution of the destructor and freeing memory when you destroy an object with 'delete'. Despite their somewhat scary names, constructors and destructors are just functions which are called automatically when you create or destroy objects. It's very important that you learn to use them to initialize or clean up an object.
4) Learn to use encapsulation to divide up the internal state of an object and its external interface. Other objects can only access methods or member variables of an object which you have declared as 'public'. They get no access to the members you declare to be 'private'. This way you can limit how the object's state is altered from the outside and keep it valid at all times. Limitations and restrictions may sound like a bad thing, but in reality they are your best friend.
5) Learn how to use inheritance and how to design class hierarchies. It's a powerful instrument for writing type safe code and avoiding redundancy. It is also an instrument you have to learn to play well, because it can also quickly lead to bad design.
Speaking of bad design: C++ allows classes and functions to be 'friends' of other classes. That actually means breaking the encapsulation. Like feeling the need to use 'goto', it's a sign that you should rethink your design.
Oh, It's unbelievable that there are responses for my questions! Thanks for the suggestions, really! Actually, I have got the concepts things about C++, like objects, hierarchies things. I guess I am lack of some projects experiences. Even I got the concepts about it, I have no idea how to use them in programming. It might be the more practices make it perfect. I have to spend much time on it and use C++ times and times. Anyway, thanks a lot! Buy the way, I red effective C++ recently. It talks about STL and boost things. I almost program with BOOST and STL library every day. They are important for the C++, aren't they ?
Actually, I have got the concepts things about C++, like objects, hierarchies things. I guess I am lack of some projects experiences. Even I got the concepts about it, I have no idea how to use them in programming. It might be the more practices make it perfect.
You have sensed the trouble; lack of experience.
If you cannot apply concepts like object orientation, you don't really understand them yet. You should therefore stop saying, "I get the concepts." You should ask questions like, "How do I learn to view a project as a collection of objects?" or "How do I decide which operations are closely enough related to put into a single object?"
For the first question, I personally very much like the work of Rebecca Wirfs-Brock (search "Wirfs-Brock" on amazon) on class roles and collaborations. I used Designing Object Oriented Software to teach a team of C developers OOP, but I suspect the more recent titles are also good.
For the second question, much as been written on the web on "separation of concerns" and "dependency injection". But as a practical matter of learning, you should start writing module tests for each class you write. Nothing slims down your classes like having to test all the interfaces and import all the dependencies into each test case.
Thanks again. It 's quite boring reading book without implement project, isn't ? It was supposed to be a tool or a manual when I got some problem. I will follow your suggestion anyway, spending much time to read the book and practicing more~
It 's quite boring reading book without implement project
This is always the problem for learning. If you are lucky, some employer will let you learn on their time. Otherwise, there's nothing to do but try to think of some sufficiently interesting thing to code on your own time. Best of luck.
Actually, I have got the concepts things about C++, like objects, hierarchies things...Even I got the concepts about it, I have no idea how to use them in programming.
Well then you don't actually understand the concepts.
As I recall it took me about 2 years to figure out how to apply objects to designs in C++ after I figured out the syntax of classes in C++. Before that I was still doing structured programming rather than object oriented programming even though I was using C++ (and classes.)
I have a couple of suggestions based on my experiences. Although you may think you got everything, it's more likely that you don't. Practice says more than theory.
I remember myself that one day it hit me: "AHA!!!". It was like that, from one day to the other everything made sense.
The problem is that it's very difficult to get to the "AHA!!!" moment, but I do know that the fastest way to get there is by having real world experiences.
I don't think you should learn object oriented design through C++ as many of its little nuances can get in the way of learning the real deal which is object oriented design. I'd say to go with C# first if you want to learn OO design.
Now, there are a few steps I'd suggest you to take:
1 - Read open source code of well designed OO applications. If you look around it shouldn't be hard to find.
2 - Design a real OO application, with its own domain model layer, with all objects that contain both data and behavior, completely separated from user interface or data access layer. You can get a lot of ideas from open source projects and design pattern books. Try creating an application for someone you know that run a small business, for free, as an experimental project.
3 - Publish the code so people can give you their opinion and point out where you went wrong and where you did right. Here is where the real learning will occur.
4 - Port your application to C++
Just an idea of what I believe is a good way to learn OO C++
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
Oh~It's amazing that so much experiences and thanks for sharing. As you said, it 's the directly way reading some open source code instead of book, I will have a try to find some in communities. It's sure thing that I will avoid the open source code without documents, it 's really nightmare, isn't it ? For the 2nd tip, it 's out of my range, It might I am from a China... I have never thought about run a business, even it 's for free. But you are right. I must have a try. I will publish the code if everything is fine which I make a real project. Anyway, thanks! sincerely !
Exactly. Analyzing the business and its rules (which can get complex even in small business) can give you a better challenge than designing a zoo application (cat inherits from animal, etc).
Try getting these rules an transforming them in objects with data and behavior as if they were the living business. These objects should survive on their own once you feed them data, so no business logic on the UI!
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
yep, yep, yep!!! Some words like yours just hit my mind. "The objects in the project is more likely the real thing in the world, the code is better".Hah, My English is not that good and I try to represent the line... Whatever, your words are totally right, no doubt. BTW, should I spend some time to read some books like Design pattern and Software Engineering ?
Don't worry. It's really a lot of things you get to hear about and it all must be very confusing. That's why I told you to start with understanding the intentions behind object orientation.
The problem with all books, design patterns or libraries is, that they all solve problems you have not encountered yet. You can believe them or not, but simply using them as you are told will not help you understand more.
Start writing a small C++ program and try to do it with as little help as possible. Try to rely on what you have learned so far and do things as you think they should be. To be honest, you will probably run into problems every step on the way and your solutions may not be the best. Yet. The good thing is, that each problem will be an opportunity to gain some experience by solving it yourself.
At first this may be very frustrating, unless you keep in mind that this is just an excercise. Be proud of every victory, as small as they may be in the beginning, They will lead you to the things you must think about next and after a while books will become helpful again. Once you have understood a problem, you also have a chance to understand a solution.
Thank you for that! sincerely. You are 100% right about the intentions things. I should not study C++ for studying instead of real problem. Actually I encounter problems every day and I do my best to solve them. Even there are some problems I meet everyday but they are changed everyday, they are different. It means that my capacities get higher and higher day by day. It really make sense.
Boost and STL are great until you try to see what is inside the structures when the program crashes. Some debuggers are intelligent enough to be able to print the contents of collections. In many of them, it is just an undecipherable structure so you have to pick through the STL/Boost bit to see how it was implemented and then work out how to check the values in the debugger.
Picking through template libraries can be really painful: why do the writers insist on using one or two letter variables with leading underscores? Were these written by two finger typists?
For Martin Cheng: I would like to add that Points 2,3,4,5 are very, very important if you really want to get the most out of C++ and not fail later down the line. All of the points mentioned are aspects of "object oriented" analysis/design/programming and I would recommend learning this in parellel with C++ from good, well written, and proven sources. Booch, Yourdon, etc. and will almost certainly mean learning UML if you do not already know it depending on what books you pick up.
A good design book, & the "patterns" books by the gang of four and martin fowler, are especially handy to understand heirarchies and what C++ gives you above C, but be prepared to criticise and ignore them completely in practice if need be.
Finally, try desperately to get "real world" problems and practice, practice, practice. Small things like sorting algorithms, queueing mechanisms, even simple mutex controls, up to practical but low level tasks like neural net engines, file format conversion engines, etc (Concentrating on the core objects underneath the guis/cli). before you know it you will feel that nothing is impossible and nothing outside of your ability... It's a great language. go for it....
It's amazing suggestion I have to say! Everything including designation, programming skill, even testing and debugging skill are necessary in C++. It 's better to learn and use them in parallel, no doubt. I had just worked in new company for 5 months. Before that I have to say I jumped the jobs quite frequently and there were less exp in one field. I used to work in C, PHP, JS, embedded driver and etc. it 's embarrassed thing
The project of new company is about p2p media server, the arch is really huge! Many class, module, skill, library I have to know. First I attamp to make a UML diagram , is it useful for me ?
Coming from an Algol (60 and 68R) and C background, I started using C++ from version 1, as it seemed such an eloquent concept and made expressing problems for the computer so much more 'natural' for want of a better word.
I carried on developing larger systems, even through the mess the new iostreams and broken manipulators of version 2 made of my code, and the horrors introduced (inadvertently) into third party libraries by both compiler writer and library implementor misunderstandings of references.
However, in recent years, my aged and fading brain started to find it difficult to understand and even harder to remember how to use the ever increasing new features and complex semantics for the more esoteric aspects of the language, to the point where it was taking more work to understand how to use the language than it was to solve the problems I was working on.
At that point I started to switch to other languages: Java/AJAX for desktop/web development, and Python for general purpose stuff where speed was not an issue. I rarely do any C++ these days, though still do a fair bit of C when metal-bashing is required.
Perhaps I'm cutting off my nose to spite my face by not enthusiastically grasping C++0x (see: I can't even remember the correct ETLA for the latest revision!), but learning wonderful new concepts doesn't pay the bills...
Don't worry. Nobody gets younger. If I were to put together a team, I would go for as many veterans as I can get. I trust experience more than anybody's marketing promises or 'paradigm of the week'. If that makes them a little conservative, then so be it. C++ 11 does introduce new concepts (and one I would really welcome is postponed), but they are not forced on you. You can keep going as you did before. Along the way one or the other feature may prove to be useful for what you are doing and then you should not hesitate to learn more about it. There is no need to hurry.
You forget the Frankenstein-architecture: Sewn together roughly from bits of old legacy stuff, third party libs, and later add-ons, but hopelessly inadequate to fulfill the role it was intendended for, yet too expensive or difficult to be done all over again.
You may or may not like C++. But you can't just "turn away from .NET to C++". This is like you said "I am turning away from gasoline, since I do not want to depend on all of that oil stuff...". C++ is just a language, .NET is a eco-system of many languages, infrastructure, libraries, tools etc. If you rely on that, the language itself does not matter, but the presence of this infrastructure does.
I just deleted a very long response. Simple answer: Really, can't I?
Why should I allow Mickeysoft (or anybody else) to lock me into their walled gardens? Why should I pay for the OS, the development environment and a modest 30% developer tax on top of that for the honor of being allowed to publish my work? Why should I work more to keep my code current than to expand it? And what makes you think that there are no alternatives?
No, this time Mickeysoft has jumped the shark and nuked the fridge, all at the same time. I will rewrite my code only once more. To make certain that they can't do that to me again, no matter what crazy ideas they have next. Perhaps then I will see the day when a code module is actually reused instead of rewritten.
I reply to your message, although the answer applies to all comments.
No, you can't. "C++" and ".NET Framework" are just not compatible terms to compare, therefore you can't "switch" from one to another. .NET Framework is an implementation of a specification which defines an Application Development Framework plus the humongous infrastructure which enables to run the framework itself plus applications written against it. C++ is a language specification consisting of 1250 pages of text (*) at least my copy does. Its up to vendors to implement this specification but here the parallels are over.
I'd understand if somebody wrote "I am switching from .NET to Java" (which happens to be both language and AVR), or, to certain extent, "I am switching to native C++ development based on Qt". But in these cases, you are putting yourself in the similar position as before - you get dependent on somebody (**). Of course, you can write software based solely on C++ specification, but this is not really comparable to application development based on a infrastructure of the .NET Framework kind, not even comparable to writing software against an native C++ application development framework like Qt etc.
(*) ...written by masochists (**) The "open source" arguments also apply to .NET specification for which an oss implementation exists