Iteration over the structure fields

On 6 oct, 21:59, robn1...@gmail.com wrote:
> Is there any quick and neat way to perform some repeated operation
> over all the fields of a structure without
> repeating the same code for each individual field?

Yes.
See Boost.Fusion.

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

size of array

On Oct 3, 11:41 am, Mathieu Mazerolle
wrote:
> > Not portably, unless you keep the size in a separate variable.
>
> Most general-purpose allocators that implement C++'s new[] semantics
> need to store the size of the allocation, making your proposed
> solution wasteful in memory.

But do they need to store the *exact* requested size of the
allocation, or just the actual allocation size?

And does the actual allocation size have to be in a reasonably
accessible location from the raw pointer?

IIRC, C malloc/free isn't required to do either. So an implementation
of new/delete build on top of malloc/free won't have those properties
either. (Consider a specific implementation that always allocates
pointers aligned to eight bytes, and provides a Microsoft-like
extension function _msize that returns the actual allocated size in
bytes. There is no pragmatic reason why this implementation should
not round up all allocation requests to the least multiple of eight
bytes, so let it. That is,

char* tmp = new char[2]

is only *required* to allocated 2 bytes, but actually allocates eight
bytes. Then _msize(tmp) returns eight; there is no way to recover the
intended array size of two.)

> The obvious suggestions presented in this thread so far avoid, I
> think, the underlying question: why does C++ not expose the
> information that the implementation should already have? (the size of
> the allocation)

Speculating: because the fact typical efficient implementations [O(log
n) allocate/deallocate] do not have this information efficiently
accessible, was taken into account when defining the standards?
[Could someone with an inside track on the standards process step in
here?]

> Yes, there are allocators that do not have this information (buddy
> allocators, etc.), but based on my experience it would be a better
> overall trade-off to impose the responsibility of storing the
> allocation size in the implementation and not the client.

The reimplementation of malloc/free/new/delete I custom-wrote to
enable close to mathematical reliability in memory management does do
this as a freebie [it intentionally stores the exact allocation size
requested in bytes], but is *not* a better overall tradeoff compared
to typical implementations. O(n) insertion *before* error-checking
(which is also O(n)) is completely inappropriate for a general-purpose
implementation.

> .... For example, could not
> std::vector take advantage of such a facility to avoid duplicated
> storage of the vector's capacity?

Assuming the standard were altered to mandate this facility, yes :)
But I see several motives to not mandate this facility.


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

catch match

What should this code output ?

#include
#include

class my_exception : std::exception
{
public:
static void foo()
{
try
{
throw my_exception();
}
catch(const std::exception&)
{
std::cout << 1 << std::endl;
}
catch(const my_exception&)
{
std::cout << 2 << std::endl;
}
}
};

int main()
{
my_exception::foo();
return 0;
}

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

Ragged array

On 3 Okt., 18:44, Decebal wrote:
> I have an array like the following:
> #####
> int foo[LAST_ENUM + 1][ARRAY_LEN] = {
> {0, 0,
> 12, 3,
> .
> .
> .
> 15, 7,
> -1},
> .
> .
> .
> {9, 0,
> -1},};
>
> #####
>
> But the the lengt of the different arrays can be quite different.
> ARRAY_LEN must fit the biggest, which could be a waste of space. I
> think that I used in the pasted a 'ragged' array, which does not waste
> space. But I can not remember how I did that. How can I declare and
> initialise a ragged array?
>
> { See comp.lang.c FAQ 6.16 .
> -mod/sk }

