SilverScreen Solid Modeler

Notes for SilverC developers

Notes for SilverC developers

 Previous topic Next topic  

Notes for SilverC developers

 Previous topic Next topic JavaScript is required for the print function  

SilverSharpAPI

This section is for developers already familiar with SilverC, SilverPlus, or SilverEngine that are interested in taking up SilverSharp.

 

 

Because C# does not permit global functions or variables, that is public symbols declared outside the boundaries of a class, access to the SilverScreen API is through a sealed, abstract data type named SC. After referencing the SilverSharp assembly in your application, you may use the functions documented in the SilverScreen API by referencing them through the SC class of the SilverSharp namespace. For instance, here is a short piece of code making random calls into the SilverScreen API:

 

C# Code

 

 using SilverSharp;

 

 ...

 

 BLOCK_NODE root = SC.get_bos("\\") as BLOCK_NODE;

 

 MATRIX mx = new MATRIX();

 

 SC.tm_scale_x(0.5, ref mx);

 SC.tm_scale_y(0.5, ref mx);

 

 SC.panel_message("Welcome to SilverSharp");

 

 

For consistency's sake SDC chose to use the same data type names across development platforms. This means that an OBJECT_NODE in the SilverC platform and an OBJECT_NODE in the SilverSharp platform both represent a SilverScreen object entity. However, an OBJECT_NODE in the SilverC platform is a reference to a c-style unmanaged structure declared in ssnodes.h, and an OBJECT_NODE in the SilverSharp platform is a reference to a managed class declared in the SilverSharp assembly. They are logically consistent, but their implementation is very different. Likewise, the SilverScreen API functions that are part of the SilverSharp platform have parameters and return types that are CLR-compatible, but have preserved their names. Finally, many of the SilverSharp managed classes have been extended to work more naturally in CLR languages. The guiding principal behind SilverSharp was to keep the end-result as familiar as possible to existing developers, but not at the expense of  experienced CLR-language users.

 

There were rare instances when maintaining legacy syntax would hinder or confuse CLR-language users. One such instance involves string formatting as practiced in C# as opposed to as practiced in C.

 

The ss_command function that is part of the SilverSharp assembly uses the formatting style that is ubiquitous to C#, rather than the style that is practiced in C languages.

 

For example, in SilverC, SilverPlus, and SilverEngine platforms the following code draws a polygon:

 

SilverC Code

 

 #include "silver.h"

 #include "ssnodes.h"

 

 ...

 

 SS_XYZ p1 = { 0.0, 0.0, 0.0 };

 SS_XYZ p2 = { 1.0, 0.0, 0.0 };

 SS_XYZ p3 = { 1.0, 1.0, 0.0 };

 

 ss_command("begin polygon");

 ss_command("point %z", &p1);

 ss_command("point %z", &p2);

 ss_command("point %z", &p3);

 ss_command("end");

 

 

The same code, for the SilverSharp platform, would look like this:

 

C# Code

 

 using SilverSharp;

 

 ...

 

 SS_XYZ p1 = new SS_XYZ( 0.0, 0.0, 0.0 );

 SS_XYZ p2 = new SS_XYZ( 1.0, 0.0, 0.0 );

 SS_XYZ p3 = new SS_XYZ( 1.0, 1.0, 0.0 );

 

 SC.ss_command("begin polygon");

 SC.ss_command("point {0}", p1);

 SC.ss_command("point {0}", p2);

 SC.ss_command("point {0}", p3);

 SC.ss_command("end");

 

 

While experienced developers might argue in either direction, that is towards API consistency or towards language consistency, we chose to honor language consistency (for the same reasons that C# designers made the same decision).