DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 13 of 18 FirstFirst ... 31112131415 ... LastLast
Results 181 to 195 of 261

Thread: Another Language

  1. #181
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Another Language

    "Jonathan West" <jwest@mvps.org> wrote in message <news:3afb3a90$1@news.devx.com>...

    > IIRC, there were effectively two separate versions of VB4 - VB4/16 and
    > VB4/32.


    Correct.

    > If Microsoft had written things down for VB3 as you describe, would
    > you have expected them then to have a 16-bit Integer datatype for VB4/16 and
    > a 32-bit Integer datatype for VB4/32?


    Would there have also been Int16, Int32, etc.? If not, how do you read a
    binary file written by a 16-bit app containing 16-bit integers, if you're
    stuck with a 32-bit Integer and a 64-bit Long, without lots of hassle?

    --
    Joe Foster <mailto:jfoster@ricochet.net> On the cans? <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



  2. #182
    Mike Mitchell Guest

    Re: Another Language

    On Thu, 10 May 2001 20:48:26 GMT, kylix_is@hotmail.com (Mike Mitchell)
    wrote:

    >Nah! Try me! Go on! See, I just.....lean over to the left a tad, and
    >grab my "Radio Shack TRS-80 User's Manual for Level 1", first edition,
    >second printing - 1978, with a "Personal Note from the Author", one
    >Dr. David A. Lien of San Diego, 1977.


    Further to that, I now have the following interesting link:
    http://www.rjh.org.uk/altair/ian.htm

    which was derived from
    http://www.theregister.co.uk/content/4/18915.html

    MM

  3. #183
    Craig Clearman Guest

    Re: Another Language

    Hi Phil,

    > > Do you have any way to code without making this
    > > assumption in a typesafe language?

    >
    >Craig: C++'s #define method is one approach.


    Sorry, Phil, but even when you use a define or typedef, you are still
    making this assumption. The only thing you've gained is an easier
    ability to redefine your datatypes.

    > Microsoft could have provided
    >default definitions for keywords (e.g., Integer = Int16, Long = Int32,
    >etc.), which would have allowed developers to redefine the keywords if they
    >wish.


    You do recognize how horrible that would be, don't you? Can you
    imagine trying to debug an application that has redefined Integer to
    Boolean? This approach wouldn't be useless -- it would be actively
    harmful. Redefining keywords is dumb, whether a programmer does it, or
    whether a software house does it.

    >I think it's C++'s ability to do this which has contributed to its
    >relative stability over the years. Microsoft's mistake with VB was in not
    >documenting, well in advance, that the implementation was subject to change.


    No. C++ can change its data type sizes because its programmers have a
    choice. They can choose fixed size integers and processor-defined
    integers. As such, they can actually figure out which changes are
    necessary when moving between architectures and which changes would be
    catastrophic.

    The best way that MS could handle this with VB is to do the same:
    create a new datatype that is variably defined. That's what *everyone*
    recommended long ago: a SysInt. Or just call it the same as C++: an
    int.

    Ciao, Craig


  4. #184
    Craig Clearman Guest

    Re: Another Language

    Kunle,

    >> An Integer, even under VB.NET, is not going to be defined as the
    >> performant data type under any processor. It is going to be a 32-bit
    >> variable. If you run under Itanium, an Integer will still be a 32-bit
    >> variable, as it currently stands.

    >
    >That is the only remaining issue with Integer IMO. It should resolve to the
    >most efficient bitsize for the underlying architecture (but be at least
    >32-bits wide)


    No. We would not have a supported way of handling fixed size variables
    under your proposal.

    >> Simply put, if MS wants a variable to be variably-defined dependent
    >> upon the processor, it should create a new datatype. Way back when, it
    >> was suggested that they use something called SysInt. If they are going
    >> to go this way, mapping Integer to Int32 on some processors, and Int64
    >> on others, they have gone about it exactly the wrong way.

    >
    >Why a new datatype?.


    I would think that would be self-evident. You currently don't have a
    way to handle something. You create something new to handle it because
    incorporating it into an existing function would break current usage.
    The *entire* world recognizes this as the best way to handle changes.
    This is the case for process engineering, manufacturing, software
    development, *everything*.

    > The pseudo-datatype named "Integer" should be that
    >datatype IMO. It's not a CLR type anyway,


    *Exactly* the problem. There is no such functionality in the
    framework. The CLS only has fixed sized datatypes. As such, you could
    never tell by looking at an assembly whether the variable will fit
    against your datatype unless you also use a fixed sized datatype.

    >We already have fixed-size integer datatypes - Int16, Int32, Int64....
    >We just need Integer to be variable sized as I explained above. (Short/Long
    >would maintain their relation to Integer)


    Umm...No.

    As you say: IL has fixed-size datatypes. That's it. No more. We need
    something else to map to if we want variable sized datatypes.
    Otherwise, you can not expect your assemblies to work against other
    languages on other processors.

    >> >developers should not make assumptions as to their size and/or layout.

    >>
    >> Do you have any way to code without making this assumption in a
    >> typesafe language?
    >>
    >> Have you ever persisted data to a database? You've made this
    >> assumption. Have you ever persisted data to a file? You've made this
    >> assumption. Have you ever converted between two datatypes? You've made
    >> this assumption. Have you ever chosen a datatype other than Variant?
    >> You've made this assumption.

    >
    >I like to think that in all this instances, the assumption is driven be the
    >requirements of the data and not by the language. If I need to save/retrieve
    >data from a data store, I examine the data store and select a datatype that
    >matches.


    Exactly. You made an assumption about the size of your variable, and
    the size of the variable in the database.

    > When I get a new tools (or new version of a tool), I re-run the process.


    So you rewrite all of your code for every new version? Or for every
    processor that an existing version will target?

    Of course, this assumes that you are going to recompile your source
    code for every processor that you will target. One of the benefits of
    the distribution system in .NET is that it should not be necessary. If
    you compile to IL, a different JIT could compile better optimizations
    based on the computer running your assembly.

    Granted, in the first version, there will not be any such
    optimizations. But that is one of the benefits to the architecture.

    But this means that you *have* to have a different IL construct for
    your new, variably-sized datatype.

    Ciao, Craig


  5. #185
    Kunle Odutola Guest

    Re: Another Language


    "Craig Clearman" <chclear@nospam.please> wrote in message
    news:nsftftgdtd8u6gqr0mt9p2l16ukamj946d@4ax.com...

    > >That is the only remaining issue with Integer IMO. It should resolve to

    the
    > >most efficient bitsize for the underlying architecture (but be at least
    > >32-bits wide)

    >
    > No. We would not have a supported way of handling fixed size variables
    > under your proposal.


    Fixed-size integer datatypes in VB.NET are Int16, Int32, IntXX...

    > >> Simply put, if MS wants a variable to be variably-defined dependent
    > >> upon the processor, it should create a new datatype. Way back when, it
    > >> was suggested that they use something called SysInt. If they are going
    > >> to go this way, mapping Integer to Int32 on some processors, and Int64
    > >> on others, they have gone about it exactly the wrong way.

    > >
    > >Why a new datatype?.

    >
    > I would think that would be self-evident.


    No it isn't self evident. I believe the keyword "Integer" is the most
    intuitive name for the default integral datatype. It is the name that you
    would think to use when you just want an integer...consequently it should be
    the most efficient. MS has already reclaimed the name, it just needs to go
    all the way and declare it as I suggested and not make another mistake of
    defining it as an alias for a fixed-size datatype. We already have to serach
    & replace "Integer" with "Int16" in existing source anyways.

    > The *entire* world recognizes this as the best way to handle changes.
    > This is the case for process engineering, manufacturing, software
    > development, *everything*.


    To change is to alter, morph, evolve...

    > > The pseudo-datatype named "Integer" should be that
    > >datatype IMO. It's not a CLR type anyway,

    >
    > *Exactly* the problem. There is no such functionality in the
    > framework. The CLS only has fixed sized datatypes. As such, you could
    > never tell by looking at an assembly whether the variable will fit
    > against your datatype unless you also use a fixed sized datatype.


    This is a language issue. Not a CLS issue. The CLS has provided what is
    expected of it. There is no such type in x86 machine code either (or any
    other CPU code AFAIK) but C/C++ support "int" quite well...

    > >We already have fixed-size integer datatypes - Int16, Int32, Int64....
    > >We just need Integer to be variable sized as I explained above.

    (Short/Long
    > >would maintain their relation to Integer)

    >
    > Umm...No.


    Errmm....Yes.

    > As you say: IL has fixed-size datatypes. That's it. No more. We need
    > something else to map to if we want variable sized datatypes.
    > Otherwise, you can not expect your assemblies to work against other
    > languages on other processors.


    It's a language issue and it is platform dependent. If you need to interop
    (in which case size matters) then use a fixed size datatype. No such
    datatype can be truly cross-platform. How would you pass such a datatype
    between an app on a P3 system (32-bit) and an Itanium system (64-bit) ?

    > > When I get a new tools (or new version of a tool), I re-run the process.

    >
    > So you rewrite all of your code for every new version? Or for every
    > processor that an existing version will target?


    I re-run my unit and system tests at the very least ;-)
    Such things typically don't change in every revision of a tool. But if they
    change...

    > Of course, this assumes that you are going to recompile your source
    > code for every processor that you will target. One of the benefits of
    > the distribution system in .NET is that it should not be necessary. If
    > you compile to IL, a different JIT could compile better optimizations
    > based on the computer running your assembly.


    Why the source code?. The IL contains all the info it needs unless the
    platform's architecture changes or the definition of the datatypes change.
    In both cases, you will need a compile anyways.

    > But this means that you *have* to have a different IL construct for
    > your new, variably-sized datatype.


    No it doesn't IMO. The datatype should be resolved at compile-to-IL time.
    There is no need for an IL "native integer datatype" construct. It could NOT
    be cross-platform.

    Kunle




  6. #186
    Kunle Odutola Guest

    Re: Another Language


    "Craig Clearman" <chclear@nospam.please> wrote in message
    news:u9ftftsgdgrt6g86dvclnavr35teh0bg5m@4ax.com...

    > >I think it's C++'s ability to do this which has contributed to its
    > >relative stability over the years. Microsoft's mistake with VB was in not
    > >documenting, well in advance, that the implementation was subject to

    change.
    >
    > No. C++ can change its data type sizes because its programmers have a
    > choice. They can choose fixed size integers and processor-defined
    > integers. As such, they can actually figure out which changes are
    > necessary when moving between architectures and which changes would be
    > catastrophic.


    There is no such thing as a processor-defined integer IMO. The C++ compiler
    simply resolve 'int' t the native bitsize of the underlying CPU.
    It's a language/compiler issue.

    If "Integer" in VB is defined in a similar manner to C++'c 'int', we have
    the same choices as the C++ guys. The real issue is whether it should be
    called SysInt, NativeInteger etc....I say call it Integer.

    > The best way that MS could handle this with VB is to do the same:
    > create a new datatype that is variably defined. That's what *everyone*
    > recommended long ago: a SysInt. Or just call it the same as C++: an
    > int.


    That is one way to handle it. Defining "Integer" to be the same size as the
    native bitsize is a better option IMO.

    Kunle




  7. #187
    Jonathan West Guest

    Re: Another Language


    "Kunle Odutola okocha.freeserve.co.uk>" <kunle.odutola@<REMOVETHIS> wrote in
    message news:3afadf60@news.devx.com...
    > >
    > > In what way are better applications built if you write "Dim x as

    Integer"
    > > instead of "Dim x as Long" in order to declare a signed 32-bit integer?

    >
    > In no way at all.


    Thank you. It took us long enough to reach that point.

    > But if I just want an Integer - don't care about the
    > size


    Of course you care about the size. The size always has to be big enough to
    support the range of values that you plan to assign to the variable. That is
    why I refined Karl's proposal for a definition of SysInt so that the minimum
    length was defined.

    >- to use for a loop counter, indexing etc and use the aptly named
    > "Integer" datatype, why should my applications suffer a performance

    penalty
    > compared to if I had known that the underlying CPU architecture was 32bits
    > and I had chosen to use Long instead, or Int64 (LongAlso?) in the future,

    or
    > Int128 (AndEvenLonger?)...


    No reason at all. That is why Karl suggested the SysInt datatype. I fully
    agree that there would be a use for a datatype of this sort. The only point
    on which we disagree is that I think it is inappropriate to change the
    meaning and function of an existing keyword in order to provide it.

    >
    > The Integer keyword is more naturally "the" Integer datatype than Long,
    > Short, IntXX or anything else and, that is what most people would use. I
    > have already stated that I actually began to use Long instead. Ultimately,
    > the benefit is that VB'ers can just concentrate on the problem rather than
    > the implementation details and still be happy in the knowledge that the
    > resulting applications are as efficient as they could be.


    I accept that you think that your proposal for the meaning of Integer is a
    good one. That's your opinion and you are quite entitled to it.
    Unfortunately, you have fallen into the classic mistake of assuming that
    simply because *you* think that it is better/more intuitive to use Integer
    for this purpose, that this is in fact a general rule which will apply to
    everyone. With any such possible rule, you need to check whether is actually
    *does* apply to everyone before you make that assumption. As you have
    discovered, on this matter there are others who disagree with you, and who
    have put forward a number of reasons why they disagree. Therefore, it
    appears that it is not a general rule, and there are arguments in both
    directions.

    I take the view that, unless there is some particular benefit in redefining
    keywords, a language update should not do so. I accept that your opinion is
    that in this case there is a benefit, and I disagree with your opinion, for
    the reasons I have already stated.

    I think that is about all there is to say on this. We've pretty much beaten
    this topic to death.

    --
    Regards
    Jonathan West


  8. #188
    Craig Clearman Guest

    Re: Another Language

    Kunle,

    >> No. C++ can change its data type sizes because its programmers have a
    >> choice. They can choose fixed size integers and processor-defined
    >> integers. As such, they can actually figure out which changes are
    >> necessary when moving between architectures and which changes would be
    >> catastrophic.

    >
    >There is no such thing as a processor-defined integer IMO. The C++ compiler
    >simply resolve 'int' t the native bitsize of the underlying CPU.
    >It's a language/compiler issue.


    Yes, it is a language issue. C++ gives you the power to declare
    something an int or an __int32 or a DWORD. This gives you the ability
    to write processor independent code.

    Under your definition for VB.NET, you would not have this ability.
    That means that you have to rewrite your code for each processor
    design. This is why your proposal is a bad idea.

    In order to write code that can be maintained for multiple
    architectures, you need the ability to define something as fixed size.
    (32-bit on all processors, for instance.) If you don't have that
    ability, you can not write portable code.

    >> The best way that MS could handle this with VB is to do the same:
    >> create a new datatype that is variably defined. That's what *everyone*
    >> recommended long ago: a SysInt. Or just call it the same as C++: an
    >> int.

    >
    >That is one way to handle it. Defining "Integer" to be the same size as the
    >native bitsize is a better option IMO.


    Integer is already defined. You are talking about redefining, which
    would break existing code. Furthermore, you don't have a replacement
    for the current definition, which limits your proposed language far
    more than the lack of a SysInt.

    Ciao, Craig


  9. #189
    Craig Clearman Guest

    Re: Another Language

    Kunle,

    >> No. We would not have a supported way of handling fixed size variables
    >> under your proposal.

    >
    >Fixed-size integer datatypes in VB.NET are Int16, Int32, IntXX...


    No. Those declarations are not VB.NET datatypes. They are IL
    datatypes. There is no variably sized datatype in IL, therefore
    nothing that compiles to IL can rely on this functionality. In fact,
    if you try to use them consistently in VB.NET, you will find that they
    are crippled. There is precisely *no way* that VB.NET can distinguish
    between an Integer and an Int32 in anything to which it doesn't have
    source-level access. That's because they are not different.

    Your alternative is to recompile your source to IL for each
    architecture that you will target, thus destroying one of the key
    benefits of IL.

    >> >> Simply put, if MS wants a variable to be variably-defined dependent
    >> >> upon the processor, it should create a new datatype.
    >> >
    >> >Why a new datatype?.

    >>
    >> I would think that would be self-evident.

    >
    >No it isn't self evident.


    Okay.

    If MS wants something new, they should create something new.

    >This is a language issue. Not a CLS issue. The CLS has provided what is
    >expected of it. There is no such type in x86 machine code either (or any
    >other CPU code AFAIK)


    The CLS was not designed to target x86 machine code. It was intended
    to be an abstraction layer above the hardware, so that it could run on
    multiple architectures without a change to source code.

    >but C/C++ support "int" quite well...


    By having the ability to define a variable as fixed size as well as
    variably-sized. IL does not have this ability, thus languages built
    upon IL do not have this ability without source code recompiles.

    >> >We already have fixed-size integer datatypes - Int16, Int32, Int64....
    >> >We just need Integer to be variable sized as I explained above.

    >(Short/Long
    >> >would maintain their relation to Integer)

    >>
    >> Umm...No.

    >
    >Errmm....Yes.


    You've heard this many times. Int32 is *not* a VB.NET datatype. It is
    an IL datatype. If you play with Int32 in VB.NET, you will find that
    it is crippled. The only way to interrogate another assembly and
    determine whether the datatype defined is a Int32 or an Integer is to
    check its source code. Now, add to the fact that you can use an
    assembly built in a different language, and you can recognize why it
    would be prohibitively difficult to interrogate that source. When you
    further recognize that you don't have to have the source to the
    assembly, you'll recognize that the only way to differentiate between
    an Integer and Int32 is to have two different constructs in the IL.

    >Such things typically don't change in every revision of a tool. But if they
    >change...


    Then you will rewrite your code.

    >> Of course, this assumes that you are going to recompile your source
    >> code for every processor that you will target. One of the benefits of
    >> the distribution system in .NET is that it should not be necessary. If
    >> you compile to IL, a different JIT could compile better optimizations
    >> based on the computer running your assembly.

    >
    >Why the source code?. The IL contains all the info it needs unless the
    >platform's architecture changes or the definition of the datatypes change.
    >In both cases, you will need a compile anyways.


    You only need a compile from IL to the native code on the box that
    will be running the code! This is the benefit to a JIT environment --
    you can use the same assembly on different processors, different
    architectures, even different systems.

    You do *not* recompile from source to IL for every processor. You only
    recompile from IL to native code. This is the major strength of the
    new distribution scheme.

    >> But this means that you *have* to have a different IL construct for
    >> your new, variably-sized datatype.

    >
    >No it doesn't IMO. The datatype should be resolved at compile-to-IL time.
    >There is no need for an IL "native integer datatype" construct. It could NOT
    >be cross-platform.


    Have you ever written portable code?

    Ciao, Craig


  10. #190
    Jeff Peil Guest

    Re: Another Language

    Hi Craig,

    Just pointing out a couple technical points you seem to have missed.

    "Craig Clearman" <chclear@nospam.please> wrote in message
    news:eaovftclo7dedkosb693mt134mje5tds40@4ax.com...
    > \There is no variably sized datatype in IL, therefore
    > nothing that compiles to IL can rely on this functionality.


    IL *does* have variably sized data types: native int, native unsigned int,
    pointers, etc.

    > You've heard this many times. Int32 is *not* a VB.NET datatype. It is
    > an IL datatype. If you play with Int32 in VB.NET, you will find that
    > it is crippled. The only way to interrogate another assembly and
    > determine whether the datatype defined is a Int32 or an Integer is to
    > check its source code. Now, add to the fact that you can use an
    > assembly built in a different language, and you can recognize why it
    > would be prohibitively difficult to interrogate that source. When you
    > further recognize that you don't have to have the source to the
    > assembly, you'll recognize that the only way to differentiate between
    > an Integer and Int32 is to have two different constructs in the IL.


    Strictly speaking System.Int32 is a base class library type, not an CIL/MSIL
    datatype (there is a int32 IL type, notice however the capitalization
    difference.) Just as the BCL System.Int32 type maps to int32 the
    System.IntPtr BCL type maps to native int.



  11. #191
    Craig Clearman Guest

    Re: Another Language

    Hi Jeff,

    >Just pointing out a couple technical points you seem to have missed.


    Always willing.

    >> \There is no variably sized datatype in IL, therefore
    >> nothing that compiles to IL can rely on this functionality.

    >
    >IL *does* have variably sized data types: native int, native unsigned int,
    >pointers, etc.


    Where are they? I've certainly seen some work on this front in the
    marshalling/interop. For instance, the UnmanagedType enum has SysInt
    as an option, but I haven't seen any value type called native int. And
    when you are pushing to an unmanaged heap (I think they are calling it
    the native heap), with a function like Marshal.PtrToStringAnsi, you
    appear to be using an Int32.

    And at least now, while we have a SystemDefaultCharSize, we don't have
    an equivalent for an integer.

    Ah. There it is: IntPtr. Yes, that is what you would push SysInt
    towards.

    I don't have the frameworks on this computer, so I can't really tell
    what it looks like, but the documentation hasn't been created yet. The
    listed member functions look strange as well, not allowing for most
    conversions. Have you played with it?

    >Strictly speaking System.Int32 is a base class library type, not an CIL/MSIL
    >datatype (there is a int32 IL type, notice however the capitalization
    >difference.) Just as the BCL System.Int32 type maps to int32 the
    >System.IntPtr BCL type maps to native int.


    Yeah, I was talking about the value types.

    Ciao, Craig


  12. #192
    Kunle Odutola Guest

    Re: Another Language


    "Jonathan West" <jwest@mvps.org> wrote in message
    news:3affa4ee$1@news.devx.com...
    >
    > "Kunle Odutola okocha.freeserve.co.uk>" <kunle.odutola@<REMOVETHIS> wrote

    in
    > message news:3afadf60@news.devx.com...
    > > >
    > > > In what way are better applications built if you write "Dim x as

    > Integer"
    > > > instead of "Dim x as Long" in order to declare a signed 32-bit

    integer?
    > >
    > > In no way at all.

    >
    > Thank you. It took us long enough to reach that point.


    It took _you_ long enough. It was never about this issue.

    >
    > > But if I just want an Integer - don't care about the
    > > size

    >
    > Of course you care about the size. The size always has to be big enough to
    > support the range of values that you plan to assign to the variable. That

    is
    > why I refined Karl's proposal for a definition of SysInt so that the

    minimum
    > length was defined.


    No I don't always (care about the size). With the ubiquity of 32-bit
    procesors, this isn't really an issue but the minimum bit length is
    important in the general case.

    > >- to use for a loop counter, indexing etc and use the aptly named
    > > "Integer" datatype, why should my applications suffer a performance

    > penalty
    > > compared to if I had known that the underlying CPU architecture was

    32bits
    > > and I had chosen to use Long instead, or Int64 (LongAlso?) in the

    future,
    > or
    > > Int128 (AndEvenLonger?)...

    >
    > No reason at all. That is why Karl suggested the SysInt datatype. I fully
    > agree that there would be a use for a datatype of this sort. The only

    point
    > on which we disagree is that I think it is inappropriate to change the
    > meaning and function of an existing keyword in order to provide it.


    It's a choice of name issue really, it was clouded by those claiming that
    keywords *must* not be redefined. In general, I am against gratuitious
    keyword redefinition but given:
    a) that no substantial source code base would run on both VB6 and VB.NET due
    to the massively different platform APIs
    b) the oft-repeated assertion that VB's definition of "Integer" as a 16-bit
    was wrong
    I see the "Integer" keyword redefinition issue as a red herring. Do the
    search & replace for "Integer" with "Int16" and move on is my advice...

    All that remains is for MSFT to redefine Integer as the native integer
    datatype....

    > I accept that you think that your proposal for the meaning of Integer is a
    > good one. That's your opinion and you are quite entitled to it.
    > Unfortunately, you have fallen into the classic mistake of assuming that
    > simply because *you* think that it is better/more intuitive to use Integer
    > for this purpose, that this is in fact a general rule which will apply to
    > everyone.
    > With any such possible rule, you need to check whether is actually
    > *does* apply to everyone before you make that assumption. As you have
    > discovered, on this matter there are others who disagree with you, and who
    > have put forward a number of reasons why they disagree. Therefore, it
    > appears that it is not a general rule, and there are arguments in both
    > directions.


    You are wrong in assuming that I expect you all to accept my views. Many
    expect me to accept their views though. Some without any logical arguments,
    just personal insults. I don't for the reasons I have stated.

    > I take the view that, unless there is some particular benefit in

    redefining
    > keywords, a language update should not do so. I accept that your opinion

    is
    > that in this case there is a benefit, and I disagree with your opinion,

    for
    > the reasons I have already stated.


    I respect your views but I don't subscribe to them on this particular issue.

    > I think that is about all there is to say on this. We've pretty much

    beaten
    > this topic to death.


    Yep. It was a simple comment that I made that many took me to task on. It's
    all up to MSFT really....

    Kunle




  13. #193
    Jeff Peil Guest

    Re: Another Language


    "Craig Clearman" <chclear@nospam.please> wrote in message
    news:se50gtstq8odqclpgbj4ga6mihui9rnv0m@4ax.com...
    > Where are they?


    If you're really interested, then read the MSIL docs, IIRC back with the pdc
    docs it took me about 8 hours to get through the MSIL docs, fairly
    worthwhile reading imo.

    > I don't have the frameworks on this computer, so I can't really tell
    > what it looks like, but the documentation hasn't been created yet. The
    > listed member functions look strange as well, not allowing for most
    > conversions. Have you played with it?


    Sure, the compiler support is minimal, but at the MSIL level, a native int,
    is just that, a native-width int, remember when
    adding/multiplying/manipulating such types in MSIL one is using opcodes.
    Basically the BCL type is a late addition and thus the compiler support in
    V1 is minimal, but it's just another type. At the IL level you can use it
    just like you would use an int32 or int64. For the most part the only time
    you'd really find it useful in C# or VB.NET (due to the lack of compiler
    support), is portably interacting with APIs that have different width
    requirements on different width architectures (such as Win32 vs Win64)

    > >Strictly speaking System.Int32 is a base class library type, not an

    CIL/MSIL
    > >datatype (there is a int32 IL type, notice however the capitalization
    > >difference.) Just as the BCL System.Int32 type maps to int32 the
    > >System.IntPtr BCL type maps to native int.

    >
    > Yeah, I was talking about the value types.





  14. #194
    Kunle Odutola Guest

    Re: Another Language


    "Kunle Odutola okocha.freeserve.co.uk>" <kunle.odutola@<REMOVETHIS> wrote in
    message news:3aff2a41@news.devx.com...

    > > > The pseudo-datatype named "Integer" should be that
    > > >datatype IMO. It's not a CLR type anyway,

    > >
    > > *Exactly* the problem. There is no such functionality in the
    > > framework. The CLS only has fixed sized datatypes. As such, you could
    > > never tell by looking at an assembly whether the variable will fit
    > > against your datatype unless you also use a fixed sized datatype.

    >
    > This is a language issue. Not a CLS issue. The CLS has provided what is
    > expected of it. There is no such type in x86 machine code either (or any
    > other CPU code AFAIK) but C/C++ support "int" quite well...


    An update to my reply above:

    Actually, you have a point with the CLS issue. I can't quite figure out why
    the IL "native int" datatype isn't supported in the CLS. It would allows
    managed code to use the "native int" in a cross-language, cross-platform
    manner. The only restriction I will add to it (in the CLS context) is that
    it can only be used for local types and only as parameters in private
    methods.

    Any views??

    Kunle




  15. #195
    Kunle Odutola Guest

    Re: Another Language


    "Craig Clearman" <chclear@nospam.please> wrote in message
    news:eaovftclo7dedkosb693mt134mje5tds40@4ax.com...
    > Kunle,


    > >> No. We would not have a supported way of handling fixed size variables
    > >> under your proposal.

    > >
    > >Fixed-size integer datatypes in VB.NET are Int16, Int32, IntXX...

    >
    > No. Those declarations are not VB.NET datatypes. They are IL
    > datatypes. There is no variably sized datatype in IL, therefore
    > nothing that compiles to IL can rely on this functionality.


    IL has the "native int" datatype in signed and unsigned forms. It seems to
    be currently restricted to 32-bits or 64-bits only but then I don't know of
    any 128-bit CPUs.

    > Your alternative is to recompile your source to IL for each
    > architecture that you will target, thus destroying one of the key
    > benefits of IL.


    See above.

    > >> >> Simply put, if MS wants a variable to be variably-defined dependent
    > >> >> upon the processor, it should create a new datatype.
    > >> >
    > >> >Why a new datatype?.
    > >>
    > >> I would think that would be self-evident.

    > >
    > >No it isn't self evident.

    >
    > Okay.
    >
    > If MS wants something new, they should create something new.


    My assertion is that "Integer" (which isn't new) is the appropriate name for
    the datatype in VB.NET.

    > By having the ability to define a variable as fixed size as well as
    > variably-sized. IL does not have this ability, thus languages built
    > upon IL do not have this ability without source code recompiles.


    IL does. See above.

    > >> >We already have fixed-size integer datatypes - Int16, Int32, Int64....
    > >> >We just need Integer to be variable sized as I explained above.

    > >(Short/Long
    > >> >would maintain their relation to Integer)
    > >>
    > >> Umm...No.

    > >
    > >Errmm....Yes.

    >
    > You've heard this many times. Int32 is *not* a VB.NET datatype. It is
    > an IL datatype. If you play with Int32 in VB.NET, you will find that
    > it is crippled. The only way to interrogate another assembly and
    > determine whether the datatype defined is a Int32 or an Integer is to
    > check its source code.


    That is the current implementation. I am happy that Integer has been changed
    but I agree that it has not been properly aligned with the "native int"
    datatype.
    Given that "native int" isn't covered in the CLS, I suspect this is now a
    language issue and that ultimately all such types would have to be resolved
    by a compiler to one of the IntXX types.

    > Now, add to the fact that you can use an
    > assembly built in a different language, and you can recognize why it
    > would be prohibitively difficult to interrogate that source. When you
    > further recognize that you don't have to have the source to the
    > assembly, you'll recognize that the only way to differentiate between
    > an Integer and Int32 is to have two different constructs in the IL.


    Being unable to tell if it was an Integer in the original source is not a
    problem AFAICT. All you need to know to use it is it's IL datatype...
    IL does have th construct you refer to but, the CLS doesn't include it
    AFAICT.

    > >Why the source code?. The IL contains all the info it needs unless the
    > >platform's architecture changes or the definition of the datatypes

    change.
    > >In both cases, you will need a compile anyways.

    >
    > You only need a compile from IL to the native code on the box that
    > will be running the code! This is the benefit to a JIT environment --
    > you can use the same assembly on different processors, different
    > architectures, even different systems.
    >
    > You do *not* recompile from source to IL for every processor. You only
    > recompile from IL to native code. This is the major strength of the
    > new distribution scheme.


    True you *shouldn't* need to compile from source on every platform but, with
    the CLS restrictions, you may have to.
    This is one of the reasons I see for fighting for VB.NET to be on absolute
    parity with C# (re: IL compatibility) rather than VB6. Of course there are
    pros and cons...

    > >> But this means that you *have* to have a different IL construct for
    > >> your new, variably-sized datatype.

    > >
    > >No it doesn't IMO. The datatype should be resolved at compile-to-IL time.
    > >There is no need for an IL "native integer datatype" construct. It could

    NOT
    > >be cross-platform.

    >
    > Have you ever written portable code?


    Let me expand my previous comments:
    1) "No it doesn't IMO."
    IL already *has* a construct for native integer but the CLS doesn't support
    it

    2) "The datatype should be resolved at compile-to-IL time."
    Given this situation (and VB.NET's inability to circumvent the CLS) the
    datatype should be resolved at compile-to-IL time by VB.NET

    3) "It could NOT be cross-platform"
    Since the IL native integer construct could result in different bitsizes on
    different platforms, such a type cannot interop across dissimilar platforms.
    But then again, correct use of such a type would never require
    cross-platform interop based on such a type.

    Kunle




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center