{ clc++m banner removed; please don't quote it. -mod }

One example:
typedef std::vector > IntVector2d;


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

Compiler allowed to "simplify" floating-point expressions?

Alan McKenney wrote:
> Does the C++ standard allow a compiler to
> "simplify" floating-point expressions in the way
> we learned in Algebra class?


Check the assembler output. For example:

int main()
{
float x = 5.524;
if( ( x + 1.0 ) - 1.0 ) {
return 8;
}
return 0;
}


If compiled with 'g++ -S alg.cc', you'll see all the steps.

if compiled with 'g++ -O2 -S alg.cc', it gets optimized down to:

int main()
{
return 8;
}

- Chris


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

size of array

Mathieu Mazerolle wrote:

>> Perhaps we'd have some new syntax like:
>> char *p = new char [100];
>> const size_t n = std::allocation_size(p);
>
> This is what I suggested above: I like the idea! Why did this not
> figure into the original design of new[]/delete[]? No one seems to be
> able to answer this question!

As I am not a member of the standardisation committee, I can only guess
why this feature is not specified, but my guess would be that the
committee did not see enough added value in such a feature to add it.

Note that an implementation is still free to offer this feature if it
wants.


>> Given this std::vector seems a wiser choice to me. Or perhaps I
>> completely misunderstood what you meant. Could you please clarify?
>
> Suggestion:
> std::vector p;
> std::allocation_size(&p[0]) == p.capacity()
>
> Obviously, this isn't a constraint that should be imposed on
> std::vector, but illustrates how an implementation of std::vector
> could use such a facility to improve efficiency.

Who knows if there is not an implementation out there that uses such a
facility to avoid explicitly storing the capacity of its std::vector<>
implementation.
It is allowed. You just can't rely on it to be true for the next
compiler you use.

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

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

Compiler allowed to "simplify" floating-point expressions?

Alan McKenney wrote:

> Does the C++ standard allow a compiler to
> "simplify" floating-point expressions in the way
> we learned in Algebra class?

No. The simplification rules of algebra class do not apply here, because
computer floating point arithmetic is (usually) neither commutative nor
associative. Limited precision necessitates rounding and this changes
the result if operands are reordered. 1.9/15 in the standard copes with
that.

This rules is important for users who needs predictable results from
their computations, the same result by the last bit regardless of
compiler, machine or optimization level (given that FP implementation
follows the same rules). For the majority of applications where
floating point cycles are burned these days (=video games) exact
results are less interesting than performance, that's why most
compilers supply some command line option to circumvent this.
(-ffast-math et.al.)

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

size of array

On 6 Okt., 04:59, Mathieu Mazerolle
wrote:
> > This is against the "you don't pay for what you don't use" principle
> > of C++.
>
> > Just because you think it would be handy, and "a better overall
> > tradeoff", we shouldn't force this on everyone.
>
> As Mathias pointed out, in the case of new[], the implementation is
> always paying for this. What I suggested was that in many cases (e.g.
> std::vector's capacity) we are being forced to pay for it twice. It
> makes no sense for array new[]/delete[] to need to know things that
> anyone else can't know, especially if you can't present an argument
> that knowing it would have a non-zero cost (as I suggested, it should
> have zero cost unless explicitly used - perfectly in line with C++'s
> semantics).

You (and possibly Mathias) are mistaken: nothing requires the size of
the allocated memory to be available when requesting memory. When
using new[] (who uses this form today?), the requirement to store the
count of the allocated objects is needed only when the objects have a
nontrivial constructor, and this is often not the case.
For std::vector, operator new[] most probably is not used at all.
>
> To rephrase the OP's question into one of my own: why does the C++
> standard prevent the query of the size of a dynamically allocated
> block of memory?

That could be useful sometimes, but only in quite specific cases. One
useful usage could be used in conjunction with some realloc-in-place
function in C++. But this answer is not the one you are looking for.


/Peter

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

Conversions in template functions

Bharath wrote:

> While learning function templates I wrote below program to understand
> better. The compiler output is also given below.
> The doubt that I've here is that why is the compiler doing conversion
> of double(1.1980) to int when it can convert int to double (to "wider
> one") and could use template generated
> function(my_max(double,double)) rather than handwritten
> one(my_max(int x, int y)) ?

The reason is that, when determining which type to use for a template
parameter, the compiler does not consider any conversions.

In the type deduction for my_max, the first parameter says that T
should be double, while the second parameter says it should be int. As
you can't say in general which one should prevail, the compiler
declares that the deduction has failed, and discards the template as a
possible candidate for the function call.

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

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

compare two objects, if they have the same vtable

Erik Wikström wrote:
>
> No. The only case where dynamic_cast works without a vtable (on a non-
> polymorphic type) is when it is used for downcasting:
>
> Derived* d = new Derived();
> Base* b = dynamic_cast(d);
>
That looks like upcasting to me. Downcasting is from base to derived.

--
Note that robinton.demon.co.uk addresses are no longer valid.


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

Conversions in template functions

On 6 Okt., 04:44, Bharath wrote:
> While learning function templates I wrote below program to understand
> better. The compiler output is also given below.
> The doubt that I've here is that why is the compiler doing conversion
> of double(1.1980) to int when it can convert int to double (to "wider
> one") and could use template generated
> function(my_max(double,double)) rather than handwritten
> one(my_max(int x, int y)) ?
>
> #include
>
> template T my_max(T, T);
> int my_max(int, int);
>

Also I don't have been checking for the standard
I'm quite sure that the problem is that your
template handles two parameters of >>same<< type!

You are >>using<< two parameters with different types!
The "best suitable" (for the compiler) is your (int, int)
version.

In addition to this problem I would like to know how
to find out about the exact rules. Where to read? (URL?)

kindly
Thomas

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

Conversions in template functions

On 6 oct, 04:44, Bharath wrote:
> While learning function templates I wrote below program to understand
> better. The compiler output is also given below.
> The doubt that I've here is that why is the compiler doing conversion
> of double(1.1980) to int when it can convert int to double (to "wider
> one") and could use template generated
> function(my_max(double,double)) rather than handwritten
> one(my_max(int x, int y)) ?
>
> #include
>
> template T my_max(T, T);
> int my_max(int, int);
>
> main()
> {
> my_max(1.1980, 10);
>
> }
>
> template T my_max(T x, T y)
> {
> std::cout<<"my_max(T x, T y)\n";
>
> }
>
> int my_max(int x, int y)
> {
> std::cout<<"in my_max(int x, int y)\n";
> my_max(x,y);
>
> }

The compiler deduces separately the type of each argument. From the
call "my_max(1.1980, 10)", the type of each argument are different
whereas your template declaration of my_max actually specifies that
they shall be exactly the same ( except for some specific cases, e.g.
top-level cv-qualifications are ignored, etc. ). Because of this
mismatch, SFINAE occurs and there is only the non-template my_max left
in the overload set.

Alexandre Courpron.


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

Policy-based class design or inheritance?

On 4 oct, 16:32, waba wrote:

> Err, for sure, it *is* possible to do that. But it seems rather
> contrived to go through the hoops of type erasure to work around the
> fact that A and A are different
> types,

How so? You want to "erase" types, you use type erasure.
Seems more logical to me than using broken OOP that is both intrusive
and not suited for value semantics.

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

Iteration over the structure fields

Is there any quick and neat way to perform some repeated operation
over all the fields of a structure without
repeating the same code for each individual field? E.g., instead of
writing this

struct some_struct {float field1; int field2; double field3; /*many
other fields*/};
some_struct a_struct;

f (a_struct.field1);
f (a_struct.field2);
/*etc.; assuming f() is an overloaded function taking the appropriate
structure members*/

some kind of a loop would be faster to type, look nicer and be easier
to modify, if needed. Any advice?

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

The need of Unicode types in C++0x

On 4 oct, 16:19, Seungbeom Kim wrote:
> Then can someone tell me, what is wchar_t for?
> Can someone tell me any real examples where wchar_t is useful?

I'm pretty sure there is none.
It's mostly used on Windows because the API uses it for Unicode.

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

Is this a bug in comeau?

Oops - sorry about that - should have just copied and pasted - the
correct code was:

comeau online appears to compile this without ambiguity:

struct R { };
struct S : R { };

int f(R) { return 0; }

struct T {
operator S() { return S(); }
operator R() { return R(); }
};

T t;
int x = f(t); // This call should be ambiguous

This is a bug, right?



regards,
Faisal Vali
Radiation Oncology
Loyola

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

Is this a bug in comeau?

On Oct 5, 4:24 pm, Bart van Ingen Schenau
wrote:
> Faisal Vali wrote:


> If the function had been
> int f(R) { return 0; }
Yes - this is what I meant (see corrected code as followup to my
erroneous earlier post)

> then the call would still not have been ambiguous.
> In this case, both T::operator R() and T::operator S() could be used for
> the conversion, but T::operator S() is disregarded as it requires an
> additional conversion from derived class to base class that is not
> needed for T::operaor R(). Therefor, T::operator R() is preferred.

Yes - I too have come to this conclusion - but only because
I finally stumbled upon this sub-paragraph in the standard: 13.3.3/1

This basically says that in choosing between F1 and F2
F1 is better than F2 if
1) there is at least one ICS (implicit conv sequence) for some arg
for which F1 is better than F2 and is no worse for all other
args
2) else F1 is a non-template and F2 is a template
3) else F1 is more specialized than F2 (both are templates)
4) else we are in the context of a User defined conversion and the
*return* type of
F1 offers a better *standard* conversion sequence to the
destination than the
return type of F2.


Also see 13.3.3.1.2/2 & 13.3.1.4 & 8.5/14.



So in the original (corrected version) of the example, op R() gets
called because:
a) op R() and op S() are equally good based on the ICS (implicit conv
sequences) of
all their arguments (the only argument really being the implicit
object parameter,
i.e. T->T is no worse than T->T)
b) so we break the tie since R->R is a better standard conversion than
S->R and choose
op R() [note, the return type of the function is being used for
OR!]


