C++ Cpp C Plus Plus

Asking for more precision than is available = UB?

2008-12-04T21:26:00.003-08:00

On Oct 16, 2:43 am, Thomas Richter wrote:
> If you need more precision (you did check that you really need more
> precision, didn't you?) than what long double grants, you should check
> third-party libraries, for example the GNU bignum library:

Thanks for your comments Thomas. I'm aware of the various arbitrary-
precision libraries which are available, but this question isn't
really about needing extra precision for any practical purpose. I'm
just wondering if one of the 3 compilers is defective or if the code
generates undefined behavior (including, say, a segfault) according to
the standard. 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.

--
John

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

gcc compiler warning: "will be initialized after/when initialized here"

2008-12-04T21:26:00.001-08:00

Hi,

Throughout my code, I use references to existing classes in other
classes. I declared these reference vars as

class MyClass {
MyOther& myother;

MyClass (MyOther& other) : myother(other)
{
...
}

....
};

and initialize them in the constructor as shown above. Why is GCC
compiler giving me these warnings:

will be initialized after
when initialized here

(Intel compiler didn't complain, but I want to use GCC now for Linux.)

Thanks,
Andy

--
[ 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?

2008-12-04T20:26:00.003-08:00

John W. Peterson ha scritto:
> I'm pretty sure the following code causes undefined behavior (since I
> scanned through my draft of the standard and didn't find anything) but
> I just wanted to be sure. Essentially I am asking for more precision
> to be printed out than is available. Two compilers (Intel 10 and GCC
> 4.0.1) print about 20 correct digits and the rest are garbage, the PGI
> C++ compiler won't recognize (AFAICT) any precision setting beyond 16
> (or maybe it's all zeros and they aren't printed?) The test code and
> some results follow below, thanks in advance for your input.

I don't think it's a case of undefined behaviour, but it's simply
implementation-dependent behaviour.

The "garbage" after the first 20 correct digits is, technically
speaking, no garbage at all. It's truly the value of ld, that stores the
value of the literal as accurately as possible. As the value of the
literal lies between two representable floating point values, the
implementation simply chooses one of the two. The loss of accuracy
therefore happens in the first line (the assignment) rather than in the
third line (the output).

By the way, I believe PGI has a bug, because according to my
interpretation the output shall contain the exact specified number of
digits after the ".", the implementation is not allowed to output less
digits.

HTH,

Ganesh

> #include
> int main()
> {
> long double ld=3.1415926535897932384626433832795029L;
> std::cout.precision(32);
> std::cout << "ld=" << ld << std::endl;
> return 0;
> }
>
>
> Intel C++ prints:
> ld=3.1415926535897932385128089594062
>
> PGI prints:
> ld=3.1415926535897931
>
> GCC prints:
> ld=3.1415926535897932385128089594062
>

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Are throwing default constructors bad style, and if so, why?

2008-12-04T20:26:00.001-08:00

JoshuaMaurice@gmail.com wrote:
> On Oct 15, 3:48 pm, "Nevin :-] Liber" wrote:
>> The decision not to use exceptions pretty much has to be done from the
>> ground up, and it will result in a code base that is harder to get
>> correct, harder to maintain, and overall might end up slower.
>
> I agree completely. Exception use is so pervasive in normal C++ that
> it's quite difficult to isolate and squash exceptions.
>
> However, my company is trying: No exceptions anywhere. The performance
> critical sections are a like a flashback of bad C I would expect to
> see 15 years ago.
>
> I was going to attempt to persuade them that exceptions are good, but
> the argument is a little harder now in light of the my somewhat-
> trivial tests showing significant exception handling overhead when no
> exception is thrown.

Yes but that is not the consequence of using exceptions but of using a
bad compiler. What your company is doing is writing hard to maintain
poor quality C++ because you have determined that a specific compiler is
making the presence throwing an exception expensive even if it is
never thrown.

We now know that exceptions can be implemented on normal platforms with
close to zero overhead (less than the cost of using error returns).
There can be a case for writing exception free programs (note that, no
exceptions anywhere) for some limited resource (usually embedded) platforms.

Doing that involves avoiding a great deal of library resources and
should therefore not be undertaken lightly.

As a general engineering principle (not specific to software) one avoids
tools that make the product more expensive in development, construction
and maintenance.

What your evidence should do is to produce a very strong case for your
employers to switch to other compilers that do not cause them to have to
choose between seriously degraded performance and excessively high
development and maintenance costs.

>
> Funnily enough, I'm pretty sure we don't actually catch all exceptions
> from new and the standard library, meaning we get the worst of both
> worlds: bad code from exception overhead paranoia and slow code from
> the exception overhead we didn't deal with.
>
> I'm of the opinion that if it really is a problem, a profiler will
> pick it up, and we could take time to squash exceptions in that
> performance critical area.
>

As always one should focus on optimising code where it is proved that it
matters. One should always endeavour to contain such code so that when
the problem goes away it can be rewritten in a clean and easily
maintainable form.

--
[ 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)

2008-12-04T19:26:00.003-08:00

eric ha scritto:
>
> This means that the remove-erase idiom can't be used in this case:
> v.erase(remove(v.begin(), v.end(), 0));
> will give undefined behaviour.
>

Even in cases where it doesn't invoke UB (that is, if you have at least
one 0 in the vector) the code wouldn't behave correctly in the case you
have more that one 0. In that case, erase() will remove only one element
and you end up with n-1 garbage elements at the end of the vector (where
n is the number of 0s).

Morale: don't do it.

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));

