Re: mfc to .NET

Yes, our IDL system, and its precursor, the LG system, took pointer rebuilding as a key
idea. The issue was how to manage the scenario under schema migration, which MFC doesn't
handle very well at all.

There are both "standard" extensions to XML, and ad hoc extensions to XML, that allow this
to be done. Most of these are add-ons (rather than in our systems, where they were core
ideas), but they solve the problem. Note that the DOM model is the work of amateurs,
because it does not allow dags, cyclic graphs structures, etc., which is why it is almost
but not quite totally useless for practical work. Unfortunately, Microsoft's XML support
is largely DOM-based (example: in DOM, each node has a pointer to its unique parent. Makes
dags and cyclic graphs kind of difficult to construct. Since there is no sane need for a
parent pointer, this limits the model to toy problems)

The nice thing about XML-based solutions is that they really are platform independent. You
could write a serializer in VB, Java, or any other platform of your choice.

Example: represent the binary tree for A+3

<Node:Binary name "012345" Left "34567" Right "14352" op "+"/>
<Node:Leaf name "34567" identifier "A"/>
<Node:Constant name "14352" value "3"/>

Key here is that shape of the structure is decoupled from the syntax, and the name and
reference values are used to "fix up" the resulting structure. The nice thing about this
is that you can also express nested constructs with syntactic nesting and pretty-printing,
but non-nested structures such as dags and general graphs as well. So the common
subexpression tree of (A+3)*(A+3) can be represented as

<Node:Binary name "43221" Left "012345" Right "012345" op "*"/>
<Node:Binary name "012345" Left "34567" Right "14352" op "+"/>
<Node:Leaf name "34567" identifier "A"/>
<Node:Constant name "14352" value "3"/>

or as
<Node:Binary name "43221"
Left <Node:Binary name "012345"
Left <Node:Leaf name "34567" identifier "A"/>
Right <Node:Constant name "14352" value "3"/>
Right "012345"/>

In our system, the two notations were interchangeable and could be read or written at
will. The nested-vs.-flat notation was a boolean parameter of the writer; the reader
implicitly accepted either notation (the notation I'm showing here is probably a
generalization of XML, but it is closer to our notation). Non-nested structures could be
easily expressed. We used this with several programming languages and across several
machine architectures.

As you may gather from the examples, our research and company dealt with compiler
internals.

The IDL notation was adopted as the reference standard for all Ada compilers; the standard
was called DIANA, but I've long since forgotten what that acronym stood for.

There were special provisions for handling schema migration issues and the construction of
compact and efficient internal binary data structures, such as representation pragmatics
in the formal description (something XML sorely lacks; the DTD notation was a truly
amateur design, laughed at by students taking introductory compiler courses for its
inadequacy and clumsiness)
joe

On Tue, 31 Jan 2006 07:23:42 -0000, "phil cunningham" <phil@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:

>thanks for the reply and sorry if I wasn't clear earlier on
>
>What I like about serialisation (apart from it being simple) is that objects
>containing pointers to other objects are just rebuilt by the serializer.
>
>My program contains shapes* which have pointers to other objects and several
>containers of shapes - Serialisation just works really well.
>
> I don't like that it requires MFC to read the files and so is locked to
>that framework
>
>Do you have any information on how to handle data storage for complex
>structures (as above) using a non MFC approach
>
>
>Thanks again
>Phil
>
>* The 'shape' is a collection of real world floating point coordinates
>
>"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
>news:9p1tt15gug9qfd4l8ludv79ggqv0idtlca@xxxxxxxxxx
>>I wrote a book on how to do serialization; it was based on four years of
>>research
>> development at a University and three years of experience using the system
>> in a commercial
>> environment. When I looked at MFC serialization, I saw it had all of the
>> same problems
>> our system was carefully designed to avoid. So I rejected it out-of-hand
>> as being
>> fragile. Every article in every newsgroup I've seen in the intervening
>> years has
>> essentially been a rehash of problems I solved 25 years ago, so I remain
>> confident in my
>> view that serialization has too many risks in terms of long-term
>> maintenance.
>>
>> I either use custom file formats, which are easy once you know that
>> serialization is so
>> bad, or XML, which is trivial, particularly with the good XML packages
>> currently available
>> (as long as you avoid the Microsoft XML DOM packages, which are unusable).
>> Our system was
>> XML without the XML problems (it is amazing how easy it is to reinvent
>> partial solutions).
>>
>> Writing an app in .NET using CLR is a different problem than recompiling
>> MFC. There is
>> little value in transporting a running program to the .NET framework
>> unless you need the
>> other benefits of CLR. So it is necessary to justify why such an effort
>> would be
>> justified. In that case, the question becomes one of the effort of
>> rewriting code, which
>> may be what you intended to ask, but didn't.
>>
>> If you had said "rewrite an MFC application to use CLR" it would be clear
>> what you meant.
>> That is why there is confusion, because you used an ambiguous phrase which
>> is largely
>> content-free, since any number of people ask the same question about
>> recompiling plain MFC
>> apps in VS.NET
>>
>> On Mon, 30 Jan 2006 14:36:00 -0000, "phil cunningham"
>> <phil@xxxxxxxxxxxxxxxxxxxxxxxxx>
>> wrote:
>>
>>>Can I ask what you do use for file storage rather than serialisation -
>>>I've
>>>been using it for about 10 years and it's been perfect.
>>>
>>>I suppose by "transport to .Net" I mean take a program written to use MFC
>>>and re-write it to use the .Net framework. Two different frameworks,
>>>managed
>>>code etc.
>>>
>>>> You are clearly confused by the presence of the phrase ".NET" in the
>>>> Visual Studio marketing name. It's just MFC, with a newly-unusable
>>>> "improved" IDE.
>>>er, there is confusion but I dont think it is mine
>>>
>>>Phil
>>>
>>>"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
>>>news:037st1dod302q825cfm40gbb5rjui8td2c@xxxxxxxxxx
>>>> This discussion seems silly. What does .NET have to do with the
>>>> discussion of MFC? Why
>>>> is it even relevant?
>>>>
>>>> I have no idea what it means to "transport a program to .NET". Do you
>>>> mean "rebuild an
>>>> MFC project in Visual Studio .NET"? Do you mean "make my MFC
>>>> application
>>>> a Web applet"?
>>>>
>>>> I would never, ever, under any circumstances imaginable, have considered
>>>> using any form of
>>>> MFC-supported serialization for writing information to a file. It is
>>>> such
>>>> a fragile
>>>> technology that it always was, and probably will continue to be, an
>>>> inappropriate
>>>> methodology for archiving information. So whether or not it still works
>>>> is not an issue I
>>>> would have ever considered important, because it is clear that it never
>>>> worked for this
>>>> purpose. Even a minor change in the C/C++ compiler could have made such
>>>> files obsolete.
>>>> SO either they work or they don't, and ".NET" has nothing to do with the
>>>> problem. The
>>>> only thing that has relevance to the problem is the differences in
>>>> versions of MFC and the
>>>> C/C++ compiler. If these are compatible, then it will work.
>>>>
>>>> You are clearly confused by the presence of the phrase ".NET" in the
>>>> Visual Studio
>>>> marketing name. It's just MFC, with a newly-unusable "improved" IDE.
>>>> joe
>>>>
>>>> On Mon, 30 Jan 2006 09:38:20 -0000, "phil cunningham"
>>>> <phil@xxxxxxxxxxxxxxxxxxxxxxxxx>
>>>> wrote:
>>>>
>>>>>We have a standalone program written using MFC that does not really need
>>>>>to
>>>>>be web aware.
>>>>>
>>>>>I am concerned that MFC will be gradually left behind as .NET takes
>>>>>over.
>>>>>
>>>>>Is it a good idea to stay with MFC (everything works just fine) or
>>>>>should
>>>>>we
>>>>>be starting to move to .NET
>>>>>
>>>>>Just a side question, if you transport a program to .NET how do you
>>>>>maintain
>>>>>file compatibility with CSerialised files? - I cant think of any easy
>>>>>way
>>>>>of
>>>>>doing it.
>>>>>
>>>>>Any feedback will be really appreciated
>>>>>
>>>>>Thanks
>>>>>Phil
>>>>>
>>>> Joseph M. Newcomer [MVP]
>>>> email: newcomer@xxxxxxxxxxxx
>>>> Web: http://www.flounder.com
>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>>
>> Joseph M. Newcomer [MVP]
>> email: newcomer@xxxxxxxxxxxx
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: xmlns=> was not expected.
    ... > deserialization on this xml and get the results. ... It's not possible to serialize/deserialize this based on serialization ... This method needs to return an XML Schema ...
    (microsoft.public.dotnet.xml)
  • Re: dateTime in Web Services
    ... The Special Case of XML ... Simply because the XML encoding for a DateTime ... When we start with a local time, the result of serialization (encode to ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Retain default attribute values after XSD Validation?
    ... >> when I serialize the resulting doc using its WriteContentTo method, ... >> the default attributes are NOT represented in the XML output stream. ... It could generate an XML serialization preserving as much of the ... I'll want to digitally sign the Account element to both ...
    (microsoft.public.dotnet.xml)
  • Re: lxml/ElementTree and .tail
    ... switching to well-understood XML subsets or other serialization ... formats, simpler and more flexible data models, simpler API:s, and ... At the serialization level, it's easy to think that CDATA sections are different from other text, that character references are different from ordinary characters, that you should ...
    (comp.lang.python)
  • Re: Uses of processing instructions and notations
    ... Tom Anderson wrote: ... If you use XML for normal text documents then Notations and Entities are important tools for document management. ... <!NOTATION png SYSTEM "http://some-other-kind-of-URL"</a>;> ... Compression and Coding of Continuous-tone Still Images " SYSTEM ...
    (comp.text.xml)
Quantcast