So now consider:

struct R { };
struct S : R { };

int f(R) { return 0; }

struct T {

operator R() const;
operator S();

};

T t;
const T ct;
int ret = f(t); // #1
int ret2 = f(ct); // #2

For #1 - op S() gets called - here's why
a) op S() is better than op R()-const because T->T is better than T-
> const-T

For #2 - op R()-const should get called - here's why
a) op R()-const is better than op S() because const-T& -> T& is not
a valid ICS

And just for the sake of completeness (or getting closer to it ;)
consider:

struct T {
operator S();
template operator U();
};
template <> T::operator R();

f(t);

In the above op S() gets called, because when trying to break the tie,
before we get to
comparing the conversion-sequences from the return types, being a non-
template breaks the
tie in favor of the non-template.

regards,
Faisal Vali
Radiation Oncology
Loyola


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

size of array

Mathieu Mazerolle wrote:
> Bo Persson wrote:
>> This is against the "you don't pay for what you don't use" principle
>> of C++.
>>
>> Just because you think it would be handy, and "a better overall
>> tradeoff", we shouldn't force this on everyone.
>
> As Mathias pointed out, in the case of new[], the implementation is
> always paying for this. What I suggested was that in many cases (e.g.
> std::vector's capacity) we are being forced to pay for it twice.

We are not always paying for this. new[] only has to store the number of
elements if the object has to be destroyed (a non-trivial destructor) on
a delete[].

There's no reason for a 'new char[100]' to store the number of chars
somewhere, since the destructor is a no-op.
Same for std::vector. The class uses an allocator to allocate raw memory
and constructs the objects in it. The allocator has no mechanism to
retrieve the size of the memory chunk, so std::vector has to remember
the sizes (both capacity and already constructed objects).

On the other hand, the implementation maybe has to know the size of a
chunk of memory the application deallocates, but it doesn't necessary
has the exact size. Most allocators have a specific allocation granulary
and only reserve memory chunks which are multiples of, for example, 8
bytes, to guarantee alignment. Also, the reserved size might not be
stored somewhere, but must be calculated by going through a linked list
of memory chunks. A garbage collected implementation might not be able
to get the size at all.

> It
> makes no sense for array new[]/delete[] to need to know things that
> anyone else can't know, especially if you can't present an argument
> that knowing it would have a non-zero cost (as I suggested, it should
> have zero cost unless explicitly used - perfectly in line with C++'s
> semantics).

How? Would you store the size only when somewhere else in the program
someone does a std::allocated_size(ptr)? What if these program parts are
in two distinct translation units?

> [...] For example, would it be useful to have a flavor of sizeof that
> returns the number of elements of a new[]'d pointer (with non new[]'d
> pointers resulting undefined behavior)?

