Josh Petrie

C# is an excellent language to make tools in. The largest hurdle will be interoping with your C++ code base, if you actually need/want to do that. It sounds like you may be able to avoid direct interop for the time being and you may way to put off learning how to do that for a while if you do choose to go the C# route.

But it's an excellent language that I would definitely recommend learning -- it gets a lot of use building tools in the industry. Rarely, these days, is anybody writing complex GUI tools in raw Win32. Even if they stay with C++ they're usually using something like wxWidgets, et cetera.

This is not the thread to be debating whether or not Java is "fundamentally broken." Take it elsewhere, please.

Direct3D is a (mostly) COM based graphics API.

MDX is a now-deprecated wrapper for that API for accessing it from managed code, such as C#.

SlimDX is a modern, improved wrapper for accessing that API from managed code. It is not the same as MDX, however.

Those errors you listed confirm my hypothesis: you've got code that is written for MDX which is not compatible with SlimDX. You'll have to rewrite it.

You're doing something wrong.

If you want more detailed answers, ask more detailed questions (in other words, give us the exact errors and line numbers).

From a cursory glance I can tell you most of this code isn't going to compile because it looks like it was written to MDX, not SlimDX. SlimDX, for example, does not have a Direct3D object with a constructor like that. Nor does it support events at all. You also appear to have improperly copy-pasted (or worse, transcribed) this code, as you have weird fragments like "Format." floating around on their own lines.

SlimDX is not a drop-in replacement for Managed DirectX. You're going to have to rewrite the code that deals with the DX layer.

Quote:

I'd personally love to see more people describing what it's really like to be in the industry - tell some war stories, talk about technologies under development, etc. I'd do a lot of that myself, but I'm under some tight NDAs, so unfortunately I can't really talk about anything terribly interesting. (I am considering talking to the management about changing that, but I digress.)

As would I. I'd also like to feel more comfortable discussing work related problems openly; I'd love to see more company's support something like Insomniac's public R&D portal. I've been thinking about ways to approach the genesis of such a program myself -- so if you do talk to management, let me know how it goes.

It's more common that these situations that appear completely nonsensical are caused by something you're not noticing (corrupt debugging information, for example, can cause similar weirdness). What's the code look like? What's the generated IL look like (use Reflector)? Et cetera.

Quote:

But for future reference, if you think someone's wrong... please backup your statements with a little evidence, rather than just simply saying "you're wrong" about things.

You mean like you just did with all those links supporting statements concerning the plethora of C# patents and how much harder it is to "port C#" versus Java?

We're done here.

Quote:

It is Microsoft's attempt at patenting something that was already created. (YES, that is one reason why a lot of people hate them!)

The language isn't patented; I am aware of no attempts to patent the related patentable things either. In any case, I think it's foolish to assume -- in this day and age, that somebody patenting anything makes them "evil." Look rather at what they do with the patent -- with the glut of companies that exist only to patent things and try to make money collecting on those patents, other more morally grounded companies need to start patenting things purely as a defensive measure.

Quote:

1. Java can be ported to ANY computer, no matter what OS, hardware, etc. This includes portable devices such as cellphones & smartphones, and also computers much bigger than the average PC, like servers and mainframes and even supercomputers.

This is true of any language for which some kind of standardization, even a de-facto one, is available.

Quote:

As well, the C++ standard requires money to view.

You can, however, find drafts online... and for most people's needs those are pretty good.

Quote:

Josh Petrie, a member of these forums, is even working on a CLR for the Sony PSP.

And it does Hello World like crazy awesome.

Quote:

In essence, almost all of your points have been subjective, or factually incorrect. Posting such misinformation here on the For Beginners forum is a very bad thing to do, because you can mislead a beginner who is unable to distinguish the good information from the bad. This is why these sorts of topics are discouraged, since they rarely provide sound advice or guidance, and very often contain factual inaccuracies that can lead those who are new to programming astray.

Agreed. This thread is dangerously close to being completely useless, so let's all be very careful about what we post, hm? Think long and hard before you hit the button. Misinformation, derailing, and FUD makes my moderation trigger finger twitch.

Win. This is like the <dot> and <cross> "operator" hacks on steroids. I dare you to submit this to Boost.

Quote:

i doubt c# will replace c++ as the main gaming language, its not all about speed but also the fact that c# is bound to windows and the worst : you can decompile c# applications into their source code, and that's something you dont want.

Wrong. C# is not "tied to Windows' in any way, shape, or form -- no more than C or C++ are. C#, like C, like C++, is standardized by a third party body (ECMA, in this case). Microsoft has people on the advisory board for the standardization committee, but they do the same for C++ as well. So, that's a wash.