in all other cases, use the "correct" remove idiom:

v.erase(remove(v.begin(), v.end(), 0), v.end());

HTH,

Ganesh

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

c++0x: static_assert & concepts

2008-12-04T19:26:00.001-08:00

SG ha scritto:
> This is a quote from Kanny Kalev's article "Static Assertions":
> ( http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=343&rll=1
> )
>
> "The concepts proposal doesnât eliminate the need for static
> assertions in C++. [...] static assertions are useful in C++ programs
> that do not use templates at all. [...]

So far, so good.

> [...] static assertions, when used
> together with the TR1 type_traits library, can diagnose type errors
> that intrinsic support for concepts cannot, such as ensuring that the
> template argument of basic_string shall be a POD type."

This I disagree. I don't see why concepts should be unable to ensure
POD-ness of the character type. Ok, we don't have a std::Pod concept
right now in the C++0x working paper, but we could have it, if it's
needed. Consider that even std::is_pod needs some compiler magic to be
implemented properly; a similar magic could be used to provide implicit
concept maps for an hypothetical std::Pod concept as it's already
required for std::StandardLayout and others.

> This sounds like we still need traits classes. It's unfortunate that
> the "boolean value" of a concept-check isn't easily acessible for meta
> programming and static_assert. There is a way to turn an old-style
> compile-time predicate (template<..> struct {..};) into a concept via
> std::True. But it doesn't work the other way around, does it?

Yes, traits classes still have their use in the concept world.

We don't have a way as compact as std::True to do it, but turning a
concept into a trait class is not that difficult:

concept MyConcept { /* ... */ }

template
struct is_my_concept : std::false_type {};

template
struct is_my_concept : std::true_type {};

HTH,

Ganesh

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

c++0x: static_assert & concepts

2008-12-04T18:26:00.003-08:00

On 16 oct, 00:38, SG wrote:
> There is a way to turn an old-style
> compile-time predicate (template<..> struct {..};) into a concept via
> std::True. But it doesn't work the other way around, does it?

template
struct is_foo
{
static const bool value = false;
};

template
struct is_foo
{
static const bool value = true;
};

I didn't know it was possible to turn a meta-function into a concept.
How is it done?

--
[ 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)

2008-12-04T18:26:00.001-08:00

JoshuaMaurice@gmail.com wrote:
> If you could post a complete code sample, I might be better able to
> help.
OK, here goes:

#include
#include
#include
using std::cout;
using std::vector;
using std::remove;

template
void print(const T& t)
{
for (typename T::const_iterator it = t.begin(); it != t.end(); ++it)
cout << *it << ' ';
cout << '\n';
}

int main(int, char**)
{
int k[] = { 1, 2, 3, 4, 5, 6, 7, 8 };
vector v(k, k + 8);

print(v);

int to_be_found = 0;
vector::iterator it = remove(v.begin(), v.end(), to_be_found);

if (it == v.end())
cout << to_be_found << " not found\n";

// Single iterator version of erase cannot be used if iterator
//points to end, becaue the Windows version erases the last element
//and the Linux version crashes
v.erase(it); // This exhibits undefined (?) behaviour
//v.erase(it, it); // This always works
print(v);
return 0;
}