The easiest way is std::vector. Also, it lowers the risk for a
memory/resource leak and lets you resize() your array.

--
Thomas

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

size of array

Mathieu Mazerolle wrote:
>> This is against the "you don't pay for what you don't use" principle
>> of C++.
>>
>> Just because you think it would be handy, and "a better overall
>> tradeoff", we shouldn't force this on everyone.
>
> As Mathias pointed out, in the case of new[], the implementation is
> always paying for this. What I suggested was that in many cases (e.g.
> std::vector's capacity) we are being forced to pay for it twice. It
> makes no sense for array new[]/delete[] to need to know things that
> anyone else can't know, especially if you can't present an argument
> that knowing it would have a non-zero cost (as I suggested, it should
> have zero cost unless explicitly used - perfectly in line with C++'s
> semantics).
>
> To rephrase the OP's question into one of my own: why does the C++
> standard prevent the query of the size of a dynamically allocated
> block of memory?

Because the implementation is not required to know the size of the
block. Even if it knows the size of the allocated block, this may not be
the size the programmer asked for -- It's only required to return "at
least" the amount of memory required, right? So for the OP's question
this information would be useless, because from a general malloc/new
view the information of how much memory was allocated does not tell us
how much was requested.

> (...) For example, would it be useful to have a flavor of sizeof that
> returns the number of elements of a new[]'d pointer (with non new[]'d
> pointers resulting undefined behavior)?
>

Personally I think it would have made sense so allow for a sizeof-like
thing that returns the number of elements new[]'d because every
implementation is already required to be able to determine this information.

br,
Martin

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

Conversions in template functions

On Oct 6, 11:44 am, Bharath wrote:
> While learning function templates I wrote below program to understand
> better. The compiler output is also given below.
> The doubt that I've here is that why is the compiler doing conversion
> of double(1.1980) to int when it can convert int to double (to "wider
> one") and could use template generated
> function(my_max(double,double)) rather than handwritten
> one(my_max(int x, int y)) ?
>

Two points here:

1. For argument deduction, *no* automatic type conversion is allowed.
That is, here type T must match exactly. If you want the conversion,
you must do it by yourself.

my_max(1.1980, 10);

or,

my_max(1.1980, static_cast(10));

2. For overloading resolution, a non-template function will be given
preference over a template specialization if the two functions are
equally good candidates for an overload match.

Regards,

Jiang


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

Compiler allowed to "simplify" floating-point expressions?

On Oct 6, 6:24 am, Alan McKenney wrote:
> Does the C++ standard allow a compiler to
> "simplify" floating-point expressions in the way
> we learned in Algebra class?
>


Yes, according to the current standard, which does not *disallow*
this transform, it is possible the expression will be optimized
and code is "simplified" but gives wrong result. That is, for this
QoI issue, compilers are free to generate code they believe
reasonable for them[possibly not for the clients].


> For example, is it standard-conformant for a
> compiler to implement
>
> double x;
> ....
> if ( ( x + 1.0 ) - 1.0 )
>
> as
>
> double x;
> ....
> if ( x )
>
> I ask because I was at one time told that the
> C standard explicitly allowed such algebraic
> transformations, even though it changes the
> meaning of the code.


Not so long ago this was quite true, and still possible
true for some implementations.

Some production-quality compilers did change groupings
specified by parentheses. Compiler writers, who did their
excellent jobs in other respects, made basic mistakes in
floating point code generation. After all, not all of the
compiler writers are numerical analysts.


> I'm guessing that if this was at one time the
> case, it might have been corrected since then,
> as writers of numerical code have started moving
> from Fortran to C++. But I have not ever heard
> any discussion of it, and the one time I brought
> it up in another thread, I didn't get much of an
> answer.

I am not sure this have been *corrected* or not, to prove
this strong word we need hard data, which is not available
from my limited knowledges.

However, I am definitely sure that for numerical computation,
or floating point arithmetic, things are going better now.

For example, beginning with vc8.0, the compiler allows
programmers to select floating-point modes, such as
fp:precise, fp:fast and fp:strict. For fp:precise, the compiler
will never perform algebraic transformations unless the final
result is provably identical.

And for gcc, if we do not specify -ffast-math or
-funsafe-math-optimizations, it is quite possible that there
will be no harmful transformations for floating point arithmetic.

BTW, for serious, portable numerical code, test cases for
floating point arithmetic are very important in my mind.
Without such tests, making any assumptions (IEEE format,
precision, machine epsilon, etc.) is considered dangerous.

IMHO, maybe this post won't stop your worrying and actually
you are not alone. Floating point is one of the "dark corners"
of C++ language. Although I see the technical difficulties here,
I still hope someday there will be a chapter for floating
point in our holly standard.

Regards,

Jiang

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

Specialization of inner templates: should it be legal?

Dear Faisal Vali,

> > My question concerns the specialization of inner templates without the
> > specialization of outer templates, for example
>
> > template
> > struct A
> > {
> > template struct B;
> > template<> struct B {}; // error
> > template<> struct B {}; // error
>
> > };
>
> > Well we know that the standard emphatically says this is not allowed
> > in 14.7.3.18
>
> > I would like to understand the rationale behind this requirement.
>
> I have yet to see a good reason for this - appears to be just another
> inconsistency between explicit vs partial specialization syntax that
> no one has submitted as a defect to the standards committee (did i
> miss the DR?)


How easy is it to submit a defect report? If it is not too difficult I
would not mind spending some time on it.


> > For the curious, this restriction can be overcome as follows
>
> > struct true_ {};
>
> > template struct if_same {};
> > template struct if_same { typedef true_ type; };
>
> > template
> > struct A
> > {
> > template struct B;
> > template struct B::type>
> > { int x; };
> > template struct B::type>
> > { double x; };
>
> > };
>
> > This works on both GCC 4.3.0 and ICC 10.1.012. Although, I think this
> > should not be legal per 14.7.3.18.
>
> I do not see anything in 14.7.3.18 that forbids the above - What
> specific phrase/sentence do you feel does or should?


You are right. There is nothing in it that prevents it.


> Also, I do not think you need to resort to SFINAE to select the best
> specialization here - it might be simpler to just use ESABTL ;)
> (Explicitly Specialize All But The Last, which scales well with
> multiple parameters that need to be fully specialized):
>
> template struct Outer {
> template struct Inner;
>
> private: // sorry ;)
> template struct Inner; // do not try
> your tricks -
>
> template struct Inner {
> typedef int int_type;
> };
> template struct Inner {
> typedef double double_type;
> };
> template struct Inner,_> {
> typedef int outer_int_type;
> };
>
> };
>
> Outer::Inner::int_type x;
> Outer::Inner::double_type x2;
> Outer::Inner>::outer_int_type x3;


I like your solution, it is much easier to read. I think you missed a
public: before the partial specializations.


> > Can someone be so nice to shed some light on the rationale behind
> > 14.7.3.18?
>
> good luck - I hope they do ;)


I hope they do not. Otherwise it will be a pain in the ass to use the
workarounds. Not to mention the annoying superfluous template argument
floating all around the debug output.

cheers,
Krishna.

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

compare two objects, if they have the same vtable

> Derived* d = new Derived();
> Base* b = dynamic_cast(d);
Why would one use a cast for code like this in the first place?

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

compare two objects, if they have the same vtable

Erik Wikstr=C3=B6m schrieb:
> On 2008-10-04 19:59, Albert Zeyer wrote:
>> So, the following is not possible then?
>>
>> class Base { public: int data1; };
>> class Derived : public Base { public: int data2; };
>>
>> Base* obj = new Derived();
>> Derived* d = dynamic_cast(obj);
>
> No. The only case where dynamic_cast works without a vtable (on a non-
> polymorphic type) is when it is used for downcasting:
>
> Derived* d = new Derived();
> Base* b = dynamic_cast(d);
>

That is upcasting.

http://en.wikipedia.org/wiki/Downcasting

--
Thomas

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