Hello,

kwikius wrote:
> A C++ virtual platform is AFAIK no more than an idea. There is no
> current cross platform standard AFAIK.  FWIW I started looking at
> strongly defined  types with my Quan library:

I want C++ virtual platform to be a standard - otherwise porting and
supporting becomes a pain.

* I believe that Apache Portable Runtime [1] is a pretty good choice
for C.
* OPEN specification [2], [3] extends APR with threading, automatic
memory management and automatic code generation. This is again in C,
and is not quite popular.
* Boost [4] targets mostly algorithms, and not a cross-platfrom
compatibility.

Currently comp.std.c++ FAQ recommends STLport only, probably because
other APIs are not standardized yet. Could you please recommend any
other porting/virtualization layers to look at? Or putting this
question in a way which is aligned to the group identity, which set of
public C++ APIs will be discussed here as a part of ANSI C++ standard
in ten years?

[1] Apache Portable Runtime (APR), http://apr.apache.org/
[2] OPEN specification,
http://issues.apache.org/jira/secure/attachment/12327424/openspec.zip
[3] OPEN reference implementation,
http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/port/
[4] Boost, http://www.boost.org/

Thanks,
Alexei

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kwikius wrote:
> Bo Persson wrote:
>> ===================================== MODERATOR'S COMMENT:
>>
>> For what it's worth, I can't think of anything more on-topic than a
>> discussion of whether certain kinds of requirements in the
>> standard would make the standard unimplementable on important
>> platforms.
>
> There is of course a precedent for this in 1.4/7 of the standard.
>
> One could of course add a specification for separately named
> cross-platform types, such as integers and floats of guaranteed size
> and behaviour.  The more refined specification, would only apply to
> certain libraries. The problem occurs if libraries conforming to the
> tighter specification need to interact with libraries based on the
> looser specification. I presume when this is done by the user the
> results are back to being 'implementation defined' or undefined. One
> has crossed over the border from the virtual platform to the real
> one. Obviously the library standard developers job will be very much
> concerned with mapping the types in the virtual platform to types on
> the real platform, but clearly this removes one large problem which
> currently has to be dealt with continually by the user, which would
> seem to me as a user to be a very good thing.
>

But we also have the opposite problem, that some applications does not have
to be portable. Like inhouse development.

>From what other departments are doing right now, we know for sure that we
will have the mainframes around for the next 10-20 years. Because their work
is strategic, but definitely non-portable.

So what is the advantage of having the Java code portable, when you know
that you are not going to change platform for a decade or two?

For some of us, a little implementation defined behaviour is not a problem,
beacuse everything we do will run on this single implementation anyway.
Having a stricter language is no advantage at all, if it doesn't fit the
environment well.


Bo Persson


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Bo Persson" wrote:
> kwikius wrote:
> > Bo Persson wrote:
> >> ===================================== MODERATOR'S COMMENT:
> >>
> >> For what it's worth, I can't think of anything more on-topic than a
> >> discussion of whether certain kinds of requirements in the
> >> standard would make the standard unimplementable on important
> >> platforms.
> >
> > There is of course a precedent for this in 1.4/7 of the standard.
> >
> > One could of course add a specification for separately named
> > cross-platform types, such as integers and floats of guaranteed size
> > and behaviour.  The more refined specification, would only apply to
> > certain libraries. The problem occurs if libraries conforming to the
> > tighter specification need to interact with libraries based on the
> > looser specification. I presume when this is done by the user the
> > results are back to being 'implementation defined' or undefined. One
> > has crossed over the border from the virtual platform to the real
> > one. Obviously the library standard developers job will be very much
> > concerned with mapping the types in the virtual platform to types on
> > the real platform, but clearly this removes one large problem which
> > currently has to be dealt with continually by the user, which would
> > seem to me as a user to be a very good thing.
> >
>
> But we also have the opposite problem, that some applications does not have
> to be portable. Like inhouse development.

As far as you are concerned then there would be no change. A 'virtual
platform specification' would not affect you.

> >From what other departments are doing right now, we know for sure that we
> will have the mainframes around for the next 10-20 years. Because their work
> is strategic, but definitely non-portable.
>
> So what is the advantage of having the Java code portable, when you know
> that you are not going to change platform for a decade or two?

