hi !
i have a Data folder contain 2 file and some folders
Attachment 12314
how can i copy this folder ?
os:windows7...
Printable View
hi !
i have a Data folder contain 2 file and some folders
Attachment 12314
how can i copy this folder ?
os:windows7...
Well a crude way would be to call system() to invoke the xcopy utility.
Or maybe something based on this
CopyFile function (Windows)
does system() have any command to remove non empty directory?
system() is just a programmatic way of doing whatever you could do at a console command prompt.
There is no standard (yet), but Boost.Filesystem may be of help.
It depends on how much effort you're willing to put into solving the problem.
Sooner or later, API bloat stops and you have to start doing some things for yourself.
For example, you could read this
FAQ > Accessing a directory and all the files within it - Cprogramming.com
Throw in some
CreateDirectory function (Windows)
Add a liberal sprinkling of
CopyFile function (Windows)
Perhaps some
DeleteFile function (Windows)
and
MoveFile function (Windows)
for good measure.
You should do some reading to find out how compressed and/or encrypted files are dealt with as well.
tnx salem and elysia
i changed the win32 code(last example) and it seems to work and ofcource i dont know how!:D
FAQ > Accessing a directory and all the files within it - Cprogramming.com
would you recomend me a book for learning win32 ?
tnx
I would strongly suggest you go as far as you can with boost rather than going the Win32 route. Win32 is Evil™.
And if you want to do graphical user interfaces, you should pick up a GUI framework, such as Qt.
Avoid Win32 like the plague. It's convoluted, bloated and just extremely difficult to use. Plus it's C, and not C++, which strongly limits your effectiveness when using C++.
Well yes, but I mentioned the effectiveness. It limits our ability to express powerful and flexible code as we typically do in C++.
For example, for every resource we acquire, we must create some code to release that resource, be that some smart pointer + custom deleter or some new RAII object we write.
Or for example, for every callback, we are required to use a global or a static class member function which typically take some weird callback types which we have to cast back to proper types. We can't send a class member, some arbitrary function or functor or a lambda, all with correct parameter types for what we know the callback will receive.
I mean, it's like, if you are screwing screws and have an automatic screwdriver that works with those screws, why would you want to use a manual screwdriver, then? There is typically little point to "leaving" our rich and powerful universe unless we have a good reason for doing so.
In our "rich and powerful universe" we have to use third party libraries or APIs like boost, win32, or Qt to do little things like building a GUI, doing more than basic file handling, accessing databases, and a whole lot of things that are useful.
Win32, except for religious fanatics who intone that "Microsoft is evil" or "Win32 is evil" , is an option, no more. Like all of them, it has advantages and disadvantages.
I'm all in favour of doing things in standard C++ if at all possible, and am delighted that C++-11 offers more facilities and supports more techniques than previous versions of C++. But pragmatism is concerned with solving problems, not crouching in some some perceived state of perfection within some "rich and powerful universe". Not even the greats of C++ would advocate such crouching - they are mostly interested in how to get jobs done.
Incidentally, given that Microsoft is predominantly a C++ house, your characterising win32 as C is ironic. The C-like flavour of the win32 API is more about allowing it to be used across programming languages, rather than a homage to C.
I would argue that, unless there is something you cannot express in whatever language you are using and whatever libraries, frameworks and tools you are using, and you can express it in Win32, you should not use Win32.
On a purely opinion way, it is ugly as hell, a pain to work with and is just disgusting, being built on old and dull foundations (as opposed to "syntax rich" foundations), and on a practical note, it is much easier to shoot yourself in the foot and it just takes more time to get the job done.
That is, at least for a newbie.
Ah, you characterise yourself both as a newbie and as a religious fanatic, I see.
Given that newbies statistically have trouble grasping "syntax rich" foundations, I would suggest your argument is idealistic. Learning a bunch of syntactic features by rote is an effective way to get into trouble, and waste time doing it, and that is quite common for beginners (and, even a few too many teachers and authors). Pragmatically, if "old and dull" is useful to get the job done effectively, then use that. If "syntax rich" (or, in practice, specific syntax features) is useful to get the job done, then use that.
Having used both the new rich syntactic features in modern C++, as well as the old and dull things like win32, and even wrapping of old and dull things using modern techniques to get jobs done, my experience is not as black and white as you describe. In my experience, rich syntax is quite dangerous if it is used without sufficient understanding, and even more dangerous if support (eg compiler implementations) hasn't caught up - which it hasn't yet with some of the more latest features. Yes, there are problems with older APIs, but one of their virtues is that they are typically stable and better-documented so, with some care, are easier to understand and use.
Religious at least, I will admit. Though I try to ensure my arguments are backed up by facts. Still, I am as everyone else, not perfect. I make mistakes, and sometimes I let things go to my head.
Also, I have assumed or stated nothing about your experience. I don't do it on any senior members on the board. I know full well that there are a lot of seniors here who know a lot more than me, and there are a lot of them I look up to.
*shrug* Anyway, I have nothing more to add since you aren't really countering my arguments. Sometimes, it is hard to sum up cons and pros and to describe them in an easy way. Sometimes discussion is the only way to expose the "naked" truth about something.
i want to learn win32 for just deep learning i dont care if i would use it in future or not or how hard its to use and understand
why so rush ! i will learn how to use QT or sth else maybe after win32
and i found this books recomended on internet which one is better?or recommend another book if these are not good enough...
Programming.Applications.for.Microsoft.Windows.4th Ed.Jeffrey.Richter
Programming Windows - Win32 Api (Mspress, Charles Petzold, 5Th Ed)
tnx
Charles Petzold was suggested to me by everyone I asked about it! I haven't recieved my copy I ordered online yet, which is ironic since I just started trying to use another OS. I had trouble tracking down the book in person, but I have heard much about despite its age it was the "bible" on the subject of sorts.
I do agree with Elysia that: It is very difficult to understand from a beginners perspective. I have made multiple programs in Win32 and would still shudder at the idea of trying to do it without the documentation website open at the same time. There are just too many variables and functions with names that are just difficult to memorize since they lack a good reflection of what they do. Being a beginner myself I would say that I would prefer to not use it if I could. Though I see the point in understanding it and having some working knowledge in case I'm ever put in a situation where I"m going to have to use it.
I agree with Grumpy on the fact that it should be considered just as viably as any other solution for a given situation. Obviously in most situations zealetrous hatred for anything can turn out to be a blinding weakness.
Ultimately do what you want, just expect a few falls along the way.
I have not tried to counter your arguments, per se. I'm pointing out there are shades of grey, where you appear to have described things as only black versus white. You claim (and I paraphrase) that win32 is evil and should not be used. A counter to that (literally) would be to prove or demonstrate the opposite of your views (say, that win32 has the sort of perfection associated with saints and should always be used over alternatives). I have not asserted the opposite of your view, let alone tried to prove or demonstrate it.
No, actually, I didn't.
I mentioned that unless you have a good reason for not using Win32, then don't use it.
The reasoning is that, it will make you have to plunge into the world of C, and into the world of the nitty gritty Windows. We did not specifically use C to write out code, so why should do we so all of a sudden? If we wanted to write C, we could have chosen it from the beginning. True, C++ makes it rather easy to interop with C, but it nevertheless leads into a world with more bugs, and more pain. It also leads us into the world of Windows, which truly is Evil™. The API is huge, obscure and difficult to use. There is a reason why there exists many GUI frameworks--both for C and C++--to hide all these details from the user and make it easier to make graphical applications.
However, there are valid reasons for using Win32, or it would not exist. Just as goto is Evil™, so it both Win32 API. They are a necessary evil sometimes. For example, you must interop with some existing Win32 code. No library is probably going to do that. You absolutely and truly need the flexibility to do certain tasks. Sometimes you have some circumstances that prevents you from using libraries. Maybe your boss forbid you, etc, etc, etc.
Of course, this is purely from a practical point of view. There is nothing stopping one--nor should there be--to learn it just for fun.