#### Archived

This topic is now archived and is closed to further replies.

# C# and C++ and DirectX

This topic is 5092 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi im C++ to set a renderstate u do: Device->SetRenderState(D3DRS_ZENABLE, true); in c# Device.RenderState.ZEnable = true; So how come in C++ u cant do that? Yratelev

##### Share on other sites
SetRenderState is implemented as a method because it has to call into the driver to set things up. In C# it''s implemented as a property, which does other things behind the scenes than just setting the value.

It''s just different ways to do the same thing.

I like pie.

##### Share on other sites
What RenderTarget is saying is that in C++

Device.RenderState.ZEnable = true;

would only change a variable (it would set the field to "true"). That doesn''t run the code that needs to be run in order to REALLY enable that flag.

In C# (if I''m not mistaken because I''m a C++ guy) apparently an assignment can have code attached to it (probably the "=" operator is overridden.)

I suppose you could also override the "=" operator in C++ but that''s not how it''s done (historically) because C/C++ programmers don''t like things hidden from them in general. If they''re calling a function they want to KNOW that they''re calling a function because that implies significantly more overhead than a simple assignment.

As computers get faster-and-faster and programs get bigger-and-bigger, readability (C# and other "managed" languages) will slowly begin to win out over efficiency (C/C++). It''s already starting to happen in many areas of programming that can afford the overhead.

BTW, you might pick up a book on C and dig a little deeper into what goes on behind the scenes of object oriented languages. It''s pretty interesting and will broaden your understanding of programming.

OK, I''m coming down off of my soap-box now.

oki cool thanks

Yratelev

##### Share on other sites
quote:
Original post by TreborZehn
What RenderTarget is saying is that in C++

Device.RenderState.ZEnable = true;

would only change a variable (it would set the field to "true"). That doesn't run the code that needs to be run in order to REALLY enable that flag.

In C# (if I'm not mistaken because I'm a C++ guy) apparently an assignment can have code attached to it (probably the "=" operator is overridden.)

I suppose you could also override the "=" operator in C++ but that's not how it's done (historically) because C/C++ programmers don't like things hidden from them in general. If they're calling a function they want to KNOW that they're calling a function because that implies significantly more overhead than a simple assignment.

As computers get faster-and-faster and programs get bigger-and-bigger, readability (C# and other "managed" languages) will slowly begin to win out over efficiency (C/C++). It's already starting to happen in many areas of programming that can afford the overhead.

BTW, you might pick up a book on C and dig a little deeper into what goes on behind the scenes of object oriented languages. It's pretty interesting and will broaden your understanding of programming.

OK, I'm coming down off of my soap-box now.

I don't know C#, but I am 100% (EDIT: No, not 100%, but close) sure that nothing in the '=' operator is hidden there. In C++ DX, you can't just set values to variables because you are using the COM, and you have no access to any variables, only a functon table, so you have to use a "set" function.

[edited by - PlayGGY on March 4, 2004 7:20:54 PM]

##### Share on other sites
in c# you can define properties like this:
class C {....bool Enabled {    set {        // do aything you want after/before changing the flag        // the actual value is accessed by the keyword        // "value"    }    get {        // do anyhitng you want before returning the value        // in this case you have to return a bool    }}....}

This has been both accepted and rejected by the comunnity, some say that it provides easier code, some say that it limits the usability of the code because you don''t know if doing
cObject.Enabled = true is gonna be a simple member access or a complicated action also afaik you can''t overload them so you end having something like:
obj.Position = cPoint3D;obj.setPosition (cPoint2D);

rather than
obj.setPosition (cPoint3D);obj.setPosition (cPoint2D);

which is more consistent

##### Share on other sites
In that instance, you''d just define two properties, one with a CPoint2D type, and one CPoint3D. I''m not sure if you can overload the names though, I haven''t tried. Hm.

I love properties personally. The whole point is that you shoudln''t have to know what''s going on behind the call; it should just work. A property lets you design classes that can hide the details, so the user doesn''t need to learn some complex API just to use your classes.

I like pie.

##### Share on other sites
quote:
Original post by RenderTarget
In that instance, you''d just define two properties, one with a CPoint2D type, and one CPoint3D. I''m not sure if you can overload the names though, I haven''t tried. Hm.

Personally, I would write the CPoint2D type to implicit cast itself to CPoint3D. You would define an explicit cast to convert from a CPoint3D to a CPoint2D.

##### Share on other sites
Using a setXXX method hides the details also. but which is a more complex api:
void setPosition (Point3D point)void setPosition (Point2D point)void setPosition (int x, int y, int z = 0)

or

.Position3D .Position2D.Position3D = new Point3D (x,y,z) // equivalent of the 3 one

The problem of properties is that since you don''t actually know what the code is doing(if setting a member or performing an action) would you trust time critical code to use them?

##### Share on other sites
But isnt ''Position3D = new Point3D (x,y,z)'' more natural way?
You acually change its state (position in this case), and not doing some action on it (like you would if you call a function)...
Yeah, of course you dont know what is code doing, but you don`t know for:
''setPosition (x, y,z);''
either...

##### Share on other sites
The fact is that since the implementation of the class is hidden from you you don''t actually know how the position is stored internally, i have seen some classes where the position is stored as a 4x4(no sure if it was 3x3) for some computations they make, the new Point3D () approach would create temporary unneeded objects, now if some people use setXXX and others use XXX, after years of development the language will grow lexical inconsistences. Also using setXXX is more consistent with the idea that classes are logical units that manage themselves and any state belongs to the class

Anyway I''m not against properties, i was just stating the actual opinions about them.

##### Share on other sites
AFAIK, properties are supported both in Visual C++ and Borland CBuilder as:

class Object
{
public:
int GetSize() const { return this->size; }
void SetSize(int value) { this->size = value; }

__declspec( property( get=GetSize,put=SetSize ) ) int Size;

private:
int size;
};

int main()
{
Object obj;

obj.Size = 5;
obj.SetSize(5);

int size1 = obj.Size;
int size2 = obj.GetSize();

assert(size1 == 5 && size2 == 5);
}

[edited by - mishikel on March 11, 2004 12:47:00 PM]

##### Share on other sites
"The problem of properties is that since you don''t actually know what the code is doing(if setting a member or performing an action) would you trust time critical code to use them? "

The same ''problem'' exists with plain function calls.