I can only speculate about what youre systems do. However let us say
you hold databases. From your point of view you get requests to read or
update arbitrary data and that is the end of it. At the client end you
have users who have made the requests. Very often those users are not
full time professional programmers, but many non-professionals need to
be able to present the data in a way that is meaningful and useful.
Typically from my admittedly limited experience they are likely to
start from some GUI interface, a web browser say or from an Excel
spreadsheet in MSWindows using VBA or using Java or another language
that gets the local job done as fast as possible.

universityadmin and lecturers spring to mind as a possible example of
this type of user

 And of course people move from one department to another department or
site with different hardware or someone else asks if they can have a
copy of someones useful utility. The professional programmer maybe sees
all these little applications as a nightmare but I would guess to the
people that use them they help to get their job done and get a lot of
satisfaction from which the company atmosphere benefits.  Programming
can be fun after all. It is even more fun if you can write your app
once and know that it will run anywhere.

Good managers will also see that if possible it is beneficial to try to
get all these little applications running well together, common file
formats and so on.

The above is pure speculation of course but I would guess that this is
some part of what the Java phenomenon is about.

> For some of us, a little implementation defined behaviour is not a problem,
> beacuse everything we do will run on this single implementation anyway.
> Having a stricter language is no advantage at all, if it doesn't fit the
> environment well.

I guess the only interest you need to have is to make sure that a
virtual platform spec is as efficient as possible to avoid tieing up
your servers, but apart from that I don't see your applications being
affected.

And BTW the idea of a C++ virtual platform is no more than that, but
its an interesting concept to think about. In fact maybe it ties in
quite well with the ConceptC++ proposals:

http://www.generic-programming.org/languages/conceptcpp/

At one level C++ embraces the idea of abstraction, but at the other it
chains you to a particular platform, a weird mix.

I have no idea whether an Int32 Concept would fly... Maybe I should
experiment with that.

regards
Andy Little

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"kwikius" <andy@servocomm.freeserve.co.uk> wrote in message
news:1165052792.130434.269920@79g2000cws.googlegroups.com...
> Programming
> can be fun after all. It is even more fun if you can write your app
> once and know that it will run anywhere.
>
> Good managers will also see that if possible it is beneficial to try to
> get all these little applications running well together, common file
> formats and so on.
>
> The above is pure speculation of course but I would guess that this is
> some part of what the Java phenomenon is about.

If I take some creative liberty and assign your last speculative comment and
associate it with the preceding, but elimininating all the stuff you wrote
when
you first used "speculate", I think you're right on track and that it is
"obvious".
I too am the one who makes things relatively "rediculously simple" akin to
your "virtual platform" ambitions, and have loads-O-fun doing it too!


>> For some of us, a little implementation defined behaviour is not a
>> problem,
>> beacuse everything we do will run on this single implementation anyway.
>> Having a stricter language is no advantage at all, if it doesn't fit the
>> environment well.
>
> I guess the only interest you need to have is to make sure that a
> virtual platform spec is as efficient as possible to avoid tieing up
> your servers, but apart from that I don't see your applications being
> affected.

Not to rag on "efficiency and performance", but how many developers
even have to worry about that anymore (as in server and desktop programs)?
(the considered more relevant parameter omitted from public forum: feel
free to try to get that out of me in private discussion though). (hehe,
feeling
cocky or something).

> And BTW the idea of a C++ virtual platform is no more than that,

No more than what?

> but its an interesting concept to think about. In fact maybe it ties in
> quite well with the ConceptC++ proposals:
>
> http://www.generic-programming.org/languages/conceptcpp/

I read two lines and relegated it to all that "templates and partial
specialization" nausea from the language groups. What concept there
do you find attractive?

> At one level C++ embraces the idea of abstraction, but at the other it
> chains you to a particular platform, a weird mix.

And that platform is? Perhaps you like the multi-language infliction upon
all programming that MS promotes? (Can someone puh-leeze shoot fatally
Basic already?!)

> I have no idea whether an Int32 Concept would fly... Maybe I should
> experiment with that.