/*
output using VC++

1 2 3 4 5 6 7 8
not found
1 2 3 4 5 6 7

output using g++

1 2 3 4 5 6 7 8
not found
Segmentation fault
*/

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Can COM class be used as Template Class

2008-12-04T17:26:00.003-08:00

On Oct 15, 6:37 pm, Piaoger Gong wrote:
> Hi,
>
> template
> class CMyHandler
> {
> public:
> void DoSomething(int num, CComPtr spiNode)
> {
> spiNode->Remove();
> }
>
> };
>
> int main()
> {
> CMyHandler handler;
> handler.DoSomething();
> return 1;
>
> }
>
> The above code will get a link error for ComClass::DoSomething is
> unresolved.

No, ComClass::DoSomething is only part of that function's signature.

> if I have ComClass::DoSomething called outside of template class. No
> link error again.
>
> Is there any method for this issue and I am thirsty for you solution.
>
> Thanks invance,
> Piaoger
>

A function has a signature.
Same goes for non-static member functions
(which additionally includes a this parameter).

void DoSomething( int n ) { } // 1

and

void DoSomething() { }

are two completely different functions.
So if you declare and implement 1 and then try to call DoSomething()
it will be unresolved, as expected. The only part of a function
declaration not considered to be part of its signature is its return
type (if any).

If you were to provide a default value for a given arguement:

void DoSomething( const int n = 5 ) { }

Then you could call DoSomething() since that is really DoSomething(5).
We have a signature match for the function call. DoSomething( const
int ).
There are additional rules in the case you choose to provide default
values to some, not all, parameters. Lookup those details in your fav C
++ book.

Not sure if thats what you are looking for.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Can COM class be used as Template Class

2008-12-04T17:26:00.001-08:00

Sorry. The subject should be "Can COM class be used as Template
argument".
If someone can provide some information about why and how to resolve
the link error when we want to call COM class method, It will be much
appreciated.

--
[ 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)

2008-12-04T14:26:00.003-08:00

eric wrote in
news:48f5f7bc$0$5038$e4fe514c@dreader26.news.xs4all.nl:

> Hi all,
>
> Suppose we have a vector of integers:
> vector v;
> filled with some values but not the integer 0 (zero).
>
> Next, we try to remove the zero from the vector:
> vector::iterator it = remove(v.begin(), v.end(), 0);
> Of course, the returned iterator equals v.end().
>
> Now comes the rub: when we erase the element using the iterator
> range version
> v.erase(it, v.end());
> all is fine.
>
> But when we use the single iterator version (for example,
> because I already know that there is only one zero in the
> vector):
> v.erase(it);
> Bad Things Happen: Windows/Visual C++ removes the last element
> of the vector and Linux/g++ segfaults.

You are contradicting yourself. First you say that the vector does
not contain any zeros, then you say that you "already know that
there is only one zero". Both can't be true at the same time.

>
> This means that the remove-erase idiom can't be used in this
> case:
> v.erase(remove(v.begin(), v.end(), 0));
> will give undefined behaviour.

The erase-remove idiom uses the iterator range version of erase:

v.erase( remove( v.begin(), v.end(), 0 ), v.end() );

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! ]

question regarding std::9.4.2/4 (static data members of const integral type)

2008-12-04T14:26:00.001-08:00

Hi,

when looking into certain headers of the Boost library, I found that
the case of
static const integral members of class templates is treated
differently from case to case.
For example (after expanding macros):

boost/type_traits/detail/ice_eq.hpp:

template
struct ice_eq
{
static const bool value = (b1 == b2);
};

template
struct ice_ne
{
static const bool value = (b1 != b2);
};

template bool const ice_eq::value;
template bool const ice_ne::value;

But on the other hand:

boost/type_traits/detail/ice_or.hpp:

template bool b5 = false, bool b6 = false, bool b7 =
false>
struct ice_or;

template bool b7>
struct ice_or
{
static const bool value = true;
};

template <>
struct ice_or
{
static const bool value = false;
};

// No namespace scope definitions of ice_or<...>::value

boost/type_traits/detail/cv_traits_impl.hpp:

template struct cv_traits_imp {};

template
struct cv_traits_imp
{
static const bool is_const = false;
static const bool is_volatile = false;
typedef T unqualified_type;
};

....

// No namespace scope definitions of cv_traits_imp<...>::is_const/
is_volatile

