On 20 oct, 00:41, itaj sherman
> On Oct 18, 3:48 pm, Mathias Gaunard
>
> > Yes, and that's the only way to ensure your object is always in a
> > valid state when you access it.
>
> Can you prove this? I think it is not.
> In the case of my template class or when using Boost.optional, the way
> to ensure it is with the assert/exception inside the member function
> that gives access to the object.
If you have to check it at runtime, then that's because you couldn't
ensure it by design...
> > Why not (assuming C++0x lambdas)
> > X x = [](){ Y y; X x(y); return x; }();
> > x.use();
>
> > or
> > X x([](){ Y y; return y; }());
>
> for 2 reasons:
> 1) Same problem as with Boost.Optional, you require an assignment
> operator for X
No, you don't.
It requires, however, that X is copyable (C++03) or movable (C++0x).
> And there is an extra temporary object created, which I don't know the
> compiler can optimize.
There is one, yes, which is always optimized in this case by any
decent compiler.
It's called NRVO. So assuming that optimization that will take place,
it has zero overhead.
> 2) I have to compile and execute this code on VC6.0
That's quite off-topic but, really. What a joke. Use a C++ compiler.
It is likely even boost won't run on it. They're planning to drop
support for 7.0 soon, even.
Funnily enough, that compiler won't apply NRVO but only RVO.
>, and cannot
> upgrade for at least 6 more months. Not my decision but I have to live
> with it.
I used C++0x for demonstration purposes. You are free to call actual
functions, functors, or generate them with anything you like (mem_fun/
bind1st, bind, boost.lambda, fc++, boost.phoenix...)
> Please, what is poor? What is unportable?
Usage of the magic "16" number which is "supposedly" the biggest
alignment requirement of any type on any platform?
Usage of a constant arbitrary big memory size, even when the type is
small?
Note that your technique doesn't even guarantee that alignment, if I
read it correctly.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Sometimes I want to separate the declaration and construction of a local variable
Sometimes I want to separate the declaration and construction of a local variable
On Oct 19, 11:42 pm, itaj sherman
> A few replies suggested that I use: X x(Y());
>
> I'll give a more general example than example1 to show why I can't.
> Basically because the Y instance might be needed for other things as
> well. [...]
void example1_1b() {
struct Local {
X x1, x2;
Local (const Y& y) : x1 (y), x2 (y) {/*...other things...*/}
} local (Y ());
local.x1.use ();
local.x2.use ();
//...more code that uses local.x1 and local.x2...
}
Regards,
Vidar Hasfjord
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Questions about C++0x standard
Martin Eisenberg ha scritto:
> Alberto Ganesh Barbati wrote:
>
>> A case with a recursive call like this:
>>
>> int factorial(int n)
>> {
>> return n < 2 ? 1 : n * factorial(n - 1);
>> }
>>
>> can't be made constexpr according to the WP and I can't find a
>> way to rewrite it as you suggested to make it work.
>
> I'm going purely on what little I've picked here about these things
> recently, but wouldn't the following do it?
>
> template
> constexpr int doFact(int n, Args... args)
> { return n < 2 ? 1 : n * doFact(n - 1, 0, args); }
I guess you mean
{ return n < 2 ? 1 : n * doFact(n - 1, 0, args...); }
>
> constexpr int fact(int n) { return doFact(n); }
>
Very intriguing! Unfortunately, I believe it won't work. The reason is
in 5.19/5:
"An expression is a potential constant expression if it is a constant
expression when all occurrences of function parameters are replaced by
arbitrary constant expressions of the appropriate type."
This means that in order to determine that
n < 2 ? 1 : n * doFact(n - 1, 0, args...)
is a potentially constant expression you eventually need to be able to
determine the constexpr-ness of doFact(...) with an arbitrary number of
parameters. This is practically impossible because the process would
exceed memory constraints (or other implementation-defined limits, such
as the maximum number of parameters per function) on any machine.
> ...or perhaps
>
> constexpr int fact2(int n) { return doFact(n, 0); }
>
You don't need the second parameter, a template argument pack can always
be empty.
Ganesh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
vector<>.erase(where) vs vector<>.erase(from, to)
Alberto Ganesh Barbati ha scritto:
> eric ha scritto:
>> Alberto Ganesh Barbati wrote:
>
> The one-argument erase() is efficient only if know that information in
> advance by some any other mean.
Let me rephrase that: if you don't know in advance the information that
you have *exactly one* value to erase, then any use of the one-argument
erase needs to be part of a loop which might be executed zero or more
times. The resulting code is not going to be more efficient (and is most
probably less efficient) than the application of the erase(remove()) idiom.
Ganesh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Questions about C++0x standard
Brendan
| I have a couple of questions about the forthcoming c++0x standard.
|
| Why are constexpr's not allowed to be recursive (according to the
| wikipedia article)? We are still allowed to do things like this
| correct?
[...]
The original constexpr proposal explicitly disallowed recursion
(either explicit or implicit) out of caution -- not that there were
any deep insurmontable difficulty. However, various iterations of
word smithing had the implicit effects of removing those restrictions
and, as far as I know from the last committee meeting, constexpr
functions are now allowed to be recursive. So, there should be no
need to write convoluted code to try to simulate recursion.
--
Dr. Gabriel Dos Reis (gdr@cs.tamu.edu), Assistant Professor
http://www.cs.tamu.edu/people/faculty/gdr
Texas A&M University -- Department of Computer Science
http://www.open-axiom.org/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Sometimes I want to separate the declaration and construction of a local variable
On 18 oct, 15:29, itaj sherman
> To my understanding using Boost.optional it would look like:
> void example1()
> {
> optional< X > x; //keeps place to construct an object of type X later
> {
> Y y;
> x = X(y); /*local variable x is contructed inside this inner scope
> because the constructor needs a resource Y.*/
> /*y should release its resource now.*/
> }
>
> //now I can use the object
> x.get().use();
> //...more code that uses x.get()
>
> }
>
> In the documentation there are a few examples for uses of
> Boost.optional, but none of the resembles this. Anyone ever used it in
> this case?
>
> It seems to me that it has these drawbacks:
> 1) Is there a way to avoid the construction of the temporary object X
> and then calling the copy constructor (optional::operator= calls it)?
Yes, using in-place factories, which are provided just for that
purpose.
> 2) This does require X to have a copy constructor, which is realy a
> non-neccessary requirement for this use.
No, it doesn't if you use in-place factories.
> 3?) Does Boost.optional hold the object directly inside it or does it
> allocate another buffer on the free store?
It's stored on the stack.
> Another thing: in any way, IMO optional should not be used directly
> for this, rather it should be wrapped by another template class more
> specific to this use.
I don't see what you could remove.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
operator++(int);
On Oct 8, 5:38 am, Matthias Berndt
> Hi,
>
> I'll start with a quote from D&E, page 246. It's about how to
> distinguish ++i from i++ when overloading operator++ for decltype(i).
>
> "Several alternatives that did not involve new keywords were suggested.
> For example:
> class Ptr_to_X {
> // ...
> X ++operator(); //prefix ++
> X& operator++(); //postfix ++
> };
> or
> class Ptr_to_X {
> // ...
> X& operator++(); //postfix because it
> //returns a reference
> X operator++(); //prefix because it
> //doesn't return a reference
> };
> I considered the former too cute and the latter too subtle. Finally, I
> settled on:
> class Ptr_to_X {
> // ...
> X operator++(); //prefix: no argument
> X& operator++(int); //postfix: because of
> //the argument
>
> };"
>
> My problem is that I really don't understand what he means by "too
> cute". I always thought cuteness were a good thing. And besides, I think
> that introducing a bogus argument is a horrible, horrible wart :( (one
> reason being that I can never remember which is which). IMO, the
> ++operator syntax would have been a lot more elegant. Does anybody have
> an idea about what might be wrong with it?
{ clc++m banner removed; please don't quote it! -mod }
My way to remember is: The one you want to define is the one with the
reasonable syntax.
The one you probabely/usualy don't want is the one with the bogus hard
to remember syntax.
Whether intended to be so or not, I think it's good.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Visibility and dependent base class
On Oct 5, 9:56 pm, Kaba
> Consider the following short example:
>
> template
> class Base
> {
> public:
> enum {VALUE = 1};
> typedef int Value;
>
> void g() {}
>
> };
>
> template
> class Derived: public Base
> {
> public:
> void f()
> {
> // These do not compile...
> //Value value = VALUE;
> //g();
> }
>
> };
>
> int main()
> {
> Derived
> derived.f();
> // ... but these do.
> derived.g();
> Derived
> return 0;
>
> }
>
> (by compiled I mean it compiles under VC++2008_1 and the newest Comeau
> compiler)
>
> What is happening here? My first explanation was that because the base
> class is dependent on template parameters, everything on it is hidden by
> default to the derived class (as a safeguard because you never know in
> general what kind of stuff the base class contains). However, it seems
> that outside the Derived class the base class is again visible through
> Derived. How do you reason about this?
{ clc++m banner removed; please don't quote it! -mod }
In my classes (and template classes), I usualy want to inherit
typedefs and members from base classes templates or not. So to
simulate an "always inherit" rule I do the following in all template
classes.
If you think about it as inheritance (as I do), it is important IMO to
qualify with the current type and not with the specific base. Moreover
to shorthand the recurring reference to the current type, I self-
typedef it as this_type.
template< typename T1, typename T2 >
class MyTemplateClass: public Base1< T1 >, public Base2< T2 >
{
//I put the following line at the beginning of a template class
private: typedef MyTemplateClass< T1, T2 > this_type;
//now I use "this->FunctionName" and "typename
this_type::TypedefName" when accessing inherited identifiers.
void f()
{
typename this_type::Value value = this_type::VALUE;
this->g();
}
};
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
vector<>.erase(where) vs vector<>.erase(from, to)
In article <48f84c7c$0$3424$e4fe514c@dreader20.news.xs4all.nl>,
eric
> > v.erase(find(v.begin(), v.end(), 0));
> But that's exactly the problem: I can use this construct only if I
> already know that there is exactly one 0. The moral seems to be: find()
> first, check the resulting iterator and only do erase() when the
> iterator is not at the end of the container.
You need to define what you want to do. It is either:
(1) Remove all 0s.
(2) Remove the first 0, if it exists.
These are not the same thing, and require two different implementations.
(1) is easily accomplished with
v.erase(remove(v.begin(), v.end(), 0), v.end());
> Pity I have to do the test myself, but maybe it is the vestige of an
> age-old C mindset, e.g. the str*() functions crashing when they get a
> null pointer instead of more civilized behaviour.
It is just your expectations. You want a function that removes at most
one element, and the one provided removes exactly one element. If this
stuff is error prone in your code you can always write a wrapper:
iterator erase_at_most_once(container c, iterator i)
{
return i == c.end() ? i : c.erase(i);
}
--
Nevin ":-)" Liber
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Sometimes I want to separate the declaration and construction of a local variable
On Oct 18, 3:48 pm, Mathias Gaunard
> On 17 oct, 05:31, itaj sherman
>
> > I have this problem with c++ syntax. The problem is basically that the
> > declaration (and scope) of a local variable is bound to its
> > construction (in time, flow and scope).
>
> Yes, and that's the only way to ensure your object is always in a
> valid state when you access it.
Can you prove this? I think it is not.
In the case of my template class or when using Boost.optional, the way
to ensure it is with the assert/exception inside the member function
that gives access to the object.
If it were a language feature like in my pseudo code example, the
compiler could verify it.
>
> > Sometimes (examples below) I
> > want to declare a local variable for use in a certain execution scope,
> > but I want to invoke its contructor within a more inner scope.
>
> Then it means you want a scope within an expression.
> That is what closures are. Functions can do it too if you don't need
> to access higher scopes.
>
> > So, it
> > looks like I need to separate the construction from the declaration.
>
> No, you really don't want that.
>
> > I thought of a way to do it nicely with a template class that I named
> > ecStrictPlace (it uses placement new). Instead of defining a variable
> > of type X, I define a variable of type ecStrictPlace
> > the place in memory where an object of class X can be constructed
> > later using one of X's constructors, and then the object can be used.
> > When the execution exits the scope, the local ecStrictPlace
> > destructor also destroys the internal X object (if it has actually
> > been contstructed). So this should also be exception safe.
>
> That's the same as boost::optional
> As you can see, however, at any time your object might be initialized
> or not.
>
>
It has some things in common with Boost.optional, but it is not
exactly like it, not even almost exactly like it. See my first reply
about it - there are differences I cannot live with.
>
>
>
> > example 1:
> > So, I wished my code would look like (pseudo syntax):
> > void example1()
> > {
> > declare X x; //local variable x is declared in this scope, but not
> > constructed yet
> > {
> > Y y;
> > construct X x(y); /*local variable x is contructed inside this inner
> > scope because the constructor needs a resource Y.*/
> > /*y should release its resource now.*/
> > }
>
> > //now I can use the object in x
> > x.use();
> > //...more code that uses x...
>
> > }
>
> Why not (assuming C++0x lambdas)
> X x = [](){ Y y; X x(y); return x; }();
> x.use();
>
> or
> X x([](){ Y y; return y; }());
for 2 reasons:
1) Same problem as with Boost.Optional, you require an assignment
operator for X, which is not neccessary requirement for this purpose.
And there is an extra temporary object created, which I don't know the
compiler can optimize. Although assuming C++0x, the temporary object
can probabely be optimized with && move semantics.
2) I have to compile and execute this code on VC6.0, and cannot
upgrade for at least 6 more months. Not my decision but I have to live
with it.
> or
> X x(Y());
>
It has been suggested by others, I should have given a more general
example1.1 see my next reply.
> or
> X x = let(_a = Y()) [ _a ](); (boost.phoenix)
>
> or really, whatever. Just return what you need from another scope (if
> you really need to create a new scope, that is).
>
>
>
>
>
> > The following does the same thing with no overhead (not even my extra
> > bool member data), but the code cannot be written so straight forward.
>
> > void example1()
> > {
> > class X_construction
> > {
> > private:
> > Y _y;
> > X _x;
>
> > public:
> > X_construction()
> > :
> > _y(),
> > _x(_y)
> > {}
>
> > X& get()
> > {
> > return _x;
> > }
>
> > };
>
> > X_construction x;
> > x.get().use();
> > //...more code that uses x.get()
>
> > }
>
> I don't get it.
> If you can write that, you can write X x(Y());
>
I think not. again see example1.1 in my next post.
> > example 2:
> > I need to construct an object of type X with X::X( Y& ) or with
> > X::X( Z& ) and then use it. The choice of the constructor depends on
> > some parameter.
>
> It's the exact same thing as your other "problem", where you need the
> exact same solution.
> Generate whatever temporaries you need in the construction expression,
> possibly using functions or closures.
>
> > Following is my code for this template class ecStrictPlace within a
> > test program that uses it.
>
> Your stack allocation technique is really poor and unportable.
> There are type traits to get a POD with a given size and alignment
> requirement.
Please, what is poor? What is unportable?
I would have used Boost if it had what I need. Boost.optional is not
close enough for me. I tried to do my best here.
As for the alignment, I know have to see to it, but there are many
threads about the alignment with placement new, my questions here are
about other aspect of this issue.
{ clc++m banner removed; please don't quote it. -mod }
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Asking for more precision than is available = UB?
Alan McKenney wrote:
> On Oct 16, 8:40 pm, "John W. Peterson"
> wrote: ...
>> I think it must be undefined behavior to ask for more
>> precision than is available, I just wanted to check clc++m to
>> find out for sure.
> I would expect that as you ask for
> more and more digits, you should get
> an ever more precise decimal
> representation of the exact value
> of the floating-point number.
You are right. The reason is that the very title of this thread
confuses precision and accuracy -- presentation vs. content,
basically. Finite precision clearly implies finite accuracy, but
precision itself is not something that can "run out". Google the pair
of terms for more info than anyone's going to put in a post.
Martin
--
Dare to think!
--Paracelsus
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Sometimes I want to separate the declaration and construction of a local variable
On Oct 18, 3:48 pm, Martin Bonner
> As well as echoing our moderator's comment that Boost.Optional is what
> you want, I have a couple of points about your motivating examples:
>
> On Oct 17, 4:31 am, itaj sherman
>
> > example 1:
> > I have some class X with a constructor X::X( Y& ). It expects the
> > parameter Y to be alive while X::X( Y& ) executes but no neccessarily
> > longer than that.
>
> If you can rewrite class X to have a constructor X::X(const Y&), you
> can write it the code just as:
> X x(Y()); // Y temporary object that will destroyed at the ";"
>
It was suggested by Mathias too, I should have given a more general
example, please see example1.1 in my next post
>
>
> > example 2:
> > I need to construct an object of type X with X::X( Y& ) or with
> > X::X( Z& ) and then use it. The choice of the constructor depends on
> > some parameter.
>
> Again, if you can change to take const Y& or const Z& (and assuming X
> is copy constructible), then you can write the code as:
>
> X x = howToConstruct ? X(Y()) : X(Z());
>
Same problem as with boost.optional: requires assignment operator/copy
constructor, and an overhead of extra temporary object.
> (But that can get /rapidly/ ugly)
{ clc++m banner removed; please don't quote it. -mod }
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Sometimes I want to separate the declaration and construction of a local variable
On Oct 17, 5:31 am, itaj sherman
> using my template class ecStrictPlace it looks like:
> void example1()
> {
> ecStrictPlace< X > x; //keeps place (on the stack!) to construct an
> object of type X later
> {
> Y y;
> x.construct(y); /*local variable x is contructed inside this inner
> scope because the constructor needs a resource Y.*/
> /*y should release its resource now.*/
> }
>
> //now I can use the object
> x.get().use();
> //...more code that uses x.get()
>
> }
>
A few replies suggested that I use: X x(Y());
I'll give a more general example than example1 to show why I can't.
Basically because the Y instance might be needed for other things as
well.
So here is example1.1, there are two X objects:
void example1_1()
{
ecStrictPlace< X > x1;
ecStrictPlace< X > x2;
{
Y y;
x1.construct(y);
x2.construct(y);
}
//now I can use the object
x1.get().use();
x2.get().use();
//...more code that uses x1.get() and x2.get()
}
so
X x1(Y());
X x2(Y());
will lock and realease the resource acquired by Y twice.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
vector<>.erase(where) vs vector<>.erase(from, to)
eric ha scritto:
> Alberto Ganesh Barbati wrote:
>> If you know in advance that there is *exactly* one 0, it's more
>> efficient to use:
>>
>> v.erase(find(v.begin(), v.end(), 0));
> But that's exactly the problem: I can use this construct only if I
> already know that there is exactly one 0. The moral seems to be: find()
> first, check the resulting iterator and only do erase() when the
> iterator is not at the end of the container.
> Pity I have to do the test myself, but maybe it is the vestige of an
> age-old C mindset, e.g. the str*() functions crashing when they get a
> null pointer instead of more civilized behaviour.
>
You are still making a lot of confusion. Just checking if std::find
returns an iterator different from v.end() does *not* ensure that you
have *exactly* one 0 (you may have more!), which is the *only* case
where the one-argument erase works correctly.
The one-argument erase() is efficient only if know that information in
advance by some any other mean. In all other cases, you should use the
two-argument version with remove().
Ganesh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Questions about C++0x standard
Alberto Ganesh Barbati wrote:
> A case with a recursive call like this:
>
> int factorial(int n)
> {
> return n < 2 ? 1 : n * factorial(n - 1);
> }
>
> can't be made constexpr according to the WP and I can't find a
> way to rewrite it as you suggested to make it work.
I'm going purely on what little I've picked here about these things
recently, but wouldn't the following do it?
template
constexpr int doFact(int n, Args... args)
{ return n < 2 ? 1 : n * doFact(n - 1, 0, args); }
constexpr int fact(int n) { return doFact(n); }
...or perhaps
constexpr int fact2(int n) { return doFact(n, 0); }
Martin
--
No wonder that illegitimate children are commonly
the greatest minds; they are the result of an hour
full of wit, marital ones often spring from boredom.
--Theodor Gottlieb von Hippel
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Sometimes I want to separate the declaration and construction of a local variable
In article
itaj sherman
> It seems to me that it has these drawbacks:
> 1) Is there a way to avoid the construction of the temporary object X
> and then calling the copy constructor (optional::operator= calls it)?
Look at the in-place factory at
> 3?) Does Boost.optional hold the object directly inside it or does it
> allocate another buffer on the free store?
Directly inside.
> Another thing: in any way, IMO optional should not be used directly
> for this, rather it should be wrapped by another template class more
> specific to this use. This class should have only the required
> interface for this use (unlike the very wide interface of optional).
I'm looking at the interface at
Which parts of this interface do you feel are unnecessary?
--
Nevin ":-)" Liber
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
vector<>.erase(where) vs vector<>.erase(from, to)
eric
news:48f84c7c$0$3424$e4fe514c@dreader20.news.xs4all.nl:
> Alberto Ganesh Barbati wrote:
>> If you know in advance that there is *exactly* one 0, it's more
>> efficient to use:
>>
>> v.erase(find(v.begin(), v.end(), 0));
> But that's exactly the problem: I can use this construct only if
> I already know that there is exactly one 0. The moral seems to
> be: find() first, check the resulting iterator and only do
> erase() when the iterator is not at the end of the container.
> Pity I have to do the test myself, but maybe it is the vestige
> of an age-old C mindset, e.g. the str*() functions crashing when
> they get a null pointer instead of more civilized behaviour.
>
No. The moral is to use the erase-remove idiom properly, and then you
do not need to use find at all.
Is there some reason I missed why you cannot use the two-iterator
overload of erase?
MV
--
I do not want replies; please follow-up to the group.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
influenceing onto comp.lang.c++.moderated
{Moderator's Note: yes, this is supposed to be spam. However, this article
was never handled by any of the comp.lang.c++.moderated moderators but
the approval was forged: there is nothing we can do if people malicously
abuse the news. -mod/dk}
On 17 oct, 19:30, Martin.S...@msn.com wrote:
> Virginia wrote on 17 Oct 2008 17:30:01 GMT:
>
> > Who can head another boring plea?
>
> http://leave.dostii.net
Is that supposed to be spam?
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
