hi happy coders. As of lately, i have a dilemma. I am learning C++ at the moment, with VS2005 and i'm asking myself if i should learn C# instead. I want to create simple tetris attack like games & a few system tools like a registry cleaner and/or tweak utilities (mostly low level). Could i use Windows Presentation Foundation for 2d games ? if so, could i do it in C++ unmanaged ? Or would C# suit me more, even though i want to do low level stuff too. Or should i learn DirectX (wich seems overkill for this)? Or should i use XNA (wich requires .net)? I really don't want to throw away my gained C++ knowledge :( Thanks for your time.

There's no rule saying you can only use one language at a time. Use C++ for the low level programs and do the rest in C#. If you don't like C/C++ window toolkits, then make the low-level functions in a C++ DLL then call them from the main C# program.

The problem is in the Microsoft documentation provided at the moment.
Most examples are C# examples, not C++/managed :(

I wanna learn WPF but with C++ ,if possible.

sadly, right now with c++ you are a bit out of luck when you want to use WPF. the ms c++ compiler is no capable of embedding compiled XAML into the executable. you can only load xaml from a file or (which is the currently recommended way of going about this) create all your xaml gui in concert with c# and derive a c++/cli class from that.
personall i 'd rather recommend sticking with c# in most cases. only when you're a lot more comfortable with native c++ or c++/cli (first one applies to me) or you really *know* you need c++ for the task at hand make a c++ dll and call that from your c# gui.
as for the applications you described i see nothing wrong with going c# all the way using WPF or not.
now, if you're setting out specifically to learn native c++ or c++/cli at the moment (unfortunately you didn't tell us if you're learning native c++ or c++/cli) you need to get familiar with dlls. of course, with c++/cli dlls are extremely easy to handle. either way i recommend to create your guis with a combination of c# and WPF.
don't forget about windows forms for simple windows tools (and more advanced tools, too!).

it's the AP again :)
after re-reading your post i gathered that you#re not really asking "what about wpf with c++". you were asking more along the lines of "what do i use to make my apps - and i want to learn c++".
if that is the case then i would recommend using windows forms with c++/cli. if you really want to learn native c++ then you will have to create dlls for the functionality of your applications and use them from a windows forms user interface. in that case using c++/cli for the gui makes no sense and i would suggest using c# for that.
it all depends on what flavor of c++ you want to learn. native or c++/cli. if you're just starting with developing windows applications then you should stay away from WPF for a while.. not because it#s overly complicated but because the tools aren't what they need to be for someone who is new to the field.

Just to add to anonymous post, with XNA your basically stuck with C# as well. However, if your clever enough, you can make it work with VB .NET and the other managed languages (Although its not supported or endorsed my Microsoft). The tools provided with XNA would allow you to easily implement a 2D version of tetris. You could use WPF for 2D games, however I feel that you may have some more flexibility with XNA since it was intended for game design. For the system tools, I'd defiantly check out WPF. Especially if your want to have a unique looking appliction.

a 3rd time.. i'm beginning to feel sorry...
regarding directx.. together with native c++ it is not easy. definitely nothing to begin with if you#re new to windows programming. managed directx and c++/cli or c# is quite a bit easier but i'd still say that for the stuff you want to do this is a bit much. at least for learning purposes.
if you specifically want to go in the direction of interactive games for windows, though, then toying around with directx (either managed or unmanaged) is required.. but again.. not easy. depends on your focus of interest. you *can* make those kinds of games with WPF. that's a choice you need to make based on in which direction you want to explore: windows tools, small games for casual consumption, 3d stuff.... once you 've made that decision you can narrow down a bit more what technologies to look into. there's no tool/language/api for everything.. you'll need to jump between them.

Thank you all for the opinions. It is much appreciated.
I look upon C++CLI as being the "port" language to .net.
From scratch, i'd prefer straight C# for managed development.

I want to develop simple system tools for windows with features found
in TweakXp and regcleaner and the likes. This pure for getting deep knowledge
of the underlying system. I dont know if doing this in a managed language
would be "natural" .

Secondly i want to create simple 2d games with AI opponents.
Creating tetris or bejeweled style games.

I am used to C style syntax and don't really like VB, maybe because it's
too different.

So, if i understand correct, i could write the "graphics engine" in WPF with c#
, wrap it up in a dll, and call it from a clr:mixed C++ project ?

EDIT:
OR, do it in straight C++/win32 with GDI+ ?
But, will i be able to do special effects like smoke and dust (dont ask why ;)) using GDI+? At least with win32 i can go as low as MS lets us in their
OS :)

Thanks again.

hi, it's the AP again.
as far as windows tools go there isn't a whole lot you cannot do via the managed APIs. Registry tools, cleaners etc can be accomplished with .net. If you want to dive down into the systems instrumentation you need to get familiar with WMI which is accessible from both native and managed - it's a bit easier to use from managed, admittedly.
If you feel the need of writing really system level tools i.e. metal level tools (hard drive destroyer +g+) you need to have some native code in your tool. For that c++/cli would be just fine. you could do the user interface in c++/cli (which is fine as your gui won't be too complex for a simple tool) and then simple add a few functions in native c++ which do the metal-level work. you simply declare a few functions as being unmanaged. no need for dlls there... and, yes, no need for c# there.
if you "only" want to do stuff that is accessible via the registry or WMI or similar technologies you likely won't need to use something different than c#.

regarding simple 2d games:
you could do it that way. write the graphics part in c# using WPF in a dll then call it from a c++/cli dll which does the actual work. however, in a small games such as a tetris clone the effort of splitting up the work seems a bit too much. you 'd be fine to just use c#. if you're more into creating a reusable component that leverages WPF which is then used by more than one project which are done in c++/cli you might want to go the dll route. i'd use the dll route, too, if for instance only s single element of your gui application needs simple (or not so simple) 2d/3d capabilities.
keep in mind that you can do your whole ui in WPF. so you would not only have the 2d display of your game be rendered by WPF but also the rest of the applications user interface (buttons, settings dialogs). if you go the c# dll route you need to commincate the settings made in the WPF dialog to the c++/cli executable. you'd be creating too much dependency for such little things that way. nothing 's stopping you from having settings dialogs etc displayed by c++/cli with windows forms though and only use WPF for the 2d game display. you have plenty of options there.. maybe too many for a beginner in the field.
To sum this paragraph up it all depends on the size of your project. If its a smaller project (tetris clone would be in that category) then i'd recommend sticking with c# and WPF. splitting up the work between a c#/WPF dll and a c++/cli exe might not be worth it and just introduces complexity. If, for instance, you're thinking of creating a computational instensive simulation in c++/cli and need something to visualize your algorithm then the c#/WPF dll route might be the right thing. With a simple 2d game you just don't have enough work for your c++/cli exe left to justify the extra effort. you need to strike a balance there.

regarding GDI+:
i'd say its safe to assume that gdi+ won't cut it any more. you *can* creating animated graphics with gdi+. maybe it would be even enough for a tetris game. but the performance of gdi/gdi+ is way behind the performance of fully 3d accelerated technologies like directx and thus WPF (contrary to what you seem to have expected). gdi+ is basically a pure software renderer (with some minor exceptions) whereas WPF is completely relying on the power of your gpu. for instance: you can easily do an animated cloth physics simulation in WPF with particles (you mentioned you need fog and effects). that is not within reach of gdi+.
don't forget about the other alternatives, though! :
you *could* combine WPF and DirectX or WPF and OpenGL or Windows Forms and DirectX or Windows Forms and OpenGL (4 options :))
For example, it would be feasable to have only the 2d display of your game be rendered by OpenGL. This rendering part of your application could sit in a native c++ dll. Then you build your game's gui using windows forms or WPF.. the buttons.. the dialogs.. the settings screens.. then you tell the native c++ dll to do all the game rendering in a specific part of your WPF or windows forms window. You would use XAML for the parts where it makes sense i.e. the gui of your application.. and you would use native c++ where it makes sense.. i.e. the (either opengl or directx) rendering part of your game. getting started with opengl and native c++ is quite easy in contrast to getting started with native c++ and directx. that could be a good route to take. i've chosen this route in a number of projects and it really comes together nicely.
just imagine: your 2d rendered game visuals cannot (well.. could.. but not intuitively) be defined by XAML. you'd have to manually code c# against the WP framework anyways. so all you'd be using XAML for would be the gui of your application (settings screen, buttongs.. i mentioned these). it makes sense to separate the game's gui and the actual 2d rendered game display.

to wrap this all up (i#M sorry for this long post.. but i thought about this exact problem you face right now quite a few times. this "what route do i take " question comes up quite a bit with people who want to dive into the new ms technologies):
you should take the following two aspects into account:
1. you want to learn c++. native c++ dll with opengl functionality which is being called by the WPF or windows application (described in last paragraph) could be a good route here. this allows you to mess with the new (WPF, windows forms c#) and the "old" (native c++ in concert with opengl) (i love the *old* c++, so don't start bashing +g+)
2. your game's size. for a small game (tetris clone, as i called it) it might not be worth all the fuss. you might be a lot better off to just use a single managed language (be it c++/cli or c#) and either managed directx or WPF. the last decision you could strike by evaluating if you really want to learn WPF and the "new world" of ms guis. now's the right time for that i'd say.

i'll shut up now :)
i hope i didn't confuse you too much. that has not been my intent. just wanted to show that you have options. quite a number of them ;)