At least ice_or<...>::value is used (e.g. in the definition of
is_base_of).

Is the Boost code incorrect or do I read paragraph 9.4.2/4 in a wrong
way?
Is this paragraph applicable for class template instantiations? (I
don't remember
a paragraph, which states that an instantiation of a class template is
a class)?

Thanks for clarification,
Norbert

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Can COM class be used as Template Class

2008-12-04T13:27:00.003-08:00

Hi,

template
class CMyHandler
{
public:
void DoSomething(int num, CComPtr spiNode)
{
spiNode->Remove();
}
};

int main()
{
CMyHandler handler;
handler.DoSomething();
return 1;
}

The above code will get a link error for ComClass::DoSomething is
unresolved.
if I have ComClass::DoSomething called outside of template class. No
link error again.

Is there any method for this issue and I am thirsty for you solution.

Thanks invance,
Piaoger

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

stringstream misunderstanding

2008-12-04T13:27:00.001-08:00

Hi,

The reasoning behind the interface is that stringstream is not
implemented in terms of a string, but to format things passed to the
stream as a string.

The representation inside a stringstream (inside the string buffer
actually) is optimized for speed and memory usage (which is why it's
better to use stringstream instead of string for more complex string
operations).

The str() function doesn't return the internal representation of the
string, as in the internal representation there is no string. Instead,
it builds a string upon request and returns that. The string is a
copy, not the internal representation.

This is (should be) lazy evaluation, as the string is constructed only
if needed (and returned as a temporary).

The same holds true for the str(std::string const&) function: it
adjusts the internal buffer of the stringstream to copy the contents
of the string. In broad terms (and broad terms only) it copies the
string internally.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Why the decision to leave typeinfo::name() out of the standard?

2008-12-04T12:25:00.003-08:00

Sebastian Karlsson wrote:
> I understand that there's some grey areas, hence the need for some
> standard. I can see why it would be advantageous for memory
> constrained platforms to return an empty string here, and perhaps that
> could be fine. The problem for me is that I need a unique ID which I
> can serialize to be able to later on de serialize from a base pointer,
> it's the same problem which boost::serialize have pretty much. The
> gains from a standardized name() would mainly be for data sharing
> between the same application compiled for different platforms.

The usual solution is for the base type to have a method returning an
integral identifier of its derived type. The deserializer loads the
base object, gets the type ID, and static_casts to the derived type.

Look Ma, no strings!

if (base* const b = loadNextObject()) {

type_id const id = b->type_id();

switch (id) {
case d1_type_id:
work_with_d1(static_cast(b));
break;
case d2_type_id:
work_with_d2(static_cast(b));
break;
default:
throw exception("unknown type in input stream");
}
}