Wow, where did that come from? You mean integer types that a developer
could rely on to be a specific number of bits or bytes and order?

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Tony" wrote:

<...>

> > And BTW the idea of a C++ virtual platform is no more than that,
>
> No more than what?

A C++ virtual platform is AFAIK no more than an idea. There is no
current cross platform standard AFAIK.  FWIW I started looking at
strongly defined  types with my Quan library:

http://quan.sourceforge.net/quan_matters/doc/html/index.html

That class template essentially provides constraints far above what you
get for built-in types, when working with physical quantities. I now
use that library a lot. Iit makes work much easier. Using it in
preference to builtin types is analogous to walking on a nice lawn
rather than through a bog.

The problems in the implementation of Quan stemmed largely from the
fact that usually Quan is  wrapping a builtin type directly and the
builtin types in C++ arent very well defined. I'm now thinking of using
the similar techniques to build some 'strong' integer and real types
with the goal of platform independence. The interesting part is at the
boundary between builtin types and strong types, IOW what happens when
you step off the lawn and into the quagmire , and vice versa.

> > but its an interesting concept to think about. In fact maybe it ties in
> > quite well with the ConceptC++ proposals:
> >
> > http://www.generic-programming.org/languages/conceptcpp/
>
> I read two lines and relegated it to all that "templates and partial
> specialization" nausea from the language groups. What concept there
> do you find attractive?

Basically the fact that you don't need to use enable_if everywhere...
It should also help you not to need to work through huge compiler error
messages. and just make life easier. I like it again because it should
mean I don't have to think so much. I like anything like that:-)

Overall though it allows you to deal in terms of abstractions. You cant
do that properly if you are tied to hardware.

> > At one level C++ embraces the idea of abstraction, but at the other it
> > chains you to a particular platform, a weird mix.
>
> And that platform is?

Some compiler hardware combo. In C++ the way youre application behaves
is very much a function of  the hardware its running on. That is a
'feature'.

> > I have no idea whether an Int32 Concept would fly... Maybe I should
> > experiment with that.
>
> Wow, where did that come from? You mean integer types that a developer
> could rely on to be a specific number of bits or bytes and order?

I certainly think that the maximum and minimum values are important,
preventing lossy conversions and not providing automatic conversions
between integers and reals. These two sets of types have very different
properties.

I don't think byte order is important unles you walk outside the type
and back into the bog.

regards
Andy Little

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"kwikius" <andy@servocomm.freeserve.co.uk> wrote in message
news:1165244571.655235.4750@80g2000cwy.googlegroups.com...
>
> "Tony" wrote:
>
> <...>
>
>> > And BTW the idea of a C++ virtual platform is no more than that,
>>
>> No more than what?
>
> A C++ virtual platform is AFAIK no more than an idea.

There's probably been as many cross-platform APIs developed (partially
or wholly) as there are C++ programmers. I'd say it's a well-evolved
concept. But you're right of course about no standard. But some people
prefer to roll their own.

>> > At one level C++ embraces the idea of abstraction, but at the other it
>> > chains you to a particular platform, a weird mix.
>>
>> And that platform is?
>
> Some compiler hardware combo. In C++ the way youre application behaves
> is very much a function of  the hardware its running on. That is a
> 'feature'.

OK.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Bo Persson wrote:
> ===================================== MODERATOR'S COMMENT:
>
> For what it's worth, I can't think of anything more on-topic than a
> discussion of whether certain kinds of requirements in the standard would
> make the standard unimplementable on important platforms.

There is of course a precedent for this in 1.4/7 of the standard.

One could of course add a specification for separately named
cross-platform types, such as integers and floats of guaranteed size
and behaviour.  The more refined specification, would only apply to
certain libraries. The problem occurs if libraries conforming to the
tighter specification need to interact with libraries based on the
looser specification. I presume when this is done by the user the
results are back to being 'implementation defined' or undefined. One
has crossed over the border from the virtual platform to the real one.
Obviously the library standard developers job will be very much
concerned with mapping the types in the virtual platform to types on
the real platform, but clearly this removes one large problem which
currently has to be dealt with continually by the user, which would
seem to me as a user to be a very good thing.

regards
Andy Little

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]