Thus, you have non-Microsoft implementation of the CLR and supporting toolchain for platforms other than Windows (see Mono). Just like C++.

Absolutely nothing about C++ makes it "magically portable" to platforms other than Windows and hardware other than PCs. Somebody has to put the sweat and elbow grease into porting the infrastructure. C++ only looks more portable because it's been around much longer (especially since it could piggyback on C in its early years). Given a few more years there's no reason C# wouldn't be just as widespread.

As for your decompilation concerns, they are slightly valid. Sure it's less than ideal to be essentially giving away your code, but there are obfuscation programs that can make it a little harder to read, if you care. Theoretically on fixed systems (consoles), one could pre-JIT (like ngen.exe) the CIL to native code, too. Again -- if you care.

Large developers typically have the legal backing required to litigate you into oblivion should you steal their code (remember, just because a thing is possible or easy doesn't make it lawful or morally correct). So that may be less of a concern for them.

And security? Security via obscurity is no security at all. It should be obvious that having the reverse-engineered C# from a tool like Reflector isn't going to be a big deal to hackers who can already crack native programs before they even hit store shelves.

Do some research next time.

Quote:

Original post by Ravyne I think the primary point the article was trying to make, and Josh can come along and correct me if he likes, is that...stuff

Yea, pretty much. The grand, overarching idea is, of course, the one get shit done. So certainly if the option exists to use an existing engine (either a full-spectrum game engine or something more specific, such as a rendering engine like Ogre), by all means, go ahead.

You can still build your own "engine" of reusable bits frameworks of code around something like Ogre just as well as you can build it around something like Direct3D, too.

Enable the debug runtimes, use unmanaged debugging, and call the overload of FromFile that takes "out compilationError" to examine any messages from the compiler.

Post the results -- particularly of any additional messages printed to the output window.

An SEH exception is a more generalized wrapper for a native exception the CLR could not directly map to a managed extension.

You're going to have to describe your problem in more detail. The only thing that sticks out so far is that the latest SlimDX release and SVN are both compiled against the August, not June, SDK. Beyond that, you should present the faulting code and a description of how your project differs from the working project to the faulting project (get a diff of the .csproj, to start).

I have a number of books by Aho and Ullman that I found useful. The "C++" part should be largely irrelevant, so I wouldn't neccessarily constrain yourself to that if you want a really good book.

Check Amazon, there are tons.

"Roguelike" and "tutorial" scares me -- most roguelikes of any pedigree have obscene code, which means a lot of new ones learn from that obscene code and make more obscene code (although perhaps slightly less so).

This tutorial isn't that good. I skimmed the first bit, because they were largely about basic roguelike concepts. I figured I'd review it if the rest of the tutorial turned out to be decent.

It started going downhill when we got to actual code. The author claims "Classes are quite literally the most important aspect of Object Orientated C++ programming," which suggests a fundamental misunderstanding of what object oriented design and programming is all about (classes are an implementation detail, at least as far as the "class" keyword is concerned). The author's initial stab at a "Character" class fails to achieve any kind of solid object-oriented design, so he should probably not be talking about OO at all in his tutorial. Also, the class may compile, but cannot be used (no definitions for the methods, and everything is private. Oops.)

He recommends Dev-C++. This is a terrible IDE backed by an outdated version of GCC. Not a good choice.

He finally gets to explaining "public access" to his classes in the next section, after making you jump through a bunch of hoops compiling stuff and claiming "things existed!" when really you accomplished nothing but, perhaps, instantiating some stack or global variables initialized to garbage.

He's going to have more problems with his ASCIIRoom class that returns from accessor functions by value, but does not provide manipulator methods to match those accessors (so you can't ever change the contents of a room)...

Okay, end of tutorial.

Over all, the code is not as terrible as I'd have imagined. The console drawing class he provides might be a useful starting point for somebody interested in building a roguelike. However, the tutorial purports to basically be a beginners C++ tutorial, and at that it fails miserably by moving far to fast, being far too verbose about things that are irrelevant, or going about things in a backwards or otherwise inefficient matter. Plus he uses poor tools. He did, however, at least stop harping on incorrectly about what is and is not "fundamental" to object oriented design, so that's another point in his favor.

Overall, I rate the tutorial as utterly dismissable, but the console class might be worth examining. He'd probably have written a better piece if he focused instead on how the console class was built, and how it worked, rather than trying like so many other barely proficient C++ programmers to "give back" to the community by writing a poor man's "learn C++" tutorial.