--
[ 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

2008-12-04T12:25:00.001-08:00

Brendan ha scritto:
> 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?
>
> template
> constexpr sum(T x) {
> return x;
> }
>
> template > constexpr sum(T x, Argsâ¦ args) {
> return x + sum(args);
> }
>
> because that would be enourmously useful, and much cleaner than the
> sum<1,2,3>::val syntax that template metaprogramming requires today.
> In general, I imagine a reduce implementation along these lines that
> could be used at both compile and runtime.

AFAIK, the current working paper doesn't allow that. The thing is still
under discussion and might change before the standard is approved,
although chances are few.

>
> Also, in the new variadic templates, are variadic template template
> arguments permissiable? i.e. can I do stuff like this?
>
> // typelist element.
> template > typename RetType,
> template
> RetType (Klass::*Ptr)(Args)>
> struct mem_fun_spec {
> typedef Klass klass;
> typedef RetType ret_type;
> typedef Ptr ptr;
> };

You will be able to have template template arguments with variable
number of arguments, but you can't write that code because:

template RetType (Klass::*Ptr)(Args)

is not a template *template* argument (if it were legal it would be a
template *non-type* argument).

> Finally... on a similar topic. Are we ever going to get some way of
> getting a typelist of a complete types members? Something like
> mem_funcs::list that is a typelist of the member functions of
> foo? That would sure be handy...

Unfortunately, no language support for introspection is being planned
for C++0x.

HTH,

Ganesh

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Hiding a reference to temporary

2008-12-04T10:25:00.003-08:00

Olivier ha scritto:
> Hi All,
>
> I was playing around with code (the code did consent) and stumbled
> over this :
>
> #include
>
> char const & hideConstRefToTemporary( char const &c )
> {
> return c;
> }
>
> char const & getChar1( )
> {
> return hideConstRefToTemporary('A');
> }
>
> char const & getChar2( )
> {
> return 'A';
> }
>
> int main( )
> {
> std::cout << getChar() << "\n";
> std::cout << getChar2() << "\n";
> return 0;
> }
>
> If you try and compile this code with gcc (I used version 4.3.2
> 20080827 alpha-testing 1), The compiler will complain of a reference
> to temporary for the function 'getChar2' but not for the function
> 'getChar1'.
>
> Is that a normal behaviour?

The question is ill-formed. Warnings are not a matter treated by the
standard, they are a quality-of-implementation issue. So a compiler can
emit or fail to emit any kind of warning and still that would be
"normal" behaviour.

> Is the code valid?

It depends on your definition of "valid". The code is well-formed, but
the behaviour is undefined, in both cases.

> Is there any word in the C++ standard that talk about this case?

No, because it shouldn't. Even the rule that says that returning a
reference to a temporary is bad is never said explicitly AFAIK, but is
implicit in 3.8.

> I know that temporaries can be bound to a const reference as function
> arguments, but how does that influence the way you use the variable
> representing that temporary ?

Each time a temporary is bound to a reference, the lifetime of the
temporary is extended to be not shorter than the lifetime of the reference.

int f();

void g()
{
const int& i = f(); // #1: i is bound to the temporary

/* ... */

// Lifetime of the temporary extended up to the point where i exits
// from scope. Normally it would have been destroyed at the
// end of line #1
}

However, this rule has no effect on temporaries bound to function
arguments of reference type, because the argument typically has shorter
lifetime:

int f();
void g(const int& i);

void h()
{
g(f()); // lifetime of i ends before lifetime of the temporary
}

HTH,

Ganesh

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Why the decision to leave typeinfo::name() out of the standard?

2008-12-04T10:25:00.001-08:00

On Oct 11, 11:59 pm, Sebastian Karlsson
wrote:
> The problem for me is that I need a unique ID which I
> can serialize to be able to later on de serialize from a base pointer,
> it's the same problem which boost::serialize have pretty much.

Then why not define it yourself?
You could make something like:
template struct serialization_traits {
static const char* const name;
};
and define
template<> serialization_traitsstd::char_traits > >::name = "string";
template<> serialization_traitsstd::char_traits > >::name = "unicode_string";
template<> serialization_traits::name = "int";
template<> serialization_traits::name =
"SomeNamespace::SomeClass";
...

This will allow you to define traits only when you need them (and
maybe for basic types) so there is no overhead, and allow you to
control the names given as much as you like (you might want to define
names following a different notation or skipping namespace alltogether
in some cases).

> The gains from a standardized name() would mainly be for data sharing
> between the same application compiled for different platforms.

What if the compilations for different platforms use different byte
alignments? How do you serialize between different architectures
(32bit vs. 64bit)?

I "feel" you're better of with more micromanaging of the serialization
process (but maybe I misunderstood something).

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Are throwing default constructors bad style, and if so, why?

2008-12-04T09:26:00.003-08:00

On Oct 15, 1:00 am, David Abrahams wrote:
> on Mon Oct 13 2008, JoshuaMaurice-AT-gmail.com wrote:
>
>
>
> > On Oct 12, 3:29 pm, David Abrahams wrote:
> >> on Sat Oct 04 2008, JoshuaMaurice-AT-gmail.com wrote:
>
> >> > And I really, really like exceptions and RAII. Damn. Disclaimer: This
> >> > doesn't kill all of RAII, but it kills some of it. It effectively
> >> > forces two phase construction for most classes if you want efficient
> >> > code on all platforms, and that makes me very sad.
>
> >> And how, exactly, is two-phase construction going to save you cycles?
>
> > To have single phase construction, constructors must acquires
> > resources. Acquiring resources can fail. User's must be able to know
> > if acquiring a resource fails. The only way I know of doing this is
> > with exceptions or 'zombie' objects. Exceptions carry significant
> > overhead on some implementations, so we're left with zombie objects,
> > and a function to query if it's a zombie.
>
> > Resource r;
> > if (r.isZombie())
> > return false;
>
> > Otherwise, we can do two phase construction, acquiring resources in
> > init(), and foregoing all exception use. It is very much like the
> > above approach; a zombie state is still required.
>
> > Resource r;
> > if (!r.init())
> > return false;
>
> > The bad compilers which handle exceptions poorly can be configured to
> > introduce no exception overhead in these two examples as nothing here
> > throws, avoiding the significant penalty of exception overhead.
>
> Maybe I'm missing something. If the user needs the ultimate effect of
> single-phase construction, he has to invoke both the throwing and
> nonthrowing phases in the 2-phase case. If both phases could be
> accomplished without throwing, there'd obviously be no advantage to
> 2-phase construction. Otherwise, phase 2 can throw, and the compiler is
> still going to have to handle the possibility of an exception from phase
> 2, isn't it?

With single phase construction with constructors, you have to use
exceptions to let the user know you failed to acquire a resource (or
have zombie objects).

The alternative I proposed for writing "fast" portable code is to
forgo all exception use and instead use error return codes. Thus all
the initialization work cannot be done in the constructor and/or you
have zombie objects. (If you're using a third party library which does
use exceptions, create a small wrapper over it to translate exceptions
to error returns to allow the rest of your program to be exception
handling free, or just immediately catch all exceptions when you call
the third party library, treating exceptions as over-glorified error
return codes like we were all taught not to do.)

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Are throwing default constructors bad style, and if so, why?

2008-12-04T09:26:00.001-08:00

on Mon Oct 13 2008, JoshuaMaurice-AT-gmail.com wrote:

> On Oct 12, 3:29 pm, David Abrahams wrote:
>> on Sat Oct 04 2008, JoshuaMaurice-AT-gmail.com wrote:
>>
>> > And I really, really like exceptions and RAII. Damn. Disclaimer: This
>> > doesn't kill all of RAII, but it kills some of it. It effectively
>> > forces two phase construction for most classes if you want efficient
>> > code on all platforms, and that makes me very sad.
>>
>> And how, exactly, is two-phase construction going to save you cycles?
>
> To have single phase construction, constructors must acquires
> resources. Acquiring resources can fail. User's must be able to know
> if acquiring a resource fails. The only way I know of doing this is
> with exceptions or 'zombie' objects. Exceptions carry significant
> overhead on some implementations, so we're left with zombie objects,
> and a function to query if it's a zombie.
>
> Resource r;
> if (r.isZombie())
> return false;
>
>
> Otherwise, we can do two phase construction, acquiring resources in
> init(), and foregoing all exception use. It is very much like the
> above approach; a zombie state is still required.
>
> Resource r;
> if (!r.init())
> return false;
>
>
> The bad compilers which handle exceptions poorly can be configured to
> introduce no exception overhead in these two examples as nothing here
> throws, avoiding the significant penalty of exception overhead.

Maybe I'm missing something. If the user needs the ultimate effect of
single-phase construction, he has to invoke both the throwing and
nonthrowing phases in the 2-phase case. If both phases could be
accomplished without throwing, there'd obviously be no advantage to
2-phase construction. Otherwise, phase 2 can throw, and the compiler is
still going to have to handle the possibility of an exception from phase
2, isn't it?

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Hiding a reference to temporary

2008-12-04T08:26:00.003-08:00

Hi All,

I was playing around with code (the code did consent) and stumbled
over this :

#include

char const & hideConstRefToTemporary( char const &c )
{
return c;
}

char const & getChar1( )
{
return hideConstRefToTemporary('A');
}

char const & getChar2( )
{
return 'A';
}

int main( )
{
std::cout << getChar() << "\n";
std::cout << getChar2() << "\n";
return 0;
}

If you try and compile this code with gcc (I used version 4.3.2
20080827 alpha-testing 1), The compiler will complain of a reference
to temporary for the function 'getChar2' but not for the function
'getChar1'.

Is that a normal behaviour?
Is the code valid?
Is there any word in the C++ standard that talk about this case?

I know that temporaries can be bound to a const reference as function
arguments, but how does that influence the way you use the variable
representing that temporary ?

Thanks for your insight,

Olivier.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Compiletime-Calculating Prime Numbers

2008-12-04T08:26:00.001-08:00

Francis Glassborow wrote:
> Well if you insist you could always use a better algorithm but that
> would require much more work at TMP. However I cannot imagine any
> place where it would be useful.

There are a couple of FFT algorithms which are designed for operand
lengths which are prime, like Rader's Algorithm. An optimized FFT
library could use compile time checks of number theoretic properties to
switch over to an more efficient algorithm for certain inputs.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Spurious blank generated in simple Win32 Console app

2008-12-04T07:27:00.003-08:00

RichardOnRails2 ha scritto:
> Hi,
>
> I'm a rusty C++ programmer trying to help a new-comer to write a
> permutations-generator. In my first dozen lines of so manage to write
> an unexpected blank character.
>
> The program and its output are posted at http://www.pastie.org/291679.
>
> The third line " PQR" should be simply "PQR" IMHO. I've made some
> dumb mistake. Learning where it is would be most appreciated.
>

Assuming you work on a platform where the size of pointers is four
bytes, the expression "sizeof(s)/sizeof(*s)" in line 6 always evaluate
at compile time to 4, regardless of the content of the string pointed by
s. In fact sizeof(s) is the size of *the pointer*, which is always four,
and sizeof(*s) is the size of a character, which is always one. As you
use "sizeof(s)/sizeof(*s)" as the size of the field "%*s" you are
actually requesting the blank of padding you see.

Notice the expression "sizeof(a)/sizeof(*a)" in line 13 is a completely
different case, that unfortunately is also wrong. In fact a is an array
(not a pointer as in the previous case) so the result is the number of
elements of the array, which unfortunately is also 4 and not 3, because
of the implicitly added terminating '\0'.

Remember: sizeof returns size of a type or object, NOT the length of a
string (be it a literal or not).

BTW, why did you write:

printf("%*s\n", sizeof(s)/sizeof(*s), s);

where you probably just meant:

printf("%s\n", s);

or, even better:

std::cout << s << '\n';

HTH,

Ganesh

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Compiletime-Calculating Prime Numbers

2008-12-04T07:27:00.001-08:00

By compiling the line

IsPrime<1000>::value;

Your system is trying to generate, compile and link many thousands
specializations of IsPrime. I suspect it runs out
of memory somewhere.

Notice also that:
1) The maximum possible value of an integer factor of j is sqrt(j).
You need therefore to test only for i <= sqrt(j).
2) Your code does not work if j<=0. You need at least to rise an
exception.
A better solution is to define j=0 to be prime (or not to be prime:
it is a
matter of taste) and j<0 to be prime if abs(j) is prime.

