http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* conversion to non-scalar type error in inheritance hierarchy - 6 messages, 4
authors
http://groups.google.com/group/comp.lang.c++/t/9592afdb621f02f7?hl=en
* Different treatment of the NodeType of LinkedList in C++ and Java - 4
messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/f3cf235e1c61e0af?hl=en
* c++0x pods and constructors - 4 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/5aa5848ff079613f?hl=en
* Binary file IO: Converting imported sequences of chars to desired type - 2
messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/690c45c0197f60ef?hl=en
* is LISP the ultimate prgram language? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/90582c87e16a1cd9?hl=en
* (partially solved) includes algorithm not working properly on sets of
strings - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/0e46582a99756035?hl=en
* value & default initialization, and copy initialization - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/497940ea6f9d0edb?hl=en
==============================================================================
TOPIC: conversion to non-scalar type error in inheritance hierarchy
http://groups.google.com/group/comp.lang.c++/t/9592afdb621f02f7?hl=en
==============================================================================
== 1 of 6 ==
Date: Thurs, Oct 29 2009 8:20 am
From: kmw
Hello,
I am working on container class with different implementations and
want to add stl-style iterators. Now, I am confronted with a
"conversion to non-scalar type" error which I do not understand. Any
comments are appreciated. Many thanks in advance!
The interface for the different implementations is defined in the base
class A. A1 is one implementation. B is the iterator base class and C
its implementation in A1. I really do not see a problem since C
inherits from B but the compiler says:
test.cpp: In function 'int main()':
test.cpp:34: error: conversion from 'A<int>::B' to non-scalar type
'A1<int>::C' requested
Best regards,
Kay
Code:
template <class X>
class A
{
public:
class B
{
public:
virtual ~B () {}
virtual void method () {}
};
virtual ~A () {}
virtual B begin ()=0;
};
template <class X>
class A1 : public A<X>
{
public:
class C : public A<X>::B
{
public:
~C () {}
void method ( ) {}
};
~A1 () {}
typename A<X>::B begin ( )
{
C test;
return test;
}
};
int main ( )
{
A1<int> test;
A1<int>::C test_it = test.begin ();
return 0;
}
== 2 of 6 ==
Date: Thurs, Oct 29 2009 8:29 am
From: Victor Bazarov
kmw wrote:
> Hello,
>
> I am working on container class with different implementations and
> want to add stl-style iterators. Now, I am confronted with a
> "conversion to non-scalar type" error which I do not understand. Any
> comments are appreciated. Many thanks in advance!
>
> The interface for the different implementations is defined in the base
> class A. A1 is one implementation. B is the iterator base class and C
> its implementation in A1. I really do not see a problem since C
> inherits from B but the compiler says:
>
> test.cpp: In function 'int main()':
> test.cpp:34: error: conversion from 'A<int>::B' to non-scalar type
> 'A1<int>::C' requested
You do not see the problem? How about here:
class B {};
class C : public B {};
B foo();
int main()
{
C c = foo();
}
Do you get the same error?
>
> Best regards,
> Kay
>
> Code:
> template <class X>
> class A
> {
> public:
> class B
> {
> public:
> virtual ~B () {}
> virtual void method () {}
> };
> virtual ~A () {}
> virtual B begin ()=0;
> };
> template <class X>
> class A1 : public A<X>
> {
> public:
> class C : public A<X>::B
> {
> public:
> ~C () {}
> void method ( ) {}
> };
> ~A1 () {}
> typename A<X>::B begin ( )
> {
> C test;
> return test;
> }
> };
> int main ( )
> {
> A1<int> test;
> A1<int>::C test_it = test.begin ();
>
> return 0;
> }
There is no conversion from the base class to the derived class. You
have to define this conversion if you want it to exist.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
== 3 of 6 ==
Date: Thurs, Oct 29 2009 8:42 am
From: kmw
Well, yes. Your code gives me the same error. I see the conversion
problem now. Thanks for clarifying. Of course I don't want explicit
conversion from the base class into the inherited classes. But how can
I achieve such kind of "parallel" inheritance? That is, 'C' is
accepted as 'B' in 'A1'. I know I could do it with reference returns
but that's not in accordance to the stl-iterator approach.
Cheers,
Kay
On Oct 29, 4:29 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> kmw wrote:
> > Hello,
>
> > I am working on container class with different implementations and
> > want to add stl-style iterators. Now, I am confronted with a
> > "conversion to non-scalar type" error which I do not understand. Any
> > comments are appreciated. Many thanks in advance!
>
> > The interface for the different implementations is defined in the base
> > class A. A1 is one implementation. B is the iterator base class and C
> > its implementation in A1. I really do not see a problem since C
> > inherits from B but the compiler says:
>
> > test.cpp: In function 'int main()':
> > test.cpp:34: error: conversion from 'A<int>::B' to non-scalar type
> > 'A1<int>::C' requested
>
> You do not see the problem? How about here:
>
> class B {};
> class C : public B {};
>
> B foo();
>
> int main()
> {
> C c = foo();
> }
>
> Do you get the same error?
>
>
>
>
>
> > Best regards,
> > Kay
>
> > Code:
> > template <class X>
> > class A
> > {
> > public:
> > class B
> > {
> > public:
> > virtual ~B () {}
> > virtual void method () {}
> > };
> > virtual ~A () {}
> > virtual B begin ()=0;
> > };
> > template <class X>
> > class A1 : public A<X>
> > {
> > public:
> > class C : public A<X>::B
> > {
> > public:
> > ~C () {}
> > void method ( ) {}
> > };
> > ~A1 () {}
> > typename A<X>::B begin ( )
> > {
> > C test;
> > return test;
> > }
> > };
> > int main ( )
> > {
> > A1<int> test;
> > A1<int>::C test_it = test.begin ();
>
> > return 0;
> > }
>
> There is no conversion from the base class to the derived class. You
> have to define this conversion if you want it to exist.
>
> V
> --
> Please remove capital 'A's when replying by e-mail
> I do not respond to top-posted replies, please don't ask
== 4 of 6 ==
Date: Thurs, Oct 29 2009 8:43 am
From: "Alf P. Steinbach"
* kmw:
> Hello,
>
> I am working on container class with different implementations and
> want to add stl-style iterators.
It may be easiest to write a templated wrapper that uses some underlying
conventional named methods interface to provide STL iterator functionality.
> Now, I am confronted with a
> "conversion to non-scalar type" error which I do not understand. Any
> comments are appreciated. Many thanks in advance!
>
> The interface for the different implementations is defined in the base
> class A. A1 is one implementation. B is the iterator base class and C
> its implementation in A1. I really do not see a problem since C
> inherits from B but the compiler says:
>
> test.cpp: In function 'int main()':
> test.cpp:34: error: conversion from 'A<int>::B' to non-scalar type
> 'A1<int>::C' requested
>
> Best regards,
> Kay
>
> Code:
> template <class X>
> class A
> {
> public:
> class B
> {
> public:
> virtual ~B () {}
> virtual void method () {}
> };
> virtual ~A () {}
> virtual B begin ()=0;
> };
> template <class X>
> class A1 : public A<X>
> {
> public:
> class C : public A<X>::B
> {
> public:
> ~C () {}
> void method ( ) {}
> };
> ~A1 () {}
> typename A<X>::B begin ( )
> {
> C test;
> return test;
> }
Not related to the compilation error, but a logical error: this begin() function
always produces an A<X>::B object. It doesn't matter that that object is
initialized from a C object. When it's returned it's a B object, and calls to
method will invoke B::method.
> };
> int main ( )
> {
> A1<int> test;
> A1<int>::C test_it = test.begin ();
test.begin() produces a B object. Class C does not provide any constructor that
takes a B object. A B object cannot be implicitly converted down to the more
specialized C object (the inheritance goes the wrong way).
>
> return 0;
> }
Cheers & hth.,
- Alf
== 5 of 6 ==
Date: Thurs, Oct 29 2009 8:47 am
From: kmw
> It may be easiest to write a templated wrapper that uses some underlying
> conventional named methods interface to provide STL iterator functionality.
Thanks for the hint. Could you give a small code snippet to ease my
understanding? That would be great!
I see the problem with the inheritance 'in the wrong way' now. Also,
thanks for this.
Cheers,
Kay
On Oct 29, 4:43 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * kmw:
>
> > Hello,
>
> > I am working on container class with different implementations and
> > want to add stl-style iterators.
>
> It may be easiest to write a templated wrapper that uses some underlying
> conventional named methods interface to provide STL iterator functionality.
>
>
>
> > Now, I am confronted with a
> > "conversion to non-scalar type" error which I do not understand. Any
> > comments are appreciated. Many thanks in advance!
>
> > The interface for the different implementations is defined in the base
> > class A. A1 is one implementation. B is the iterator base class and C
> > its implementation in A1. I really do not see a problem since C
> > inherits from B but the compiler says:
>
> > test.cpp: In function 'int main()':
> > test.cpp:34: error: conversion from 'A<int>::B' to non-scalar type
> > 'A1<int>::C' requested
>
> > Best regards,
> > Kay
>
> > Code:
> > template <class X>
> > class A
> > {
> > public:
> > class B
> > {
> > public:
> > virtual ~B () {}
> > virtual void method () {}
> > };
> > virtual ~A () {}
> > virtual B begin ()=0;
> > };
> > template <class X>
> > class A1 : public A<X>
> > {
> > public:
> > class C : public A<X>::B
> > {
> > public:
> > ~C () {}
> > void method ( ) {}
> > };
> > ~A1 () {}
> > typename A<X>::B begin ( )
> > {
> > C test;
> > return test;
> > }
>
> Not related to the compilation error, but a logical error: this begin() function
> always produces an A<X>::B object. It doesn't matter that that object is
> initialized from a C object. When it's returned it's a B object, and calls to
> method will invoke B::method.
>
> > };
> > int main ( )
> > {
> > A1<int> test;
> > A1<int>::C test_it = test.begin ();
>
> test.begin() produces a B object. Class C does not provide any constructor that
> takes a B object. A B object cannot be implicitly converted down to the more
> specialized C object (the inheritance goes the wrong way).
>
>
>
> > return 0;
> > }
>
> Cheers & hth.,
>
> - Alf
== 6 of 6 ==
Date: Thurs, Oct 29 2009 9:48 am
From: James Kanze
On Oct 29, 3:20 pm, kmw <wuerz...@gmail.com> wrote:
> I am working on container class with different implementations
> and want to add stl-style iterators. Now, I am confronted with
> a "conversion to non-scalar type" error which I do not
> understand. Any comments are appreciated. Many thanks in
> advance!
> The interface for the different implementations is defined in
> the base class A. A1 is one implementation. B is the iterator
> base class and C its implementation in A1. I really do not see
> a problem since C inherits from B but the compiler says:
> test.cpp: In function 'int main()':
> test.cpp:34: error: conversion from 'A<int>::B' to non-scalar type
> 'A1<int>::C' requested
> Code:
> template <class X>
> class A
> {
> public:
> class B
> {
> public:
> virtual ~B () {}
> virtual void method () {}
> };
> virtual ~A () {}
> virtual B begin ()=0;
> };
> template <class X>
> class A1 : public A<X>
> {
> public:
> class C : public A<X>::B
> {
> public:
> ~C () {}
> void method ( ) {}
> };
> ~A1 () {}
> typename A<X>::B begin ( )
> {
> C test;
> return test;
> }
> };
> int main ( )
> {
> A1<int> test;
> A1<int>::C test_it = test.begin ();
> return 0;
> }
You'll get the same problems without the iterators. The most
obvious problem (and why the compiler is complaining) is that
you're returning a A::B, and trying to use it to initialize an
A1::C; you can't normally use a base type to initialize a
derived type. The obvious solution for this is to use covariant
return types, except that covariant returns only work with
pointers and references, not with values.
Which brings us to the more general problem: Once A1::begin has
returned an A::B, all you have is an A::B---slicing has occured.
More generally, polymorphism only works through references or
pointers (and polymorphic classes should not generally be copied
or assigned). If you want the returned iterator to behave
polymorphically, you'll have to use some variant of the
letter/envelope or the handle idiom; for STL semantics, you'll
need deep copy, which will make copying iterators expensive.
--
James Kanze
==============================================================================
TOPIC: Different treatment of the NodeType of LinkedList in C++ and Java
http://groups.google.com/group/comp.lang.c++/t/f3cf235e1c61e0af?hl=en
==============================================================================
== 1 of 4 ==
Date: Thurs, Oct 29 2009 9:02 am
From: "yangsuli@gmail.com"
On 10月29日, 上午5时18分, James Kanze <james.ka...@gmail.com> wrote:
> On Oct 28, 9:14 pm, "yangs...@gmail.com" <yangs...@gmail.com> wrote:
>
> > I am a student who is taking the data structure course. When
> > we are learning the data structure LinkedList, I noticed that
> > Java and C++ treated the type of the node of Linkedlist
> > differently.
> > In STL, C++ actually publishes the typed of list_node:
> > class List{
> > protected:
> > typedef __list_node<T> list_node:
> > ....
> > }
>
> I suppose you miscopied something, since the name of the class
> in the standard is list, not List. And the "exposition" of the
> node type is probably due to some techical implementation issue;
> it's not officially exposed, as part of the documented interface
> in the standard.
>
> > But in Java, the class of LinkedListNode has package access,
> > so the user of LinkedList won't even see this node type.
>
> Package access is less protective than protected access in C++
> (or in Java). With protected access, the only way to access the
> name is to derive from the class. With package access, you can
> either derive from the class, or declare another class as a
> member of the same package.
>
> > Personally, I wound think the type of node is the
> > implementation detail, and the best practice is to hide it
> > from the user.
>
> Agreed. On the other hand, there can be technical reasons for
> exposing it, partially or completely: in my pre-standard
> DLListOf, it was fully private, but in my pre-standard
> AssocArrayOf, the node base type was a protected member of the
> (non-templated) base class.
>
> > But I am posting this message to see, is there any particular
> > reason that C++ choose to publish the list_node type?
>
> C++ doesn't publish it, or even require it to exist (although I
> don't see how you could implement std::list without it).
>
> > Does this has something to do with the difference in this two
> > languages?
>
> I don't really think so. I don't really see why it isn't
> private in both cases, but I suspect that there are some
> technical issues involved. (In the case of Java, it might be
> protected or package in order to facilitate the implementation
> of some more strongly typed derived class. In the case of C++,
> I don't see any real reason.)
>
> --
> James Kanze
I think I should clearify somethings:
1. I copied the code from the book "the annotated STL source (using
SGI STL)". Now I realied that it may just be a particular
implementation of STL, but not a standard requirment in the STL
standard. But I am still curious about why it is so.
2. Yes, it could be a techinical issue. But I am asking this question
because I don't know a mechanism in C++ that can prevents the user
from using a particular type.(say, a user had a veriable of
__list_node type. It does not make too much sense, but he or she has
the ability to do this). On the other hand, by making listnode class
package access in Java, one can never do such a thing. The type
itsself has been hided. I am just wondering, can we do this in C++?
3. Sure it can not be private! Actually, what do you mean by making a
type(class) private?
Thank you all by answering my question.
Yang Suli
== 2 of 4 ==
Date: Thurs, Oct 29 2009 9:56 am
From: James Kanze
On Oct 29, 4:02 pm, "yangs...@gmail.com" <yangs...@gmail.com> wrote:
> On 10月29日, 上午5时18分, James Kanze <james.ka...@gmail.com> wrote:
[...]
> I think I should clearify somethings:
[...]
> 2. Yes, it could be a techinical issue. But I am asking this
> question because I don't know a mechanism in C++ that can
> prevents the user from using a particular type.(say, a user
> had a veriable of __list_node type. It does not make too much
> sense, but he or she has the ability to do this). On the other
> hand, by making listnode class package access in Java, one can
> never do such a thing. The type itsself has been hided. I am
> just wondering, can we do this in C++?
In both Java and C++, you can very easily make the type private,
so that it cannot be seen (Java) or accessed (C++) from any
other class.
> 3. Sure it can not be private! Actually, what do you mean by making a
> type(class) private?
Exactly what you mean by making anything else private. If
something is declared private: in Java, it is invisible outside
of the class; in C++, it's name cannot be used outside of the
class. For something like a double linked list of int, for
example:
class IntList
{
private:
struct Node
{
Node* next;
Node* prev;
int value;
};
Node* root;
public:
// ...
};
The type Node cannot be accessed outside of IntList.
--
James Kanze
== 3 of 4 ==
Date: Thurs, Oct 29 2009 10:55 am
From: Lew
yangs...@gmail.com wrote:
> 3. Sure it can not be private! Actually, what do you mean by making a
> type(class) private?
>
In Java this is only possible with member types. It means that only
the class of which the type is a member, and that enclosing class's
members, have access to that type. In that it is just like any other
'private' member.
Again, see
<http://java.sun.com/docs/books/tutorial/java/javaOO/
accesscontrol.html>
That explains very simply the four access types in Java - public,
protected, default ("package-private") and private. The rules apply
to all members be they method, variable or nested type. The complete
rules are, of course, spelled out in detail in the Java Language
Specification (JLS).
--
Lew
== 4 of 4 ==
Date: Thurs, Oct 29 2009 2:03 pm
From: "Mike Schilling"
James Kanze wrote:
> STL means different things to different people. The acronym
> stands for "Standard Template Library"; Stepanov chose it before
> there was a standard C++ library. In current use, it can mean
> Stepanov's original library (without the changes introduced by
> the standard, but with some parts not adopted by the standard),
> the parts of the C++ standard library derived from Stepanov's
> work, or simply the C++ standard library.
That is "STL" may means the standard, part of the standard, or
something non-standard. And people think C++ is complicated!
==============================================================================
TOPIC: c++0x pods and constructors
http://groups.google.com/group/comp.lang.c++/t/5aa5848ff079613f?hl=en
==============================================================================
== 1 of 4 ==
Date: Thurs, Oct 29 2009 9:23 am
From: Jerry Coffin
In article <VV%Fm.41268$EU5.38030@newsfe05.iad>,
spambuster@prodigy.net says...
>
> Can C++0x PODs/aggregates have user-defined constructors and still be
> PODs/aggregates? If not, why not? How about conversion operators? And what
> is the difference between a POD and an aggregate anyway?
In C++ 0x, the definition of POD no longer includes the requirement
that the class be an aggregate. Instead, it introduces a couple of
new terms, "standard layout class" and "trivial class". A POD has to
be both. A user-defined constructor (by itself) does _not_ prevent
the class from being a POD -- but you have to be really careful. In
particular, a non-trivial copy constructor or non-trivial destructor
_does_ prevent it from being a trivial class (IOW, copying with
memcpy/memmove should work correctly).
A standard layout class basically says it can't have virtual
functions or virtual base classes, etc.
As long as it fits both of those sets of restrictions, it's a POD.
IOW, it _can_ have some "convenience ctors".
Obviously I'm leaving out some of the details -- see N2960, §9/5, 9/6
for the full details.
--
Later,
Jerry.
== 2 of 4 ==
Date: Thurs, Oct 29 2009 4:40 pm
From: "dragan"
Victor Bazarov wrote:
> dragan wrote:
>> Can C++0x PODs/aggregates have user-defined constructors and still be
>> PODs/aggregates?
>
> From [dcl.init.aggr]:
> << 1 An aggregate is an array or a class (Clause 9) with no
> user-provided constructors (12.1), no private or
> protected non-static data members (Clause 11), no base classes (Clause
> 10), and no virtual functions (10.3). >>
>
> So, no, once you add a user-defined c-tor, it's not an aggregate.
I'm not sure what aggregates are good for. I think POD may be the key thing
for layout compatibility with C and probably other languages. PODs no longer
have to be aggregates in C++0x: they can have constructors, just not default
or copy constructors, and no copy assignment operator. (N2690).
>> How about conversion operators?
>
> You can have conversion operators in an aggregate (according to the
> definition), if other conditions are met.
I assume in a POD also.
== 3 of 4 ==
Date: Thurs, Oct 29 2009 4:51 pm
From: "dragan"
Johannes Schaub (litb) wrote:
> dragan wrote:
>
>> Can C++0x PODs/aggregates have user-defined constructors and still be
>> PODs/aggregates? If not, why not? How about conversion operators?
>> And what is the difference between a POD and an aggregate anyway?
>
> Aggregates but not PODs, both in C++03 and C++0x:
>
> string foo[10];
> struct bar {
> string baz;
> };
>
> In C++0x, you can use memcpy on trivially copyable types. POD is too
> strict a requirement for this - so if you just want to use memcpy on
> a type for example, making a type trivially copyable would suffice,
> in particular:
>
> - has no non-trivial copy constructors (12.8),
> - has no non-trivial copy assignment operators (13.5.3, 12.8), and
> - has a trivial destructor (12.4).
>
> A trivial class then is a class that is trivially copyable and that
> has a trivial default constructor. F is trivial and G is trivially
> copyable:
>
> struct F { Foo() = default; F(int a):a(a) { } int a; };
> struct G { Foo(int a):a(a) { } int a; };
>
> For other things, a class has to be a standard layout class. Thus is
> true for "offsetof", to inspect a common initial sequence when two
> such structs are in an union, etc. Look up the details in the latest
> draft at 9/6.
>
> A POD is a class is trivial and a standard layout class and has no
> members of non-POD etc... . Actually, i haven't found something in
> the c++0x language in 2960 that still requires things to be PODs.
> Things either seem to refer to standard layout classes or trivially
> copyable.
But a POD is what you want to talk with C and other languages is what I
gather.
== 4 of 4 ==
Date: Thurs, Oct 29 2009 4:56 pm
From: "dragan"
Jerry Coffin wrote:
> In article <VV%Fm.41268$EU5.38030@newsfe05.iad>,
> spambuster@prodigy.net says...
>>
>> Can C++0x PODs/aggregates have user-defined constructors and still be
>> PODs/aggregates? If not, why not? How about conversion operators?
>> And what is the difference between a POD and an aggregate anyway?
>
> In C++ 0x, the definition of POD no longer includes the requirement
> that the class be an aggregate. Instead, it introduces a couple of
> new terms, "standard layout class" and "trivial class". A POD has to
> be both. A user-defined constructor (by itself) does _not_ prevent
> the class from being a POD -- but you have to be really careful. In
> particular, a non-trivial copy constructor or non-trivial destructor
> _does_ prevent it from being a trivial class (IOW, copying with
> memcpy/memmove should work correctly).
>
> A standard layout class basically says it can't have virtual
> functions or virtual base classes, etc.
>
> As long as it fits both of those sets of restrictions, it's a POD.
> IOW, it _can_ have some "convenience ctors".
That's good news. That a POD can be derived from another class is also good
news. What kind of class it can be after derived though is still unclear to
me: can it have non-static data members?
>
> Obviously I'm leaving out some of the details -- see N2960, §9/5, 9/6
> for the full details.
I downloaded N2960. I like to think in terms of the things a POD can or
cannot have rather than the lingo like: trivially copyable, trivial class,
standard layout, and on and on. In another post I wrote my understanding of
what is and isn't allowed.
==============================================================================
TOPIC: Binary file IO: Converting imported sequences of chars to desired type
http://groups.google.com/group/comp.lang.c++/t/690c45c0197f60ef?hl=en
==============================================================================
== 1 of 2 ==
Date: Thurs, Oct 29 2009 9:36 am
From: James Kanze
On Oct 29, 2:02 pm, Rune Allnor <all...@tele.ntnu.no> wrote:
> On 29 Okt, 11:00, James Kanze <james.ka...@gmail.com> wrote:
> ...
> > Compiled with "cl /EHs /O2 timefmt.cc". On my local disk here,
> > I get:
> > text: 90 sec.
> > cooked: 31 sec.
> > raw: 9 sec.
> > The last is, of course, not significant, except that it is
> > very small. (I can't run it on the networked disk, where
> > any real data would normally go, because it would use too
> > much network bandwidth, possibly interfering with others.
> > Suffice it to say that the networked disk is about 5 or more
> > times slower, so the relative differences would be reduced
> > by that amount.) I'm not sure what's different in the code
> > above (or the environment---I suspect that the disk
> > bandwidth is higher here, since I'm on a professional PC,
> > and not a "home computer") compared to my tests at home
> > (under Windows); at home, there was absolutely no difference
> > in the times for raw and cooked. (Cooked is, of course, XDR
> > format, at least on a machine like the PC, which uses IEEE
> > floating point.)
> Hmm.... so everything was done on your local disc? Which means
> one would expect that disk I/O delays are proportional to file
> sizes?
More or less. There are also caching effects, which I've not
tried to mask or control, which means that the results should be
taken with a grain of salt. More generally, there are a lot of
variables involved, and I've not made any attempts to control
any of them, which probably explains the differences I'm seeing
from one machine to the next.
> If so, the raw/cooked binary formats are a bit confusing.
> According to this page,
> http://publib.boulder.ibm.com/infocenter/systems//index.jsp?topic=/co...
> the XDR data type format uses "the IEEE standard" (I can find
> no mention of exactly *which* IEEE standard...) to encode both
> single- precision and double-precision floating point numbers.
> IF "the IEEE standard" happens to mean "IEEE 754" there is a
> chance that an optimizing compiler might deduce that re-coding
> numbers on IEEE 754 format to another number on IEEE 754
> format essentially is a No-Op.
I'm not sure what you're referring to. My "cooked" format is a
simplified, non-portable implementation of XDR---non portable
because it only works on machines which have 64 long longs and
use IEEE floating point.
> Even if XDR uses some other format than IEEE754, your numbers
> show one significant effect:
> 1) Double-precision XDR is of the same size as double-precision
> IEEE 754 (64 bits / number).
> 2) Handling XDR takes significantly longer than handling native
> binary formats.
Again, that depends on the machine. On my tests at home, it
didn't. I've not had the occasion to determine where the
difference lies.
> Since you run the test with the same amopunts of data on the
> same local disk with the same delay factors,
I don't know whether the delay factor is the same. A lot
depends on how the system caches disk accesses. A more
significant test would use synchronized writing, but
synchronized at what point?
> this factor ~4 of longer time spent on handling XDR data must
> be explained by something else than mere disk IO.
*IF* there is no optimization, *AND* disk accesses cost nothing,
then a factor of about 4 sounds about right.
> The obvious suspect is the extra manipulations and recoding of
> XDR data. Where native-format binary IO only needs to perform
> a memcpy from the file buffer to the destination, the XDR data
> first needs to be decoded to an intermediate format, and then
> re-encoded to the native binary format before the result can
> be piped on to the destination.
> The same happens - but on a larger scale - when dealing with
> text-based formats:
> 1) Verify that the next sequence of characters represent a
> valid number format
> 2) Decide how many glyphs need to be considered for decoding
> 3) Decode text characters to digits
> 4) Scale according to digit placement in number
> 5) Repeat for exponent
> 6) Do the math to compute the number
That's input, not output. Input is significantly harder for
text, since it has to be able to detect errors. For XDR, the
difference between input and output probably isn't signficant,
since the only error that you can really detect is an end of
file in the middle of a value.
> True, this takes insignificant amounts of time when compared
> to disk IO, but unless you use a multi-thread system where one
> thread reads from disk and another thread converts the formats
> while one waits for the next batch of data to arrive from the
> disk, one have to do all of this sequentially in addition to
> waiting for disk IO.
> Nah, I still think that any additional non-trivial handling of
> data will impact IO times of data. In single-thread
> environments.
You can always use asynchronous IO:-). And what if your
implementation of filebuf uses memory mapped files?
The issues are extremely complex, and can't easily be
summarized. About the most you can say is that using text I/O
won't increase the time more than about a factor of 10, and may
increase it significantly less. (I wish I could run the tests
on the drives we usually use---I suspect that the difference
between text and binary would be close to negligible, because of
the significantly lower data transfer rates.)
--
James Kanze
== 2 of 2 ==
Date: Thurs, Oct 29 2009 1:18 pm
From: Gerhard Fiedler
James Kanze wrote:
>> Re the precision issue: When writing out text, there isn't really a
>> need to go decimal, too. Hex or octal numbers are also text. Speeds
>> up the conversion (probably not by much, but still) and provides a
>> way to write out the exact value that is in memory (and recreate
>> that exact value -- no matter the involved precisions).
>
> But it defeats one of the major reasons for using text: human
> readability.
Not that much. For (casual, not precision) reading, a few digits are
usually enough, and most people who read this type of output (meant to
be communication between programs) are programmers, hence typically
reasonably fluent in octal and hex. The most important issue is that the
fields (mantissa sign, mantissa, exponent sign, exponent, etc.) are
decoded and appropriately presented. Whether the mantissa and the
exponent are then in decimal, octal or hexadecimal IMO doesn't make much
of a difference.
Since what we're talking about is only relevant for huge amounts of
data, doing anything more with that data than just a cursory look at
some numbers (which IMO is fine in octal or hex) generally needs a
program anyway.
Gerhard
==============================================================================
TOPIC: is LISP the ultimate prgram language?
http://groups.google.com/group/comp.lang.c++/t/90582c87e16a1cd9?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Oct 29 2009 10:32 am
From: Jerry Coffin
In article <f3ef9bcf-5008-4892-b1da-3e9c45fff360
@j4g2000yqe.googlegroups.com>, james.kanze@gmail.com says...
[ ... ]
> I'm not sure that macros were added because C was trying to be
> like assembler---C's macros are a lot weaker than anything I've
> seen in assembler---, but what is sure is that all assemblers
> back then did have some support for macros, and that the people
> developing C were very familiar with assembler, and macro
> technology, so when the need for e.g. "inline functions" was
> felt, macros would be a more or less natural response.
Right -- I didn't mean to imply that it was necessarily an attempt at
being like an assembler, just that they seem to be looking for a
relatively obscure source, when a much more obvious one is available.
> What I don't get is Lisp proponents trying to imply that C
> macros are derived from Lisp. Even if it were true, it's
> something that I'd try to hide, rather than claim credit for;
> C's preprocessor are not exactly the best feature of the
> language.
How can you ask such foolish question? They're on a chivalrous quest!
Lisp will now be called "Dulcinea", and they will protect all from
the cruel windmills! :-)
--
Later,
Jerry.
==============================================================================
TOPIC: (partially solved) includes algorithm not working properly on sets of
strings
http://groups.google.com/group/comp.lang.c++/t/0e46582a99756035?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Oct 29 2009 10:43 am
From: Richard Herring
[crosspost to clcm dropped - it's not a good idea to crosspost between
moderated and unmoderated groups]
In message
<5555551e-3a86-4864-8984-3fc26eed2b83@y10g2000prg.googlegroups.com>,
suresh.amritapuri <suresh.amritapuri@gmail.com> writes
>Thanks for the inputs. I solved my initial problem by adding the
>function object into the template parameter.
I don't think so...
>But now I have the new problem. My actual objective is to find out that
>two sets of strings are equal, if one string from one set beings with
>another string in the other set. Kindly look at the code below and give
>your valuable comments.
>struct areql{
> bool operator()(string x, string y)
> {
> return (starts_with(x,y)||starts_with(y,x));
> }
>
>};
Bad name. It's not testing for equality. (Nor should it be.)
You *still* need to read the documentation of std::includes (and now
std::set, too), and find out what they say the predicate is supposed to
do.
Hint: 'is_less' would be a far better name than 'areql'
--
Richard Herring
==============================================================================
TOPIC: value & default initialization, and copy initialization
http://groups.google.com/group/comp.lang.c++/t/497940ea6f9d0edb?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Oct 29 2009 4:21 pm
From: Taras_96
Hi Kai,
On Oct 29, 7:46 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
> Just one remark not relating to initialization: the line
>
> Foo foo();
>
> does not define a Foo object named foo, but declares a function foo()
> without arguments and return type Foo.
Yes of course, I knew that :*).
>
> And another remark about value initialization and default initialization: in
> the case of the given class, I think, there is no observable difference. For
> objects of class type with a user-declared default constructor, value
> initialization just calls the default constructor (which has to be
> accessible).
I believe that value & default initializations are slightly different,
see: http://groups.google.com/group/comp.lang.c++/msg/904a1bb3d44a8690.
Does everything else seem correct?
Taras
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment