Repository navigation
Expand file tree
/
Copy pathNEWS
More file actions
1085 lines (910 loc) · 50.7 KB
/
Copy pathNEWS
File metadata and controls
1085 lines (910 loc) · 50.7 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
************************************************************************
STEPcode
http://github.com/stepcode/stepcode
************************************************************************
Release 0.8 (December, 2014)
New since v0.7:
* handle diamond inheritance, derived Attributes
* rename fedex_python, fedex_plus to exp2py, exp2cxx
* many changes to the pretty printer, due to use in reformatting draft
and IS schemas (Thanks Tom!)
* parser was also changed due to errors caught while pretty printing
- we can be much more confident that the parser is correct now
* fix incorrect quoting of timestamp in p21 header
* fix various copy constructors and ShallowCopy() members
* split generated code into many small files
- far easier to open generated code in editors
- support more compilers
- small files are combined (via #include statements) into a few
large files for faster "unitary" builds, if the compiler can handle it
- unitary builds are faster than the previous builds
* most compiler warnings fixed
* performance fixes and other changes from BRL-CAD
* finally, all tests pass!
************************************************************************
Release 0.7 (April, 2013)
New since v0.6:
* Requires CMake 2.8.7 or later
* Replace *ALL* references to SCL with SC - CMake, source, filenames.
* Lazy loading code (src/cllazyfile)
* greatly reduces memory requirements and loading time when not all
instances are needed
* doesn't work with complex instances yet
* doesn't work on windows or 32-bit platforms yet
* Merged all BRL-CAD changes; now, we can work on the same repo.
* Eliminate compile-time dependency on a lexer and parser
* When lexer/parser changes, use LEMON/RE2C/Perplex (in BRL-CAD repo)
* Fixed several bugs in the class libraries that cause segfaults
* update AP209, 210e3, 242, IFC2
* Fixes for MSVC, Embarcadero (there are still problems with both:
see comments on #178 & #190, also import/export macros)
* Fixed NIST test executables
************************************************************************
Release 0.6 (May, 2012)
New since v0.5:
* Renamed from STEP Class Library to STEPcode, moved to github.com/stepcode/stepcode
* Advances in [Python](http://github.com/stepcode/stepcode/wiki/python-generator) support (#185)
* ABI versioning
* Implement memory manager with reporting of memory that isn't freed,
fix many memory leaks (#148, #160, #162, #168)
* MSVC fixes (> 128 nested if...else - #152), etc
* Add AP219, AP238, PDM schema, AP203a1, syntax highlighting files
* Improvements to CMake files, mostly from Cliff @ BRL-CAD (#143, #163, #181)
* Allow runtime bounds for aggregates (discovered with AP209e2) (#166)
* exp2cxx fprintf's can be traced with -DSCL_TRACE_FPRINTF=ON (#176)
************************************************************************
Release 0.5 (Feb 23, 2012)
New since v0.4:
* MSVC and Embarcadero support, along with many warning fixes
* Experimental Python support
* Now handles most features of EXPRESS - all included schemas,
with the exception of AP209 CD, are parsed without error. Enums are
now in their own dictionary. Allow indexing on aggregates, generics,
and binaries.
* Changes to exp2cxx that improve the generated c++ - use a
namespace, break up large static strings, make EXPRESS multiple
inheritance work by not printing multiple copies of inherited members.
All schemas now compile without error, but there are numerous warnings.
* Exchange files: handle all comments, fill in some missing attributes.
* More cleanup of source code, more documentation in scl/doc
* Special thanks to @davyw and @tpaviot for their large contributions
(MSVC and Python, respectively)
************************************************************************
Release 0.4 (Nov 13, 2011)
New since v0.3:
* Improve p21read performance by ~30%
* Improve exp2cxx performance by ~4300% (!)
* A variable defined in a LOCAL is not required to have a type label
(affected ap242,210e3,209)
* Enums and entities are allowed to have the same names
(affected ap242,210e3,209)
* Remove the SCLP23 macro
http://github.com/stepcode/stepcode/wiki/changelog-v0.4
************************************************************************
Release 0.3 (Oct 29, 2011)
What's new since v0.2?
* Start using CTest
* Add a number of schemas, update IFC2X4 to RC3, update AP235 to TC
* Update the exchange file header schema to edition two; drop support
for N279 files
* In p21read, check that the schema name for the file and library match
* Fix bug with exchange files that contain strings ending in 'S'
************************************************************************
Release 0.2 (Oct 1, 2011)
What's new since v0.1?
* Retrieve aggregate type from the underlying type (issue #4)
* Fix aggregate select types naming convention in exp2cxx (issue #59)
* Fix several segfaults and double free's in p21read (issue #63)
* Fix several file read/write bugs in p21read, including
* don't write '$' for empty string
* 'abc\S\'def' is a valid string (issue #57)
* Improve p21read execution time
* Cleanup many files and delete src/clivfasd (but much more to do!) (issue #66)
* Add BNF files, schemas, and CAX-IF Part 21 files
For a detailed list of changes, see
https://github.com/stepcode/stepcode/wiki/changelog-v0.2
For a list of closed issues, see
https://github.com/stepcode/stepcode/issues?state=closed&milestone=2
************************************************************************
Release 0.1 (Sept 2011)
What's new since the SCL 3.2 release in 1998?
===========
* CMake build system replaces the configure script, Makefiles, and bash
scripts that were used by NIST. CMake is far easier to maintain and is
cross-platform.
* Support for formats that are no longer in the STEP standard
(ObjectStore, CORBA) has been disabled.
* Fix some bugs that were found when testing SCL with modern schemas,
including spaces inserted into function names and use of outdated
functions
* Bring SCL closer to alignment with modern coding standards - replace
String class with std::string, fix all GCC warnings
* Builds on Linux, OSX, and Windows; requires mingw on Windows.
* Add debugging option -d 9 -l nnn -u nnn to exp2cxx. This limits
parser debug output to a specified range of lines in the schema.
For a detailed list of changes, see
https://github.com/stepcode/stepcode/wiki/changelog-v0.1
For a list of closed issues, see
https://github.com/stepcode/stepcode/issues?state=closed&milestone=1
Pre-BRL-CAD changes:
* Patches from http://www.statik.tu-cottbus.de/fileadmin/project_dth/scl/
Jan 2005 - Mar 2006
* STEP Class Library Release 3.2 February 1998
* STEP Class Library Release 3.1 October 1997
* STEP Class Library and Data Probe release 2.1 June 1995
************************************************************************
************************************************************************
--Original NEWS file follows--
************************************************************************
************************************************************************
Updates from http://www.statik.tu-cottbus.de/fileadmin/project_dth/scl/
Jan 2005 - Mar 2006
The original SCL source distribution could not be cleanly un-archived
on case-insensitive file systems like Windows' NTFS because of a name
conflict.
SCL is mainly written in C++, but it also contains C sources, lex and
yacc sources (compatible to flex and bison) and csh and sh scripts.
The C++ sources, written in the 1990s, are not fully compliant to
ANSI/ISO C++. Updates have been made to base parts of SCL to ANSI/ISO
C++ (only the SPF interface, not the complete database system
interfaces or the dataprobe GUI). Some problems were also addresses
with newer UNIX-like systems.
There were also some issues with the configure script and some
makefiles which are addressed, as well as a new macro that is at
least required for gcc.
Remaining problem: The p21 file scanner of SCL currently
does not allow for comments within the parameter list of
data records. Only comments outside of data records are
accepted.
DISCLAIMER: Use at your own risk. These patches are
incomplete, may be incorrect, and are not endorsed
by NIST.
************************************************************************
What's New in the STEP Class Library Release 3.2
February 1998
mkProbe now prints a usage message showing allowable command line
arguments when it is run without arguments.
Extended the EXPRESS Pretty Printer:
- added command line options -a and -A to the exppp executable to
specify that the output should be alphabetized. Without the -a option
the order of the TYPEs and entities in the original EXPRESS is
preserved when pretty printing an EXPRESS file.
- Fixed a bug in the exppp toolkit where it would crash when handling
PROCEDUREs in EXPRESS.
- Extended the NIST Pretty Printer Toolkit to provide string and
buffer representations for EXPRESS USE and REFERENCE statements, and
for providing access to the EXPRESS SUPERTYPE statements.
Extended the STEP Class Library Toolkit capabilities including:
- adding additional dictionary constructs for representing EXPRESS:
SUPERTYPE statements, WHERE rules within entities, USE FROM clauses,
REFERENCE FROM clauses, global rules, PROCEDUREs, and
FUNCTIONS. Information about these objects is available but validation
based on it is not performed.
- enhanced exp2cxx C++ code generator to generate the necessary
dictionary objects for the above EXPRESS constructs for a particular
schema. Also enhanced schema dictionary code generation to add
information necessary to generate an EXPRESS schema (i.e. which
entities, types, global rules, USE and REFERENCE statements, etc are
associated with which EXPRESS schema dictionary object).
- added capability to generate EXPRESS from the above dictionary
constructs (e.g. USE, REFERENCE, global rules, functions, procedures,
etc.) and the existing dictionary constructs for EXPRESS schemas,
types, entities, and attributes.
- Fixed a bug in the casting functions for the classes handling
instances of SELECT TYPEs in EXPRESS.
e.g.
SdaiMeasure_value::operator SDAI_Real)(
{
// was missing stmts such as these...
if( CurrentUnderlyingType () == config_control_designt_area_measure )
return _real;
if( CurrentUnderlyingType () == config_control_designt_context_dependent_measure )
return _real;
}
- Fixed an aggregate element TypeDescriptor (TD) pointer problem in
the dictionary. The TD pointer in the aggregate dictionary entry is
supposed to point at the TD representing the element type for the
aggregate. It pointed at the underlying or base type's TD (e.g. the TD
for STRING) instead of for the type which was specified in the EXPRESS.
For example where it should have pointed at a TD for a TYPE label -
where label is defined as TYPE label = STRING; END_TYPE - it pointed
at the TD for STRING. The TD for the aggregate element now points at
the TD for label.
- Fixed the casting operator for the class representing EXPRESS
enumeration types. It was returning the last element of the enum type
as the default when the enum was unset. This choice predated enums
having an unset enum value. It now returns <enum_name>_unset as the
default when the enum is unset.
- cleaned up a bit of leaked memory. The memory leaked was mostly
handles to static memory.
- sdaiString not reading a value '' properly.
- sdaiString copy constructor mixing up undefined and unset values.
- dictionary objects handling and writing WHERE rule and UNIQUE rule
comments in EXPRESS. Added a data member
SCLstring _comment; // Comment contained in the EXPRESS.
to classes Where_rule and Uniqueness_rule. Also they have functions:
SCLstring comment_() const { return _comment; }
void comment_(const char* c) { _comment = c; }
to manipulate them. When writing EXPRESS for entities and types the
keywords WHERE and UNIQUE are only written if there are actual
rules. If there are only comments the keywords are written as a
comment.
**********************************************************************
What's New in the STEP Class Library Release 3.1
October 1997
The following is a list of enhancements which are found in the version
3.1 release of the SCL and Data Probe. It assumes you are familiar
with EXPRESS (ISO 10303-11). Familiarity with version 2.1 or higher
is a big plus.
-------------------
Easier Installation
-------------------
We created a script called configure using gnu's autoconf software.
The configure script is used to install the SCL release. Configure
automates the editing of multiple SCL files based on site-specific
information needed for installation. It performs checks against the
software and operating system environment to create a header file used
by SCL to handle commonly known software porting problem areas.
Finally, it builds all the SCL executables, scripts, and libraries.
Configure requires one command line argument specifying a name which
is used to create a directory. Configure installs the architecture and
environment specific SCL executables, scripts, libraries, and object
code is under this directory.
Configure accepts optional command line arguments to install the SCL
for use with optional software packages (like Orbix and/or
ObjectStore) and for use with different compilers on different
operating systems and/or machine architectures. Configure may be
executed several times to create several SCL builds under separate
architecture/environment specific directories. Each of these
directories is based on the same source code directory to minimize
space requirements. This is possible because the SCL source code was
created with preprocessor switches which allows the same source code
to be built for different purposes. Separate builds are also necessary
to use SCL with different C++ compilers since C++ object code is not
compatible between C++ compilers.
-----------------------------------------------------
Alignment with the C++ Binding (ISO 10303-23) to the Standard Data
Access Interface (SDAI, ISO 10303-22)
-----------------------------------------------------
SCL has been better aligned with the C++ binding (ISO 10303-23,
a.k.a. STEP Part 23) to SDAI. This has involved several name changes
for classes implementing base EXPRESS types and application-schema
defined EXPRESS types. The name changes were possible since these
types and classes have been moved to be encapsulated by a namespace
implemented via a struct definition. The namespace has been defined in
a way that offers great flexibility in avoiding name conflict with
other software packages (like X Windows, CORBA implementations, etc)
and your application code. The namespace name is easily changed if
necessary. As a result of adding a namespace a noticeable difference
in SCL use has occurred.
Use of underlying SCL classes and types are now wrapped in macros that
are defined in the file sclprefixes.h. This file is installed under
the arch directory which allows it to be adjusted as necessary for
each SCL software installation. For example, if a compiler or software
package has a problem handling the namespace mechanism via a struct
definition alternate macros can be used from the sclprefixes.h file
bypassing the namespace altogether. If a name conflict occurs when the
namespace is turned off macros can be used that add a name prefix to
SCL types and classes. Use of the macros when using SCL types and
classes is what allows for the flexibility in dealing with problem
areas when using SCL with other software.
An example of a name change and macro use: sdaiString has now become
SDAI_String which could translate to SDAI::String or SDAI_String
(depending on whether you use the SDAI namespace or not) or any other
namespace or prefix as is necessary. To change the SDAI namespace name
or prefix name the macro definition for SDAI_ could be changed in
the sclprefixes.h file.
The early bound access functions that are generated by exp2cxx from
EXPRESS defined entities have been updated to the latest version of
Part 23's C++ binding to SDAI. A previous early bound function defined
as "const SdaiLabel Name()" would now be defined according to Part 23 as
"const SdaiLabel name_()". *notice* that application schema defined
types are not yet defined in a namespace. Compatibility with previous
versions of SCL early bound functions has been maintained via the -a
exp2cxx option.
-----------------------------------------------------
SDAI Session Schema objects implemented (model_contents, extents, etc)
-----------------------------------------------------
Several classes and types defined as part of SDAI Part 23's Session
Schema have been implemented (where before they mostly had stub
functions). These have been implemented for use with or without the
ObjectStore object oriented database. Model_contents_<schema_name> is
now being generated by exp2cxx allowing Entity_extents to be
maintained for entities as desired.
-----------------------------------------------------
Object Oriented Database Capability Using ObjectStore
-----------------------------------------------------
SCL has been enhanced to optionally use the object oriented database
ObjectStore from ODI. The INSTALL file describes how to build the SCL
libraries for use with ObjectStore. The SCL libraries built for use
with ObjectStore may then be used to create persistent or transient
SCL objects. The transient objects use the ObjectStore transient
database.
The SCL application, fedex_os, uses an application schema written in
EXPRESS to generate additional code needed for use with ObjectStore.
Fedex_os is used in conjunction with exp2cxx for generating the C++
necessary to implement your application schema.
Although building SCL libraries for use with ObjectStore is
documented, instructions for building your application with SCL
libraries and ObjectStore is as of yet undocumented. The undocumented
steps for building an SCL/ObjectStore application are the steps
required to build any ObjectStore application. A person familiar with
building ObjectStore applications should be able to create a Makefile
able to perform these necessary steps.
A good starting point for creating a Makefile suitable for building an
SCL/ObjectStore application would be the Makefile generated using the
mkProbe script. The configure script (executed with the ObjectStore
options) generates a make_rules file which contains the necessary
Makefile macros for using ObjectStore. The mkProbe generated Makefile
already includes this make_rules file. The Makefile is set up to build
a simple application which uses the appropriate SCL and ObjectStore
libraries. The Makefile rules for building this application could be
used as a starting point for creating Makefile rules to build your own
SCL/ObjectStore application. (The example application code is not set
up to use ObjectStore.) Additional steps would need to be added to run
the ObjectStore schema generator (ossg), link with the additional
application-specific ObjectStore object files, run os_postlink, etc.
-------------------------------------------------------
Use of Orbix with SCL for Developing CORBA Applications
-------------------------------------------------------
SCL has been enhanced to be able to use Orbix for developing SCL
applications for use within the Common Object Request Broker
Architecture (CORBA). CORBA is used to provide an architecture for use
of objects within a distributed environment. Distributed communication
occurs by client applications communicating with servers through
Object Request Brokers (ORBs). Clients may be written to use any
number of programming languages provided the CORBA software vendor
(Orbix in this case) supports the language. We have only tested
clients written using C++. We may soon test JAVA clients.
The SCL application, fedex_idl, is used to create an Interface
Definition Language (IDL) schema from your application's EXPRESS
schema. The generation of IDL schemas by fedex_idl is according to
STEP's Part 26 Interface Definition Language binding to the SDAI. The
Orbix IDL compiler is then used to generate the client and server code
necessary for communication through an Orbix ORB. The SCL application,
exp2cxx, would then be run with the -c option on your application's
EXPRESS schema to generate the server implementation objects required
to build an Orbix server (it uses the TIE approach). You would be
required to write the C++ main() function for the server code.
Although building SCL libraries for use with Orbix is documented,
instructions for building your application with SCL libraries and
Orbix is as of yet undocumented. The undocumented steps for building
an SCL/Orbix application are the steps required to build any Orbix
application. A person familiar with building Orbix applications should
be able to create a Makefile able to perform these necessary steps.
A good starting point for creating a Makefile suitable for building an
SCL/Orbix application would be the Makefile generated using the
mkProbe script. The configure script (executed with the Orbix options)
generates a make_rules file which contains the necessary Makefile
macros for using Orbix. The mkProbe generated Makefile already
includes this make_rules file. The Makefile is set up to build a
simple application which uses the appropriate SCL and Orbix
libraries. The Makefile rules for building this application could be
used as a starting point for creating Makefile rules to build your own
SCL/Orbix application. (The example application code is not set up to
use Orbix.) Additional steps would need to be added to build the
additional server code you would need to write, register the server
with Orbix, build and link with the IDL compiler generated code, etc.
-----------------------------------------------------
Use of Orbix and ObjectStore with SCL
-----------------------------------------------------
SCL has been enhanced to be able to be used with Orbix and ObjectStore
providing a persistent server for use within a distributed CORBA
environment. We have used SCL in this way for two NIST projects: the
National Industrial Information Infrastructure Protocols project and
the National Advanced Manufacturing Testbed Framework project.
Once again, although building the SCL libraries for use with Orbix and
ObjectStore is documented (via installation using the configure
script), instructions for building your application to use Orbix and
ObjectStore is as of yet undocumented. See the previous two sections.
-----------------------
MULTIPLE SCHEMA SUPPORT
-----------------------
A library and Data Probe can now be generated for an EXPRESS file
containing multiple schemas. This is done primarily by dividing the
source code generated by exp2cxx into separate files. Separate
files are generated for each schema contained in the EXPRESS file. In
addition, often schemas are dependent on one another. This will be
the case if the schemas use and reference entities and types from each
other. If, for example, entity X in schema A is a subtype of entity Y
in schema B, X will not be processed until B in schema Y is processed.
Other such cases of interdependence occur if an entity in schema A
contains as an attribute an enumeration or select type defined in
another schema. To address such cases, exp2cxx may process a
schema in multiple passes. At each pass, only the objects in the
schema which are not dependent on not-yet-processed objects in other
schemas are processed. At each successive pass through the schemas as
more and more objects are processed, more and more dependent entities
will become processable. Certain schemas may require three passes or
more in cases of chains of dependence (such as A being a supertype of
B which is a supertype of C, etc.).
For an EXPRESS file with multiple dependent schemas, it is advisable
to organize the file with bottom-up design. Schemas containing the
simpler, building block types and entities should appear first. By
doing so, when exp2cxx begins processing the more complex schemas,
there will be fewer cases in which the parser will encounter not-yet-
defined objects from other schemas. (The objects which are referenced
the most will have already been defined.) This will minimize the
number of times exp2cxx is required to divide output files.
One known case of interdependence which exp2cxx is not able to
support occurs if say select A has select B as an item, and select B
has select A as an item. (This is unsupported even if A and B are in
the same schema.) exp2cxx has no way in which it can generate
compilable source code for the selects because each is dependent on
the other. In addition, this would cause the parser to fall into an
endless loop, so we strongly discourage it. ;-)
------------------------------
USE / REFERENCE CLAUSE SUPPORT
------------------------------
The SCL also partially supports the EXPRESS concepts of USE and
REFERENCE. According to the rules of EXPRESS, schema A may reference
objects from schema B by way of a USE or REFERENCE clause (U/R). Any
object which is not U/R'ed from schema A to B, directly or indirectly,
is not visible to B. The SCL does not support the hiding of objects
between schemas. Basically, an object defined anywhere in the SCL is
visible everywhere else. What is supported is renamings of objects
between schemas. Say schema B uses entity X from schema A and renames
it to Y (i.e., "USE from A (X as Y);"). If a Part 21 file is read in
or written out using the SCL or the Data Probe, if the "current"
schema is defined to be B, the renamings defined by B's U/R statements
will be used. The "current" schema is set according to the first
schema listed in the FILE_SCHEMA section of the Part 21 file's header
section. (It is assumed that I/O is being done with the SCL's
STEPfile object.) If no current schema is defined, all possible
entity and type names are recognized in file reading, and the original
names only are used in writing.
As mentioned above, the SCL does not support the hiding of objects of
say, schema A, which are not U/R'ed by schema B. Thus, it's possible
to use the SCL or Data Probe to read or write a Part 21 file in which
A is the current schema and which contains instances of entities which
are not U/R'ed by A. This will not be flagged as an error.
The U/R clause is more poorly supported by the Data Probe. When the
Probe displays instances of entities, only their original names are
displayed. (This also applies when an entity has a select attribute
and the current choice of the select is being displayed by name. For
example, if a select is set to HEIGHT(35), the original name of
`HEIGHT' is displayed even if we're in schema B which renames HEIGHT
to LENGTH.) When a user is using a <<step entity editor window>> to
create an instance of an entity, all possible names for a type are
recognized. This includes the original object name plus all names
given to it by other U/R'ing schemas, regardless of the current
schema.
Another shortcoming with the U/R support is related to the fact that
the SCL does not allow objects of the same name in different schemas.
For this reason, U/R support is also limited to cases where the new
name is unique within the entire EXPRESS file.
Lastly, the U/R support is unable to deal with aggregate types of
two or more dimensions. Say we were attempting to instantiate a 2D
aggregate of selects. Type names will appear in the inner select
instantiations, and they should be set according to the current
schema. However, since the SCL currently does not fully support
higher-dimension aggregates (it uses the SCLundefined class and
considers the entire instantiation a string), it's impossible to
verify the values within the aggregate instance.
----------------------
COMPLEX ENTITY SUPPORT
----------------------
By complex entity, I mean ones which require external mapping (see Part 21,
section 11.2.5).
New Features
------------
(I really think the structures and functions I used to support this
are a recursive work of art. Too bad it's all invisible to the user.)
1. The primary enhancement now included is the checking of the
legality of complex entities. If a user attempts to initialize a
complex entity (class STEPcomplex), the SCL will determine, based on
the supertype and subtype information of the EXPRESS, if the entity
represents a legal combination of entities. If not, an error message
will be issued, and a complex entity will not be created. Formerly,
the SCL would only check if the entity names themselves were valid and
not worry about the combination.
2. Non-independent entities cannot be instantiated. These are
entities which cannot be created without external mapping. Say we
have,
ENTITY A SUPERTYPE OF (B AND C);
The SCL would not accept an instantiation statement such as,
#11=C(xx,yy,...);
C requires external mapping since it can only exist together with B,
in a statement such as,
#11=(A(...)B(...)C(...));
If a user attempts to create a C with internal mapping using the
STEPfile object (the class which handles all reading and writing of
Part 21 files within the SCL), an entity will not be created and an
error message will be issued. The SCL behaves similarly if a user
attempts to create an instance of an abstract supertype.
The above behavior is also reflected in the Data Probe. All entities
which are abstract supertypes are marked with an `*' (as in SCL vn.
2.1). Entities which cannot be instatiated without external mapping
are marked with a `%'. Neither can be created using the Data Probe.
(The Probe does not have the capability of creating complex entities,
see below, next section.)
(Note: A user can instantiate an entity such as C from the STEPentity
level, bypassing STEPfile. STEPentity will allow the initialization
but will place a warning in its errorDesc field.)
3. exp2cxx may be compiled with the flag COMPLEX_INFO. If this
flag is turned on, exp2cxx prints out (to `cout') a large amount of
detail on the complex entities it finds and their overall structure.
This is useful to see how fedex interpreted the complex information of
an EXPRESS file, and to get a simple graphical view of the supertype-
subtype hierarchy of the file.
exp2cxx's makefile contains the commented-out line,
#USER_DEFS = -DCOMPLEX_INFO
If this line is uncommented, a exp2cxx executable will be built
which prints such information.
Limitations
-----------
1. As in multi-schema support (above), complex entity (CE) support is
not completely reflected in the Data Probe. This may be seen in a
number of instances (you can skip this if you don't intend to use the
Probe):
(a) It's impossible to create an instance of a CE using the Data
Probe. (See point #2 under "Complex Entity Support").
(b) The Data Probe is able to correctly read a CE from a Part 21 file,
and place a copy of it in the Entity Instance List Window. It also
allows the user to edit the values of the entity's attributes by
selecting the entity (from the Ent Instance List Win) and creating a
STEP Entity Editor Window. The Data Probe, however, does not accu-
rately display the type information of the CE (in the Type Information
Window). What it does do is takes the name of the 1st entity in the
list (CE entity names are displayed alphabetically) and shows the type
info for that entity.
2. The SCL does not read partial complex instances. Generally, if a
single entity-member of a complex entity has an error, the entire rest
of the complex entity will be skipped.
3. If entity members of a complex entity have been renamed (through
the EXPRESS USE/REF clause - see previous section), they are read and
written properly. However, the SCL may not write the members of the
CE in alphabetical order (as required by Part 21, sect 11.2.5.3). The
individual entities are sorted according to their original names. If
the renaming of an individual entity places it out of order, the nodes
will be printed out of order.
4. "Diamond inheritance" is not handled automatically and must be
fixed by hand in the code generated by exp2cxx. (See
whatsnew.2-1.txt, section "Multiple Inheritance".)
5. Selects between aggregates: A select containing two aggregate
choices of the same type (e.g., ARRAY and ARRAY, as opposed to ARRAY
and SET) will cause exp2cxx to generate code which cannot be
compiled.
6. Problem with sparcworks compiler version 4.0(?) - operator int() =
op enum(). This happens in the following case... Both functions,
however, are required by Part 23. We fixed this by removing enough
functions for it to build. We were not sure if this error is the fault
of the sparcworks compiler or is a problem with the standard.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!DISCLAIMERS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Names of companies and products are provided in order to adequately
specify procedures and equipment used. In no case does such
identification imply recommendation or endorsement by the National
Institute of Standards and Technology, nor does it imply that the
products are necessarily the best available for the purpose.
NO WARRANTY
===========
NIST PROVIDES ABSOLUTELY NO WARRANTY. THE NIST STEP TOOLKIT
IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS
WITH YOU. SHOULD ANY PORTION OF THE NIST STEP TOOLKIT PROVE DEFECTIVE,
YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR, OR CORRECTION.
IN NO EVENT WILL NIST BE LIABLE FOR DAMAGES, INCLUDING ANY LOST
PROFITS, LOST MONIES, OR OTHER SPECIAL, INCIDENTAL OR CONSEQUENTIAL
DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE (INCLUDING BUT NOT
LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE, OR LOSSES
SUSTAINED BY THIRD PARTIES, OR A FAILURE OF THE PROGRAM TO OPERATE
WITH PROGRAMS NOT DISTRIBUTED BY NIST) THE PROGRAMS, EVEN IF YOU HAVE
BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM BY
ANY OTHER PARTY.
**********************************************************************
What's new in the STEP Class Library and Data Probe release 2.1
June 1995
This release of the STEP Class Library (SCL), exp2cxx code
generator, and Data Probe also contains the latest releases of the
fedex syntax and semantic checker, the NIST Express Toolkit (also new
on SOLIS as of June 12, 1995), and the Express Pretty Printer Toolkit.
The NIST Express Toolkit and fedex have been updated to handle the IS
version of Express and various problems have been fixed as a result of
pre-validation conformance testing. Following is an overview of
what's new in the STEP Class Library (and hence exp2cxx) and the
Data Probe.
--------------------
*Compilers supported:
--------------------
The SCL and Data Probe now compiles with gnu C++ v2.5.8, v2.6, and
Sun C++ v3.0.1. The SCL also compiles with ppCC, the pre-processor of
the Open OODB from TI.
-------------------
*Complex Instances:
-------------------
The SCL now supports instantiation of complex instances via a class
called STEPcomplex. The SCL supports reading and writing of complex
instances from/to Part 21 and Working files using the external mapping
specified in Part 21.
Complex instances are created by calling the constructor for
STEPcomplex with a list of entity name strings. The combination of
entity names that are passed in to become part of the complex instance
are not validated to determine if they are a legal set of entities
with regard to the inheritance structure specified in Express.
Attributes within each of the represented entities are validated as
usual.
An entity hierarchy with triangle and circle both inheriting from
shape with andor inheritance would allow creation of a
circle-shape-triangle entity. Here is an example of how such an
object could be created.
SCLstring *entNmArr[64]; // array of entity type names
int fileid = 1;
Registry *registry = new Registry(SchemaInit);
entNmArr[0] = new SCLstring("shape");
entNmArr[1] = new SCLstring("triangle");
entNmArr[2] = new SCLstring("circle");
entNmArr[3] = 0;
STEPentity * obj = new STEPcomplex(&_reg, (const SCLstring **)entNmArr,
fileid);
In the same manner the toolkit would allow a user to create a
circle-shape-triangle-color entity even if it was not valid given the
Express.
The complex instances implementation has a late bound flavor. The
instances do not have code generated implementing attribute access
functions with names matching the name of the attribute. This method
of access, normally associated with an early binding, is available for
non-complex instances and is partially available for instances
involving multiple inheritance. The complex entity instance's
attributes are accessible through the STEPattribute class in a manner
similar to the non-complex instances.
The Data Probe reads and writes complex instances from/to Part 21 and
Working files but supports very limited editing of complex instances.
----------------------
*Multiple Inheritance:
----------------------
The SCL offers two choices to users in handling multiple inheritance.
These include the method offered by SCL in previous releases and the
current method. The current method handles attributes inherited from
all parents. It does not correctly handle multiple inheritance where
an entity has more than one path through parents to a common ancestor.
One could imagine this case as a diamond shaped inheritance structure.
When this case of multiple inheritance is encountered attributes are
duplicated. This case of multiple inheritance may possibly be
avoided by modifying the EXPRESS schema by breaking some links in the
inheritance hierarchy. This will not have an adverse affect on the
implementation. The user may choose to use the current or previous
method of handling multiple inheritance. The current method is the
default behavior. The previous method is obtained by supplying the
-s (or -S) option with the exp2cxx code generator or the mkProbe
script.
When the exp2cxx code generator is generating the C++ class library
representation of a schema, it outputs information calling attention
to the cases of multiple inheritance.
The previous method of handling multiple inheritance:
This method of handling multiple inheritance is useful where
attributes are inherited from only one parent. It does not allow an
entity instance to be casted in C++ to a class representing
non-implemented parents. These multiply inherited instances are
created in the same manner as non-multiply inherited, non-complex
instances.
For each entity that has multiple parents the first parent that
contains or inherits attributes is used in the inheritance hierarchy
for the C++ class representing the entity. In each case of multiple
inheritance the parents are searched for attributes in the same order
as they were specified for the entity in Express. Once attributes
have been found associated with one parent, attributes from other
parents are ignored. All attributes handled have access functions.
The current method of handling multiple inheritance:
Multiply inherited instances are created in the same manner as
non-multiply inherited, non-complex instances. These include calling
any of the following functions:
1. the constructor of the entity class.
2. Registry::ObjCreate() with the name of the entity as a string argument.
3. EntityDescriptor::NewSTEPentity() from the dictionary entry
associated with the entity to be created.
a c e
| | | This hierarchy modeled in Express turns into
b d f the data structures pictured below.
\ | /
\ | / h
\|/ /
g -
Each STEPentity also has a pointer back to g's STEPentity.
STEPentity STEPentity STEPentity
-------------------- -------------------- --------------------
| - attribute list | | - attribute list | | - attribute list |
| for a, b, c, d,| | for c and d | | for e and f |
| e, f, h, and g | | (in that order)| | (in that order)|
| (in that order)| | | | |
| - pointer to | | - pointer to | | - pointer to |
| STEPentity ----+--->| STEPentity ----+--->| STEPentity ----+----
| - pointer to | | - pointer to | | - pointer to | |
| dictionary | | dictionary | | dictionary | |
| entry for g | | entry for d | | entry for f | |
-------------------- -------------------- -------------------- |
| | | |
a c e |
---------------------- ---------------------- ---------------------- |
| - attributes for a | | - attributes for c | | - attributes for e | |
| - access functions | | - access functions | | - access functions | |
| for a | | for c | | for e | |
---------------------- ---------------------- ---------------------- |
| | | |
b d f |
---------------------- ---------------------- ---------------------- |
| - attributes for b | | - attributes for d | | - attributes for f | |
| - access functions | | - access functions | | - access functions | |
| for b | | for d | | for f | |
---------------------- ---------------------- ---------------------- |
| |
g |
---------------------- |
| - attributes for g | |
| - access functions | |
| for g | |
---------------------- |
|
STEPentity <-----------
--------------------
| - attribute list |
| for h |
| - pointer to |
| STEPentity |
| - pointer to |
| dictionary |
| entry for h |
--------------------
|
h
|
----------------------
| - attributes for h |
| - access functions |
| for h |
----------------------
Multiply inherited entities have two early bound access functions
associated with all of the attributes - one for get attribute value
and one for set attribute value. These access functions have the same
name as the attribute. The requirement for use of these access
functions is that they must be called from the appropriate part of
the data structure representing the multiply inherited instance. C's
attribute access functions could be called from a pointer to the C or
D part of the data structures shown above. Functions are supplied for
accessing the appropriate part of the data structure.
a
/ \ An Express schema containing this type of inheritance hierarchy
| | under the current multiple inheritance implementation will cause
b c attributes for 'a' to be duplicated.
| |
\ /
d
The Data Probe fully supports the SCL implementation of multiply
inherited entity instances. Inside a STEP Entity Editor window,
attribute dictionary information is displayed as usual for all
attributes in multiply inherited entity instances. It currently,
however, only displays the first parent encountered each step up the
parent hierarchy when displaying Express dictionary information for
the entity as a result of pressing the Type Information button.
------------------
*Part 21 Comments:
------------------
The SCL now handles comments associated with Part 21 and SCL Working
files. It saves comments preceding an entity instance with the entity
instance that follows. It can handle saving all the comments in the
example below. All the comments would be saved as part of entity
instance #1.
/*comment 1*/ /*cmt 1.5 */
#1/*cmt 2*/=/*cmt 3*/ORGANIZATION/*cmt 4*/( 'hi','foo','bar')/*cmt 5*/;/*cmt6*/
#2=ORGANIZATION('ab','cd','ef');
When writing instance #1 above to a Part 21 or Working file, all
comments that have been saved with the instance will be written out
separately preceding the instance as follows.
/*comment 1*/
/*cmt 1.5 */
/*cmt 2*/
/*cmt 3*/
/*cmt 4*/
/*cmt 5*/
#1=ORGANIZATION('hi','foo','bar');
/*cmt6*/
#2=ORGANIZATION('ab','cd','ef');
Part 21 comments are also read and written for header entity instances.
Part 21 comments are supported in the Data Probe. Comments associated
with an entity appear in the comment field on the STEP Entity Editor
window. The comment (formerly "label") field accepts comments that
will be saved to a Part 21 or Working file and comments that are not.
Comments written as valid Part 21 comments (i.e. enclosed in /* */)
will be saved in files. Non-Part 21 text will only last until the end
of the Data Probe session or until the entity is deleted, whichever
comes first.
---------
*Selects:
---------
The way SCL handles selects for editing and writing part 21 files has
been updated. Here are the new rules.
- If there is only one choice in the select (i.e. a select of one
type), the value for that choice can be entered without qualification.
- If the select is between entities only (and not via nested selects),
the element types are assumed to be unique and values can be entered
as a reference to an entity instance.
- In all other cases the value must be qualified by enclosing the
value in the type of the select item.
- These rules apply to editing in the Data Probe, as well as reading
from and writing to a file.
When editing a select attribute in the Data Probe STEP Entity Editor
window, mouse clicking the edit button offers support for qualifying
the select attribute value. When you click the edit button for a
select attribute, and choose a type from the list, it is applied to
the attribute value field in the entity editor.
If there wasn't a value in the attribute previously, then the field will
contain just the type specifier, e.g., Str1() if Str1 is the type selected.
If a value exists in the field, it is modified to accommodate the new
specifier. This means the following:
o If the value in the field starts with a single-quote ('), it is
assumed to be a string literal, and is completely wrapped in the new
specifier (e.g., 'foobar' --> Str1('foobar') ).
o If the value starts with an open-paren ('('), it is assumed to be an
aggregate literal, and is wrapped in the new specifier as above.
o If the value already has a specified type (e.g., Str1('foo')), things