A standard solution to the prime number test problem is to implement
the algorithm in the old-fashioned standard way, not using templates
nor recursion.

#include
#include
#include

bool isPrime(const int n)
{
int j = std::abs(n); // n<0 is prime if abs(n) is
prime
bool primeSoFar = true;
int i = int(std::sqrt(j)+0.5); // the max possible factor of n
is sqrt(n)
while(primeSoFar && i>1) // 0 and 1 are primes by
definition
{
if(j%i == 0) primeSoFar=false;
--i;
}
return primeSoFar;
}

int main()
{
std::cout << isPrime(0) << std::endl; // prime by
definition
std::cout << isPrime(1) << std::endl; // prime by
definition
std::cout << isPrime(-1) << std::endl; // prime
std::cout << isPrime(31) << std::endl; // prime
std::cout << isPrime(-31) << std::endl; // prime
std::cout << isPrime(100) << std::endl; // not prime
std::cout << isPrime(-100) << std::endl; // not prime
std::cout << isPrime(1000) << std::endl; // not prime
std::cout << isPrime(10000) << std::endl; // not prime
std::cout << isPrime(100000) << std::endl; // not prime
std::cout << isPrime(1000000) << std::endl; // not prime
std::cout << isPrime(10000000) << std::endl; // not prime
std::cout << isPrime(INT_MAX) << std::endl; // in gcc on a 32-bit
x86 INT_MAX = pow(2,31)-1 = 2147483647 and is prime
system("pause");
}

This implementation turns the compile-time complexity of Your code
into run-time complexity.

By googling You will find other more powerfull and complex solutions
to the primeness-test problem.

Regards, Claudio Pacati

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Spurious blank generated in simple Win32 Console app

2008-12-04T06:26:00.003-08:00

Hi,

I'm a rusty C++ programmer trying to help a new-comer to write a
permutations-generator. In my first dozen lines of so manage to write
an unexpected blank character.

The program and its output are posted at http://www.pastie.org/291679.

The third line " PQR" should be simply "PQR" IMHO. I've made some
dumb mistake. Learning where it is would be most appreciated.

Thanks in Advance,
Richard

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]