http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* c++0x pods and constructors - 7 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/5aa5848ff079613f?hl=en
* Different treatment of the NodeType of LinkedList in C++ and Java - 5
messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/f3cf235e1c61e0af?hl=en
* CLI command line interface compiler for C++ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/cd86a54cab3d4055?hl=en
* value & default initialization, and copy initialization - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/497940ea6f9d0edb?hl=en
* Should the 'this' pointer be explicitly used as a rule? - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/dc65e966f7b73ba3?hl=en
* Why extracting string from stringstream(a) fails? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/515946bf9554ad00?hl=en
* is LISP the ultimate prgram language? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/90582c87e16a1cd9?hl=en
* Binary file IO: Converting imported sequences of chars to desired type - 4
messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/690c45c0197f60ef?hl=en
==============================================================================
TOPIC: c++0x pods and constructors
http://groups.google.com/group/comp.lang.c++/t/5aa5848ff079613f?hl=en
==============================================================================
== 1 of 7 ==
Date: Thurs, Oct 29 2009 12:31 am
From: Vladimir Jovic
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;
> };
>
std::string (if you are referring to that here) is not POD, therefore
that structure can not be an aggregate.
> 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; };
What is that default thing???
> 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.
I think you got that wrong. As far as I know (might be wrong), but
agregate is defined as an array or class that has none of the following
characretistics:
1) user declared constructors
2) private or protected non-static data members
3) base classes
4) virtual functions
--
Bolje je ziveti sto godina kao bogatun, nego jedan dan kao siromah!
== 2 of 7 ==
Date: Thurs, Oct 29 2009 1:06 am
From: "Johannes Schaub (litb)"
Vladimir Jovic wrote:
> 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;
>> };
>>
>
> std::string (if you are referring to that here) is not POD, therefore
> that structure can not be an aggregate.
>
That has nothing to do with it not being an aggregate. Non-PODs can be
aggregates, of course. Please gimme some standard legalese to prove me wrong
:)
>> 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; };
>
> What is that default thing???
>
This is a C++0x feature, and it means that the user declared constructor
will have a default implementation (which is trivial here).
>> 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.
>
>
> I think you got that wrong. As far as I know (might be wrong), but
> agregate is defined as an array or class that has none of the following
> characretistics:
> 1) user declared constructors
> 2) private or protected non-static data members
> 3) base classes
> 4) virtual functions
>
Yes, that's right (for c++03. For C++0x, "user declared" is changed to "user
provided", as you can declare a constructor yourself, but then default it).
So an aggregate can surely contain std::string :) However, where do i say
something contradictory?
== 3 of 7 ==
Date: Thurs, Oct 29 2009 3:32 am
From: James Kanze
On Oct 28, 7:02 pm, Victor Bazarov <v.Abaza...@comAcast.net> 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.
> > If not, why not?
> Because that's how it's defined. Ask in 'comp.std.c++' for
> the rationale behind that definition.
The rationale is probably simply that they needed the
distinction for some reason. In C++03, the distinction is
clear: aggregates can only be initialized using the aggregate
initialization syntax; other things can't be initialized using
the aggregate initialized syntax. In C++0x, there will be a
universal initialization syntax, which works for both aggregates
and non aggregates, but the semantics are still different: when
initializing an aggregate, you specify the initializer for each
member; when initializing a non-aggregate, you specify the
arguments for a constructor.
> > How about conversion operators?
> You can have conversion operators in an aggregate (according
> to the definition), if other conditions are met.
> > And what is the difference between a POD and an aggregate
> > anyway?
> And aggregate is a POD. A POD is not necessarily an
> aggregate.
Intuitively: an aggregate is determined superficially: an array
or a class with no user defined constructor, but elements of the
array or class aren't necessarily aggregates. A POD is defined
"deeply": for something to be a POD, all of its elements must be
POD's, recursively. There's more to it than that, of course.
The important difference is that whether something is an
aggregate or not determines how it is initialized (in C++03) or
what the initialization arguments mean (in C++0x). The
difference between a POD and a non-POD is that a POD has
constructors and destructors which are effectively no-ops, and
an assignment operator which is the equivalent of memcpy; this
plays a role in various contexts.
--
James Kanze
== 4 of 7 ==
Date: Thurs, Oct 29 2009 4:55 am
From: Vladimir Jovic
Johannes Schaub (litb) wrote:
> Vladimir Jovic wrote:
>>> string foo[10];
>>> struct bar {
>>> string baz;
>>> };
>>>
>> std::string (if you are referring to that here) is not POD, therefore
>> that structure can not be an aggregate.
>>
> That has nothing to do with it not being an aggregate. Non-PODs can be
> aggregates, of course. Please gimme some standard legalese to prove me wrong
> :)
>
<cut some stuff>
>> I think you got that wrong. As far as I know (might be wrong), but
>> agregate is defined as an array or class that has none of the following
>> characretistics:
>> 1) user declared constructors
>> 2) private or protected non-static data members
>> 3) base classes
>> 4) virtual functions
>>
> Yes, that's right (for c++03. For C++0x, "user declared" is changed to "user
> provided", as you can declare a constructor yourself, but then default it).
> So an aggregate can surely contain std::string :) However, where do i say
> something contradictory?
doh my mistake. An Aggregate can contain non-POD, but POD can't contain
non-POD
sorry
--
Bolje je ziveti sto godina kao bogatun, nego jedan dan kao siromah!
== 5 of 7 ==
Date: Thurs, Oct 29 2009 4:18 am
From: James Kanze
On Oct 29, 7:31 am, Vladimir Jovic <vladasp...@gmail.com> wrote:
> 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;
> > };
> std::string (if you are referring to that here) is not POD,
> therefore that structure can not be an aggregate.
std::string is not an aggregate, but bar is. Aggregation is
determined very superficially; if the class has no user defined
constructor or private data members, it is an aggregate.
> > 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; };
> What is that default thing???
Something new to C++0x. It just means that the compiler should
use the default implementation. In this case, I suppose that
Foo is a typo for F, and it is used to say that the default
constructor is the compiler generated default (and not absent,
as it would be otherwise in the presence of other constructors).
--
James Kanze
== 6 of 7 ==
Date: Thurs, Oct 29 2009 4:24 am
From: "Johannes Schaub (litb)"
James Kanze wrote:
> On Oct 29, 7:31 am, Vladimir Jovic <vladasp...@gmail.com> wrote:
>> Johannes Schaub (litb) wrote:
>> > 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; };
>
>> What is that default thing???
>
> Something new to C++0x. It just means that the compiler should
> use the default implementation. In this case, I suppose that
> Foo is a typo for F, and it is used to say that the default
> constructor is the compiler generated default (and not absent,
> as it would be otherwise in the presence of other constructors).
>
Oops, yes i typo'ed. Im sorry for any confusion caused :(
== 7 of 7 ==
Date: Thurs, Oct 29 2009 5:18 am
From: Victor Bazarov
James Kanze wrote:
> On Oct 28, 7:02 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
>> dragan wrote:
>>> And what is the difference between a POD and an aggregate
>>> anyway?
>
>> And aggregate is a POD. A POD is not necessarily an
>> aggregate.
>
> Intuitively: an aggregate is determined superficially: an array
> or a class with no user defined constructor, but elements of the
> array or class aren't necessarily aggregates. A POD is defined
> "deeply": for something to be a POD, all of its elements must be
> POD's, recursively. There's more to it than that, of course.
> The important difference is that whether something is an
> aggregate or not determines how it is initialized (in C++03) or
> what the initialization arguments mean (in C++0x). The
> difference between a POD and a non-POD is that a POD has
> constructors and destructors which are effectively no-ops, and
> an assignment operator which is the equivalent of memcpy; this
> plays a role in various contexts.
OK, so I am wrong saying that an aggregate is POD. An aggregate is POD
*iff* all of its members/elements are POD.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
==============================================================================
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 5 ==
Date: Thurs, Oct 29 2009 12:33 am
From: Dave Searles
peter koch wrote:
> On 28 Okt., 22:14, "yangs...@gmail.com" <yangs...@gmail.com> wrote:
>> Hi, everybody;
>>
>> 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:
>
> Nit: I assume you mean the standard C++ library. STL is a nonstandard
> library probably not used very much anymore.
STL isn't nonstandard according to the Word of God (Stroustrup's The C++
Programming Language).
== 2 of 5 ==
Date: Thurs, Oct 29 2009 3:18 am
From: James Kanze
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
== 3 of 5 ==
Date: Thurs, Oct 29 2009 3:22 am
From: James Kanze
On Oct 29, 7:33 am, Dave Searles <sear...@hoombah.nurt.bt.uk> wrote:
> peter koch wrote:
> > On 28 Okt., 22:14, "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:
> > Nit: I assume you mean the standard C++ library. STL is a
> > nonstandard library probably not used very much anymore.
> STL isn't nonstandard according to the Word of God
> (Stroustrup's The C++ Programming Language).
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.
In this case, the fact that the "exposed" name begins with two
underscores is a strong indication that it is strictly part of
the implementation, or perhaps an extension, but is not part of
the standard.
--
James Kanze
== 4 of 5 ==
Date: Thurs, Oct 29 2009 3:45 am
From: peter koch
On 29 Okt., 08:33, Dave Searles <sear...@hoombah.nurt.bt.uk> wrote:
> peter koch wrote:
> > On 28 Okt., 22:14, "yangs...@gmail.com" <yangs...@gmail.com> wrote:
> >> Hi, everybody;
>
> >> 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:
>
> > Nit: I assume you mean the standard C++ library. STL is a nonstandard
> > library probably not used very much anymore.
>
> STL isn't nonstandard according to the Word of God (Stroustrup's The C++
> Programming Language).
That book predates the C++ standard. A lot of the STL from those days
was incorporated into the standard library, but not all (rope, hashed
maps).
I know that most people call part of the C++ standard library STL, but
the term is not correct.
/Peter
== 5 of 5 ==
Date: Thurs, Oct 29 2009 5:47 am
From: Lew
James Kanze wrote:
> 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.
That is not correct for Java; in fact, it's exactly backwards.
In Java, "package-private", or default access means only accessible from
within the same package, as the word implies. 'protected' access is a
superset of that; members are available to subclasses even in different
packages, as well as to classes in the same package. A class cannot access
package-private members of one of its superclasses in a different package.
<http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html>
That chart does not make clear that package-private members can be inherited
by a subclass in the same package, but it's so. (It's not so for private
members, not even for extending inner classes.)
--
Lew
==============================================================================
TOPIC: CLI command line interface compiler for C++
http://groups.google.com/group/comp.lang.c++/t/cd86a54cab3d4055?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Oct 29 2009 1:07 am
From: Boris Kolpackov
Hi,
I am pleased to announce the first public release of CLI.
CLI is an open-source (MIT license), cross-platform command line
interface compiler for C++. It allows you to specify the options that
your program supports, their types, and default values. For example:
include <string>;
class options
{
bool --help;
std::string --name = "example";
unsigned int --level | -l = 5;
};
This specification can then be automatically translated to C++ classes
that implement parsing of the command line arguments and provide a
convenient and type-safe interface for accessing the extracted data.
For example:
#include <string>
class options
{
public:
options (int argc, char** argv);
options (int argc, char** argv, int& end);
bool help () const;
const std::string& name () const;
unsigned int level () const;
...
};
int main (int argc, char* argv[])
{
options o (argc, argv);
if (o.help ())
print_usage ();
if (o.level () > 4)
cerr << "name is " << o.name () << endl;
...
}
It is easy to start using CLI in your application since there are no
external dependencies. You can compile your command line interface to
C++ and simply add the generated files to your project's source code.
For a five minute introduction to CLI, see the "Hello World" example in
the CLI Getting Started Guide:
http://www.codesynthesis.com/projects/cli/doc/guide/#2
More information, documentation, and source code distributions are
available from the project's web page:
http://www.codesynthesis.com/projects/cli/
Enjoy,
Boris
--
Boris Kolpackov, Code Synthesis Tools http://codesynthesis.com/~boris/blog
Open-source XML data binding for C++: http://codesynthesis.com/products/xsd
XML data binding for embedded systems: http://codesynthesis.com/products/xsde
==============================================================================
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 1:46 am
From: Kai-Uwe Bux
Taras_96 wrote:
> Hi all,
>
> I was hoping to run my understanding of the concepts in the subject
> line past the news group. Given the class:
>
> class Foo
> {
> public:
> Foo(int);
> Foo();
> Foo (Foo const &);
> };
>
[...]
> Is the following correct?
> Foo foo; // default initialised
> Foo foo(); // value initialised
> Foo foo = Foo(); // temporary Foo is value initialised, then foo is
> copy-initialized with temporary. Note that compiler may optimise away
> copy, but it DOES require Foo to be copy constructible. ie: it is
> equiv to Foo foo(Foo());
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.
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).
Best
Kai-Uwe Bux
==============================================================================
TOPIC: Should the 'this' pointer be explicitly used as a rule?
http://groups.google.com/group/comp.lang.c++/t/dc65e966f7b73ba3?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Oct 29 2009 2:05 am
From: James Kanze
On Oct 28, 2:27 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Tue, 2009-10-27, Juha Nieminen wrote:
> > Paavo Helde wrote:
> >> Are you talking about data members or member functions?
> >> Non-member functions are typically qualified by the
> >> namespace, e.g. std::sort(), so I see no urgent need for
> >> distinguishing member functions.
> > Except for functions in a nameless namespace.
> >> For data members, I have grown a habit to use trailing
> >> underscore for all data member names, to distinguish them
> >> from local variables and parameters. Less typing than
> >> this-> and cannot be forgotten accidentally.
> > I don't know who first invented that convention, but it
> > seems quite popular, and I really can't understand why. IMO
> > an underscore truly makes code look more obfuscated than
> > other possible choices. Often you have to follow that
> > underscore with a dot or a ->, which makes it confusing.
> > Personally I have got the habit of preceding member variable
> > names with an 'm', constants with a 'k' and "globals" (well,
> > local to the current compilation unit) with a 'g'. I have
> > found it does significantly improve my own understanding of
> > the code months and years later.
> Maybe the difference is in how you spell the rest of your
> members.
Or the font you use. In many fonts, an underscore tends to get
lost. If there are two heavy characters next to it
(alphanumeric, or heavy punctuation like a semi-colon, but not
period, comma or space), you still realize that it's there, but
it's often almost invisible otherwise.
> I tend to use old Unix-style naming: all lowercase, words
> separated by _, e.g. "collation_bits". A _ suffix works fine
> for me (collation_bits_) -- I got used to it quickly.
The "old Unix-style" is nothing to separate words, and using a
maximum of abbreviations (especially dropping voyels).
Something like clltnbt:-).
> A 'm' prefix feels (subjectively) less neutral -- it interacts
> in my brain with the letters in the actual variable name.
> m_order makes me think of murder, etc.
What about my_order?
Of course, with really good naming, you don't need anything; the
name contains enough semantic information so that it's obvious
whether it is a member (from the semantics). In practice, I've
found that most people (including myself) don't name that well,
and that the my_ prefix (or our_ for static members) is helpful
in many cases, enough to be worth standardizing on. (But I
admit exceptions: public data members, for example, don't
normally get it.)
> Also, it would in practice mean that I would have to add
> another _ (m_collation_bits) or go CamelCase (mCollationBits)
> which looks too much like Java for my taste.
CamelCase precedes Java by a long shot. It's almost universal
in the telecoms field, at least in Europe, and was long before
anyone had ever heard of Java. I tend to use it by habit, even
in my private code, because of my experience in telecoms.
Esthetically, I think I really prefer the underscore; it does
make for slightly longer names, but not that excessively, and it
looks more like what I would normally write (outside of a
programming context).
> I'm not arguing strongly for trailing _; I just wanted to add
> a bit more perspective. The best would have been if C++ had
> forced us (like Python and Smalltalk do: self.collation_bits)
> but it is much too late for that now, and this->collation_bits
> cannot be enforced.
I disagree. The best would have been if there were some way of
enforcing good enough names so that the distinction wouldn't be
necessary. In practice, I find too that the real motivation for
the prefix/suffix is laziness: I'm too lazy to create
significantly different names for parameters and members in the
setters. (The real convention should probably be to "prefix"
both: my_state or my_current_state for the member, and
new_state for the parameter, or initial_state if it is a
parameter of a constructor. But as I said, I'm too lazy to do
this consistently.)
--
James Kanze
==============================================================================
TOPIC: Why extracting string from stringstream(a) fails?
http://groups.google.com/group/comp.lang.c++/t/515946bf9554ad00?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Oct 29 2009 2:12 am
From: James Kanze
On Oct 26, 3:36 pm, Maxim Yegorushkin <maxim.yegorush...@gmail.com>
wrote:
> Victor Bazarov wrote:
> > Maxim Yegorushkin wrote:
[...]
> >> Given the following declaration:
> >> void foo(int& ref);
> >> Could you explain how ref argument can possibly be
> >> copy-initialized please?
> > I am guessing the same way 'r2' is a "copy" of 'r1' here:
> > int a = 42;
> > int &r1 = a;
> > int &r2 = r1;
> > :-)
> Very well, this is what I wanted to hear. ;)
> In this case no copy constructor is required to
> copy-initialize a reference to non-const. By induction, the
> same should hold true for references to const (although they
> can be initialized with r-values, but only if necessary).
Except when the standard explicitly says it is necessary. When
binding a reference to an rvalue, the present standard gives the
compiler the liberty of either binding the rvalue object
directly, or binding a copy of the rvalue object (which is
necessary in certain cases to respect object lifetime); since it
doesn't want the legality of a program to depend on
implementation choices, it requires an accessible copy
constructor in all cases.
The next version of the standard is more explicit, requiring the
copy explicitly in some cases (i.e. when it would be necessary
for lifetime of object reasons), and forbidding it in others;
when it is forbidden, the compiler is not allowed to make the
copy, and no copy constructor is required.
> Hence, the above lvalue function template is well-formed.
> Comeau online compiles lvalue(std::istringstream(...)) just fine.
It shouldn't, according to C++03. The next version of the
standard will allow it, however. (I think, too, that a lot of
current compilers also allow it---g++ being the major
exception.)
--
James Kanze
==============================================================================
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 2:19 am
From: James Kanze
On Oct 28, 7:37 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> In article <macros-20091028120...@ram.dialup.fu-berlin.de>,
> r...@zedat.fu-berlin.de says...
> [ ... ]
> > Indeed, there is a paper claiming that Lisp macros were
> > an »inspiration« for C macros:
> If you honestly want to know what "inspired" C's macros, take
> a look at Macro-8 (an assembler for the PDP-8), or Control
> Data 160G GASS (General ASsembly System). E.g. See page 5 of:
> http://www.bitsavers.org/pdf/cdc/160/CDC_160G_Brochure_Feb64.pdf
> C was designed as a "portable assembly language", and by the
> early 1970's when it was designed, everybody "knew" that any
> sort of assembly language needed to have macros.
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.
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.
--
James Kanze
==============================================================================
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 4 ==
Date: Thurs, Oct 29 2009 3:00 am
From: James Kanze
On Oct 28, 2:55 pm, Rune Allnor <all...@tele.ntnu.no> wrote:
> On 28 Okt, 13:40, James Kanze <james.ka...@gmail.com> wrote:
> > The code was written very quickly, with no tricks or anything.
> Just out of curiosity - would it be possible to see your code?
> As far as I can tell, you haven't posted it (If you have, I
> have missed it).
I haven't posted it because it's on my machine at home (in
France), and I'm currently working in London, and don't have
immediate access to it. Redoing it here (from memory):
#include <fstream>
#include <iostream>
#include <string>
#include <vector>
#include <stddef.h>
#include <stdlib.h>
#include <time.h>
class FileOutput
{
protected:
std::string my_type;
std::ofstream my_file;
time_t my_start;
time_t my_end;
public:
FileOutput( std::string const& type, bool is_binary = true )
: my_type( type )
, my_file( ("test_" + type + ".dat").c_str(),
is_binary ? std::ios::out | std::ios::binary
: std::ios::out )
{
my_start = time( NULL );
}
~FileOutput()
{
my_end = time( NULL ) ;
my_file.close();
std::cout << my_type << ": "
<< (my_end - my_start) << " sec." << std::endl;
}
virtual void output( double d ) = 0;
};
class RawOutput : public FileOutput
{
public:
RawOutput() : FileOutput( "raw" ) {}
virtual void output( double d )
{
my_file.write( reinterpret_cast< char* >(&d), sizeof(d) );
}
};
class CookedOutput : public FileOutput
{
public:
CookedOutput() : FileOutput( "cooked" ) {}
virtual void output( double d )
{
unsigned long long const& tmp
= reinterpret_cast< unsigned long long const& >(d);
int shift = 64 ;
while ( shift > 0 ) {
shift -= 8 ;
my_file.put( (tmp >> shift) & 0xFF );
}
}
};
class TextOutput : public FileOutput
{
public:
TextOutput() : FileOutput( "text", false )
{
my_file.setf( std::ios::scientific,
std::ios::floatfield );
my_file.precision( 17 );
}
virtual void output( double d )
{
my_file << d << '\n';
}
};
template< typename File >
void
test( std::vector< double > const& values )
{
File dest;
for ( std::vector< double >::const_iterator iter = values.begin
();
iter != values.end();
++ iter ) {
dest.output( *iter );
}
}
int
main()
{
size_t const size = 10000000;
std::vector< double >
v;
while ( v.size() != size ) {
v.push_back( (double)( rand() ) / (double)( RAND_MAX ) );
}
test< TextOutput >( v );
test< CookedOutput >( v );
test< RawOutput >( v );
return 0;
}
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.)
--
James Kanze
== 2 of 4 ==
Date: Thurs, Oct 29 2009 3:03 am
From: James Kanze
On Oct 28, 8:38 pm, Brian <c...@mailvault.com> wrote:
> On Oct 28, 7:42 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Oct 26, 9:50 pm, Brian <c...@mailvault.com> wrote:
> > > On Oct 26, 12:06 pm, James Kanze <james.ka...@gmail.com> wrote:
> > > I haven't invested in text or XML marshalling because
> > > I think binary formats are going to prevail.
> > Which binary format? There are quite a few to choose from.
> I'm only aware of a few of them. I don't know if
> it matters much to me which one is selected. It's
> more that there's a standard.
> > > With the portability edge taken away from text, there
> > > won't be much reason to use text.
> > The main reason to use text is that it's an order of
> > magnitude easier to debug. And that's not likely to change.
> I was thinking that having a standard for binary would help
> with debugging.
It might. It would certainly encourage tools for reading it.
On the other hand: we already have a couple of standards for
binary, and I haven't seen that many tools. Part of the reason
might be because one of the most common standards, XDR, is
basically untyped, so the tools wouldn't really know how to read
it anyway. (There are tools which display certain specific uses
of XDR in human readable format, e.g. tcpdump.)
--
James Kanze
== 3 of 4 ==
Date: Thurs, Oct 29 2009 3:09 am
From: James Kanze
On Oct 28, 9:23 pm, Gerhard Fiedler <geli...@gmail.com> wrote:
> Rune Allnor wrote:
> > Here is a test I wrote in matlab a few years ago, to
> > demonstrate the problem (WinXP, 2.4GHz, no idea about disk):
> > [... Matlab code]
> > Output:
> > ------------------------------------
> > Wrote ASCII data in 24.0469 seconds
> > Read ASCII data in 42.2031 seconds
> > Wrote binary data in 0.10938 seconds
> > Read binary data in 0.32813 seconds
> > ------------------------------------
> > Binary writes are 24.0/0.1 = 240x faster than text write.
> > Binary reads are 42.2/0.32 = 130x faster than text read.
> In Matlab. This doesn't say much if anything about any other
> program. Possibly Matlab has a lousy (in terms of speed) text
> IO.
Obviously, not possibly. I get a factor of between 3 and 10,
depending on the compiler and the system. I get a signficant
difference simply running what I think is the same program (more
or less) on two different machines, using the same compiler and
having the same architecture---one probably has a much higher
speed IO bus than the other, and that makes the difference.
> 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.
--
James Kanze
== 4 of 4 ==
Date: Thurs, Oct 29 2009 7:02 am
From: Rune Allnor
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?
If so, the raw/cooked binary formats are a bit confusing.
According to this page,
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.
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.
Since you run the test with the same amopunts of data on the
same local disk with the same delay factors, this factor ~4
of longer time spent on handling XDR data must be explained by
something else than mere disk IO.
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
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.
Rune
==============================================================================
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