soft and program: comp.lang.c++ - 25 new messages in 11 topics

comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en

comp.lang.c++@googlegroups.com

Today's topics:

==============================================================================
TOPIC: Logical Value Of A Pointer
http://groups.google.com/group/comp.lang.c++/t/e9c0b3e622d74ae6?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 1 2009 12:11 am
From: Bertrand

Lionel B wrote:
> On Fri, 30 Jan 2009 21:36:32 +0000, Bertrand wrote:
>
>> Lionel B wrote:
>>> On Fri, 30 Jan 2009 10:02:29 -0500, Victor Bazarov wrote:
>>>
>>> (Snip)
>>> <shrug> I don't program on MS Windows... but exactly. My understanding
>>> is that NULL (as inherited from C) is *specifically* to represent a
>>> null pointer constant. If Microsoft choose/chose to subvert that then
>>> boo sucks to them. I guess if I had to I'd deal with it I would,
>>> grudgingly.
>> I thought it has something to do with the fact that with C an invalid
>> pointer was not necessarily set to 0 on all platforms, hence the need
>> for a special value. Something that C++ decided not to carry on, and
>> used 0 for invalid pointers; thus legitimating the usage of implicit
>> conversion to bool.
>
> Sure, I'm not claiming it's "wrong" to write 'if (p)', simply that 'if (p
> == NULL)' - or, for that matter, 'if (p == 0)' - is clearer in its intent.
just about, imho. if you like clarity and you think if( p ) is not clear
enough, then you should prefer this: if( is_valid_ptr( p )), with
something like that defined somewhere:
template< typename T >
bool is_valid_ptr( T* p ) { return p != 0; }

Note that here a simple return p; would cause MSVC to issue the
``stupid'' performance warning mentioned elsewhere in this thread.

>
>> btw, if example of the STL serves, several classes provide an implicit
>> conversion to bool to express the meaning of /valid/. streams are an
>> example.
>> Ok, admittedly, the most relevant one to the present discussion
>> precisely lacks it (std::auto_ptr). However, I don't think your argument
>> holds for it either:
>
> Actually my argument re. STL was about container iterators.
No worries, I was looking for examples in a well accepted library, not
really replying to something specific you wrote.

>
> Sure the streams implicit conversion is useful and such a common idiom
> that it seems perfectly natural in that context. I guess I'm arguing
> against general usage where the context is not necessarily that clearcut.
>
>> if( p.get() == 0 )
>> does not /mean/ more than:
>> if( p.get() )
>
> I guess you meant 'if( !p.get() )' ... now which style was clearer? ;-)
Ah, ah, sure. It does not mean /more/, but it does mean something
/different/ then ;-)
I meant to write if( p.get() != 0 ) which was the follow up on the
initial if( a != 0 ) or if( a != NULL ). But it was already late for me...
Nevertheless, even with if( !p.get() ) I stick to my favourite style.

--
Bertrand

==============================================================================
TOPIC: Noob programmer
http://groups.google.com/group/comp.lang.c++/t/313f69fc6424514d?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 1 2009 12:27 am
From: Björn

BJ Halterman skrev:
> I am a hobbiest programmer. Wrather, I would be if I had any ideas to
> sharpen my skills on. Don't get me wrong, I have a tonn of ideas, but most
> of them are way beyond my current skills. I have looked for OOS groups
> that
> may be able to teach me something or throw me a small function to work on.
> Nothing. So now, I am turning to you.
>
> What starter projects can a noob work on? Stuff that isn't boreing.
> Eventualy, I would like to write my own game engine for a MMORPG.
>
> Anyways, thanks for your time, and any replies. :)
>
> BJ
>
How about some simple word prosessing, like some string handling.
Perhaps a math program, utilizing math functions that you find in
most programming languages.
Which program are you using?

Bjorn

==============================================================================
TOPIC: hi i am pooja
http://groups.google.com/group/comp.lang.c++/t/b534b720b40ba7b3?hl=en
==============================================================================

== 1 of 3 ==
Date: Sun, Feb 1 2009 12:37 am
From: fhjgfshg

hi i am pooja...its very intrusting..u c that blog
sarcafe.co.cc

== 2 of 3 ==
Date: Sun, Feb 1 2009 3:30 am
From: Rolf Magnus

fhjgfshg wrote:

> hi i am pooja...

No. According to your From: header entry, you're "fhjgfshg".

> its very intrusting..

That's right. I don't trust it.

== 3 of 3 ==
Date: Sun, Feb 1 2009 6:57 am
From: getgoing

Hiiiiiiiiiiiii

==============================================================================
TOPIC: Implementation of shared_ptr
http://groups.google.com/group/comp.lang.c++/t/f44425fab08bd122?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Feb 1 2009 12:45 am
From: Bertrand

Kai-Uwe Bux wrote:
> Kai-Uwe Bux wrote:
>
>> fungus wrote:
>>
>>> This is a question about the implementation of shared_ptr:
>>>
>>> Does shared_ptr allocate a little control block to hold the reference
>>> count?
> [snip]
>> An alternative (ignoring the custom deleter) is something like this:
>>
>> template < typename T >
>> class linked_ptr {
>> T * pointer;
>> mutable linked_ptr * next;
>> public:
>> ...
>> };
>>
>> Here the shared_ptr objects for a given pointee form a circular linked
>> singly list (maybe, a variant with a doubly linked list is easier).
> [snip]
>
> Thinking about the assignment operator now, a doubly linked list is
> definitely easier.
>
>
> Best
>
> Kai-Uwe Bux
Correct me if I'm wrong, but that would be harder to make work in
multi-threaded environment without resorting to ``heavy'' locking.
(Perhaps, it is only possible with the doubly-linked case where the
cyclical aspect is avoided.)
AFAIK, Boost implementation uses a lock anyway. But one of my colleagues
implemented a lock-free variant (it might have been for Solaris only
though). I haven't seen what he did (yet), but I have a feeling that it
was achievable because of the control block.

--
Bertrand

== 2 of 4 ==
Date: Sun, Feb 1 2009 12:52 am
From: Kai-Uwe Bux

Bertrand wrote:

> Kai-Uwe Bux wrote:
>> Kai-Uwe Bux wrote:
>>
>>> fungus wrote:
>>>
>>>> This is a question about the implementation of shared_ptr:
>>>>
>>>> Does shared_ptr allocate a little control block to hold the reference
>>>> count?
>> [snip]
>>> An alternative (ignoring the custom deleter) is something like this:
>>>
>>> template < typename T >
>>> class linked_ptr {
>>> T * pointer;
>>> mutable linked_ptr * next;
>>> public:
>>> ...
>>> };
>>>
>>> Here the shared_ptr objects for a given pointee form a circular linked
>>> singly list (maybe, a variant with a doubly linked list is easier).
>> [snip]
>>
>> Thinking about the assignment operator now, a doubly linked list is
>> definitely easier.
[snip]
> Correct me if I'm wrong, but that would be harder to make work in
> multi-threaded environment without resorting to ``heavy'' locking.
> (Perhaps, it is only possible with the doubly-linked case where the
> cyclical aspect is avoided.)
> AFAIK, Boost implementation uses a lock anyway.

Even with a lock, the control block variant is definitely more straight
forward in the multi-threaded case: you put the lock within the control
block and make sure that the block in only accessed by one thread at a
time.

With the linked structure, you would have to embed a lock within each
pointer and every change would presumably have to lock the pointer, its
successor, and its predecessor.

> But one of my colleagues
> implemented a lock-free variant (it might have been for Solaris only
> though). I haven't seen what he did (yet), but I have a feeling that it
> was achievable because of the control block.

No comment: I don't know lock-free algorithms.

Best

Kai-Uwe Bux

== 3 of 4 ==
Date: Sun, Feb 1 2009 6:17 am
From: James Kanze

On 31 jan, 23:07, Juha Nieminen <nos...@thanks.invalid> wrote:
> James Kanze wrote:
> > In general, if you're allocating objects dynamically, it's
> > because they have identity, and aren't copiable. (There are
> > doubtlessly exceptions, but they aren't that common.) So just
> > ban copy and assignment.

> I'm not so sure it's the duty of a base class to impose some
> design pattern on the derived classes, especially given that
> copying reference-counted objects is trivial to make safe
> (just put an empty copy constructor and assignment operator in
> the reference counter class).

So what is the duty of a base class, if it isn't to define a
contract that all derived classes have to obey? That's the only
reason we require base classes to begin with.

> I wouldn't say that cloning dynamically allocated objects is
> such a rare thing to do.

No, but the cloning only occurs in very limited, well defined
circumstances. And again, typically, it doesn't concern the few
classes where reference counting is relevant.

--
James Kanze

== 4 of 4 ==
Date: Sun, Feb 1 2009 6:59 am
From: Juha Nieminen

James Kanze wrote:
>> I'm not so sure it's the duty of a base class to impose some
>> design pattern on the derived classes, especially given that
>> copying reference-counted objects is trivial to make safe
>> (just put an empty copy constructor and assignment operator in
>> the reference counter class).
>
> So what is the duty of a base class, if it isn't to define a
> contract that all derived classes have to obey? That's the only
> reason we require base classes to begin with.

A non-copyable contract is not in any way mandatory for reference
counting. Requiring it makes no sense. It's a design issue which is not
directly related to reference counting, and thus it's not the duty of
the reference counter base class to impose it.

>> I wouldn't say that cloning dynamically allocated objects is
>> such a rare thing to do.
>
> No, but the cloning only occurs in very limited, well defined
> circumstances. And again, typically, it doesn't concern the few
> classes where reference counting is relevant.

It's not the concern of the reference counter base class whether the
objects must be cloneable or not.

==============================================================================
TOPIC: Pure virtual functions and multiple inheritance
http://groups.google.com/group/comp.lang.c++/t/3701206a31005bdb?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Feb 1 2009 1:11 am
From: Keith Thompson

Kaz Kylheku <kkylheku@gmail.com> writes:
> ["Followup-To:" header set to comp.lang.
[90 lines deleted]

Why? The question, and your response, were entirely specific to C++;
the only connection to C was that the code declared a class of that
name.

I don't understand why you posted your followup to comp.lang.c at all;
I can't imagine why you'd direct followups to comp.lang.c.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

== 2 of 2 ==
Date: Sun, Feb 1 2009 3:45 am
From: Pete Becker

On 2009-02-01 04:11:00 -0500, Keith Thompson <kst-u@mib.org> said:

> Kaz Kylheku <kkylheku@gmail.com> writes:
>> ["Followup-To:" header set to comp.lang.
> [90 lines deleted]
>
> Why? The question, and your response, were entirely specific to C++;
> the only connection to C was that the code declared a class of that
> name.
>
> I don't understand why you posted your followup to comp.lang.c at all;

The original poster presumably will look at comp.lang.c for an answer,
and seeing a redirection will send him to the right place.

> I can't imagine why you'd direct followups to comp.lang.c.

He didn't. They go to comp.lang.c++, where they belong.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

==============================================================================
TOPIC: Exception throwing and guarentees about execution order
http://groups.google.com/group/comp.lang.c++/t/096d29d5e1b9969d?hl=en
==============================================================================

== 1 of 6 ==
Date: Sun, Feb 1 2009 1:12 am
From: "Dick Brown"

As far as I understand 11.6 (6) of the Ada 95 Reference Manual, Ada
implementations may "lose" information, where exactly an exception has
been raised. I'm not sure whether I understand Ada in that regard, but
that's off-topic anyways (if someone wants to correct me there, I'd be
grateful nonetheless).

Something like:

try
{
int i = 0;
if (...) throw(i);
int i = 1;
if (...) throw(i);
int i = 2;
}
catch (...)
{
// i may be 0 or 1 or 2, no matter which throw(i) has brought us here
}

Now the real question: Does C++ have any similar provisions? I've found
nothing in the standard, am I right there?

Have a nice weekend
Dick

== 2 of 6 ==
Date: Sun, Feb 1 2009 1:28 am
From: Ian Collins

Dick Brown wrote:
> Hi
>
> As far as I understand 11.6 (6) of the Ada 95 Reference Manual, Ada
> implementations may "lose" information, where exactly an exception has
> been raised. I'm not sure whether I understand Ada in that regard, but
> that's off-topic anyways (if someone wants to correct me there, I'd be
> grateful nonetheless).
>
> Something like:
>
> try
> {
> int i = 0;
> if (...) throw(i);
> int i = 1;
> if (...) throw(i);
> int i = 2;
> }
> catch (...)
> {
> // i may be 0 or 1 or 2, no matter which throw(i) has brought us here
> }
>
> Now the real question: Does C++ have any similar provisions? I've found
> nothing in the standard, am I right there?

I'm not sure what you are asking, catch(...) will catch any exception,
so there isn't any information to "loose".

> Have a nice weekend

It's been and gone here!

--
Ian Collins

== 3 of 6 ==
Date: Sun, Feb 1 2009 1:39 am
From: "Dick Brown"

Ian Collins <ian-news@hotmail.com> writes:

>> try
>> {
>> int i = 0;
>> if (...) throw(i);
>> int i = 1;
>> if (...) throw(i);
>> int i = 2;
>> }
>> catch (...)
>> {
>> // i may be 0 or 1 or 2, no matter which throw(i) has brought us here
>> }
>>
>> Now the real question: Does C++ have any similar provisions? I've found
>> nothing in the standard, am I right there?
>
> I'm not sure what you are asking, catch(...) will catch any exception,
> so there isn't any information to "loose".

Oh, 'catch (...)' was stupid, make that 'catch (int i)'.

Suppose the first throw throws. Is it guaranteed that the caught 'int i'
is zero inside the exception handler?

Dick

== 4 of 6 ==
Date: Sun, Feb 1 2009 1:41 am
From: "Alf P. Steinbach"

* Dick Brown:
> Hi
>
> As far as I understand 11.6 (6) of the Ada 95 Reference Manual, Ada
> implementations may "lose" information, where exactly an exception has
> been raised. I'm not sure whether I understand Ada in that regard, but
> that's off-topic anyways (if someone wants to correct me there, I'd be
> grateful nonetheless).
>
> Something like:
>
> try
> {
> int i = 0;
> if (...) throw(i);
> int i = 1;
> if (...) throw(i);
> int i = 2;
> }
> catch (...)
> {
> // i may be 0 or 1 or 2, no matter which throw(i) has brought us here
> }
>
> Now the real question: Does C++ have any similar provisions?

No. C++ exceptions are deterministic and synchronous, except for the possibility
of implementation defined behavior for stack unwinding for an uncaught exception.

> I've found
> nothing in the standard, am I right there?

No, the standard completely defines the C++ exception handling.

Cheers & hth.,

- Alf

== 5 of 6 ==
Date: Sun, Feb 1 2009 3:28 am
From: Rolf Magnus

Dick Brown wrote:

> Ian Collins <ian-news@hotmail.com> writes:
>
>>> try
>>> {
>>> int i = 0;
>>> if (...) throw(i);
>>> int i = 1;
>>> if (...) throw(i);
>>> int i = 2;
>>> }
>>> catch (...)
>>> {
>>> // i may be 0 or 1 or 2, no matter which throw(i) has brought us here
>>> }
>>>
>>> Now the real question: Does C++ have any similar provisions? I've found
>>> nothing in the standard, am I right there?
>>
>> I'm not sure what you are asking, catch(...) will catch any exception,
>> so there isn't any information to "loose".
>
> Oh, 'catch (...)' was stupid, make that 'catch (int i)'.
>
> Suppose the first throw throws. Is it guaranteed that the caught 'int i'
> is zero inside the exception handler?

Depends on what you have in your (...) before it. If that changes i, then
no. Otherwise yes. What other value could it have?

== 6 of 6 ==
Date: Sun, Feb 1 2009 6:32 am
From: James Kanze

On 1 fév, 10:12, "Dick Brown" <inva...@invalid.invalid> wrote:

> As far as I understand 11.6 (6) of the Ada 95 Reference
> Manual, Ada implementations may "lose" information, where
> exactly an exception has been raised. I'm not sure whether I
> understand Ada in that regard, but that's off-topic anyways
> (if someone wants to correct me there, I'd be grateful
> nonetheless).

> Something like:

> try
> {
> int i = 0;
> if (...) throw(i);
> int i = 1;
> if (...) throw(i);
> int i = 2;
> }
> catch (...)
> {
> // i may be 0 or 1 or 2, no matter which throw(i) has brought us here
> }

> Now the real question: Does C++ have any similar provisions?
> I've found nothing in the standard, am I right there?

It's hard to say. The above won't compile in C++, so we can't
begin to speak about the behavior it might have. If you change
it to:

int i ;
try {
i = 0 ;
if ( ... ) throw i ;
i = 1 ;
if ( ... ) throw i ;
i = 2 ;
} catch ( ... ) {
}

Then in the catch block, i will have a value of 0 if the first
throw occurred, and a value of 1 if the second occurred. (I'm
not sure about Ada, but I imagine that a lot of languages don't
offer this guarantee---it has a decidedly negative impact on
optimization.)

--
James Kanze

==============================================================================
TOPIC: A question about iterators
http://groups.google.com/group/comp.lang.c++/t/8e6025132806498c?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 1 2009 3:32 am
From: James Kanze

On 31 jan, 23:48, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
> Juha Nieminen wrote:
> > Jeff Schwab wrote:
> >> iterator const next_to_last = advance(a_collection.end(), -1);

> > What's wrong with: iterator next_to_last = --a_collection.end(); ?

> The method end() does not return an lvalue, the code would not
> compile if the iterator happens to be a pointer.

Or if it's a classe type with a global operator-- (probably a
friend).

> Generally, I would avoid code that renders T* a non-model for
> a iterator to T. This way, I keep my code more generic. Of
> course, there is no real harm in cases where you know that the
> iterator is of class type.

That's not true, since the standard doesn't require operator--
to be a member. (If it's not a member, it rather obviously
takes a non-const reference, so you can't bind a temporary to
it.)

In general, I would argue that in a quality implementation,
overloaded operators which require lvalues should be
non-members, taking a non-const reference, so that the
overloaded operator also requires an lvalue. In practice,
however:

I think that this point has only been realized very, very
recently. All of the implementations of the standard
library I know date to well before I realized it, in any
case. So they don't follow this rule, and you can't fault
them for not following a guideline which didn't exist when
they were written.

The most frequent user defined operator which requires an
lvalue is simple assignment. And you can't make that one a
non-member. Given that you're already forced to compromize
in the most frequent case, I'm not sure that it's worth the
bother in the other cases. If it's no more effort to make
the operator a global function (and in the case of compound
assignment operators, it's often significantly less effort),
go ahead and do it, but it's not worth any significant extra
effort.

> Note: I am not sure what the correct answer would be from a
> standard point of view. As far as I can tell, all iterator
> types for standard containers are implementation defined.

Yep. All that is required is that they support both prefix and
postfix ++ (and -- if they are bidirectional) on an lvalue.

--
James Kanze

==============================================================================
TOPIC: extract string
http://groups.google.com/group/comp.lang.c++/t/4e1a3f9516af489f?hl=en
==============================================================================

== 1 of 3 ==
Date: Sun, Feb 1 2009 3:34 am
From: Erik Wikström

On 2009-02-01 03:17, Sam wrote:
> Andrew Ostry writes:
>
>> how can i extract string between <rfid> and </rfid> using simple
>> string functions? (DO NOT USE XML parser)?
>>
>> <cmd><rfid>ABCDEFG</rfid><user>Tom</user></cmd>
>>
>> the string i need is ABCDEFG.
>
> If you need it, then use an XML parser. If you need to hammer in a nail,
> using a screwdriver won't get you anywhere.

But if you have a good screwdriver (one of the electric ones with a nice
and heavy battery) and you only need to get one small nail in then it is
unnecessary to go and buy a hammer.

Or put another way, if you need to parse XML you should get an XML
parser, but if all you need is to get a substring from an XML string
then you can just use the functionality provided by std::string. Adding
an XML parser might double (or more) your codebase and add additional
dependencies that have to be maintained.

--
Erik Wikström

== 2 of 3 ==
Date: Sun, Feb 1 2009 5:57 am
From: "Chris M. Thomasson"

"Andrew Ostry" <tobycraftse@yahoo.com> wrote in message
news:v8u9o4d32n1anm8jot22leuec6a2rg0k3j@4ax.com...
> how can i extract string between <rfid> and </rfid> using simple
> string functions? (DO NOT USE XML parser)?
>
> <cmd><rfid>ABCDEFG</rfid><user>Tom</user></cmd>
>
> the string i need is ABCDEFG.

_________________________________________________________________________
#include <stdio.h>
#include <string.h>

static int
display_sub_string(
char* src,
char const* str1,
char const* str2
) {
char* head = strstr(src, str1);
if (head) {
char* tail;
head += strlen(str1);
tail = strstr(head, str2);
if (tail) {
char tmp = tail[0];
tail[0] = '\0';
puts(head);
tail[0] = tmp;
return 0;
}
}
return -1;
}

int main(void) {
char str[] = "<cmd><rfid>ABCDEFG</rfid><user>Tom</user></cmd>";
display_sub_string(str, "<rfid>", "</rfid>");
return 0;
}
_________________________________________________________________________

Oh, I am sorry. Did you have to do your homework in C++? In that case, just
use `std::string'; no problem.

== 3 of 3 ==
Date: Sun, Feb 1 2009 7:57 am
From: Lionel B

On Sat, 31 Jan 2009 20:17:06 -0600, Sam wrote:

> Andrew Ostry writes:
>
>> how can i extract string between <rfid> and </rfid> using simple string
>> functions? (DO NOT USE XML parser)?
>>
>> <cmd><rfid>ABCDEFG</rfid><user>Tom</user></cmd>
>>
>> the string i need is ABCDEFG.
>
> If you need it, then use an XML parser. If you need to hammer in a nail,
> using a screwdriver won't get you anywhere.

I think, rather, that the appropriate cliche here may be: you don't need
a sledgehammer to crack a nut.

--
Lionel B

==============================================================================
TOPIC: requirements for std::map keys
http://groups.google.com/group/comp.lang.c++/t/8210f94d493336e1?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Feb 1 2009 4:36 am
From: James Kanze

Christopher a écrit :
> What are the requirements for map keys?

Copiable and assignable. You also have to provide an ordering
function.

> If I remember correctly, they just need a operator < ?

They don't need operator<. They do need an ordering function.

> I need to be able to look up objects on the fly depending on this an
> array of these structures from another library:

> typedef struct D3D10_INPUT_ELEMENT_DESC
> {
> LPCSTR SemanticName;
> UINT SemanticIndex;
> DXGI_FORMAT Format;
> UINT InputSlot;
> UINT AlignedByteOffset;
> D3D10_INPUT_CLASSIFICATION InputSlotClass;
> UINT InstanceDataStepRate;
> } D3D10_INPUT_ELEMENT_DESC;

> Everything equates to an int or enum except the lowsy LPCSTR
> which is a long pointer to a c style string, yuck.

> I think I could wrap it and provide comparison operators if
> need be. I am not sure how to compare the LPCSTR though. If I
> create a std::string from it, is there a built string
> comparison operators or do I have to write one?

The obvious solution is to define your own C++ type, which has a
constructor from the above type, with string, unsigned int,
etc., and use that as a key.

The other solution is more complex. Depending on what the
LPCSTR (a char const*?) points to, or more precisely, the
lifetime of the C style string, this class may not support copy
and assignment, in which case, you simply cannot use it.
Otherwise, the function std::strcmp (in <cstring>), or its C
equivalent, can be used for the comparison.

--
James Kanze

== 2 of 2 ==
Date: Sun, Feb 1 2009 5:13 am
From: Juha Nieminen

Sam wrote:
> Christopher writes:
>
>> What are the requirements for map keys?
>> If I remember correctly, they just need a operator < ?
>
> Aside from a copy constructor, yes.

No, operator< is not required if you give a proper comparator type to
the map. Maps can be used even with existing classes which don't have an
operator<, as long as you can write a comparator for them.

==============================================================================
TOPIC: abstract base class containing class
http://groups.google.com/group/comp.lang.c++/t/5bfe26b47a4e6f79?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 1 2009 5:12 am
From: scg_

Alf P. Steinbach wrote:
> * scg_:
>> What follows is a question by an absolute beginner – you have been
>> warned:
>
> It's unclear what you're trying to achieve.
>
> It does seem as if you're strongly focused on some particular imagined
> solution instead of the desired result.

> This looks like a DIY version of std::vector.
>
> Use std::vector.

Yes, this is true. I am after a solution that in essence resembles the
STL and the examples given in Bruce's book. In short, I firstly want to
be able to instantiate objects that make accessible an iterator by means
of, e.g.

typename B<T>::iterator iter;
iter = x.begin();

(and similarly for class C<T>, D<T>, ...) and, secondly, I want to
program algorithms for these objects in terms of an abstract base class
A instead of B, C, .... I do not want to utilize templates to achieve
this, since the B objects are special insofar as they do require the
availability of certain member functions. Is this more revealing?
Concerning STL vectors or valarrays or ublas (my context is numerics),
you wouldbe right too, if I were about to implement production code.
However, I am only trying to get acquainted with the language. At the
current state, my implementation generalizes (arbitrary types and copy
on write semantics) Todd Veldhuizen's "Expression Templates"
contribution in the 1994 C++ Report. It took me a while to comprehend
his approach, however I feel having substantially advanced in my command
of c++ in this way. If I were able to also enforce the class layout
described above, I would take another step towards understanding c++. On
the other hand, if the design is flawed from the beginning this would
also add to my c++ comprehension. std::vector are not what I am
currently after (and on the source level they are still too intimating).
Instead, DIY is the theme.

Thank you

==============================================================================
TOPIC: templated function help
http://groups.google.com/group/comp.lang.c++/t/5b281279cd4b281c?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 1 2009 5:42 am
From: Francesco Montorsi

Alf P. Steinbach ha scritto:
>> if (func(*i) == 0) \
> ...
> Assuming 'isalpha' etc. are the C library functions: this code has
> generally Undefined Behavior, that is, it's Wrong(TM).
>
> The code has well-defined result only when compiled with an option to
> make 'char' an unsigned type, and/or is operating under a restriction to
> ASCII.
Sorry - I forgot to say that *i indeed evaluates to unsigned char as the
iterator operator* has been overloaded...

Francesco

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en

To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

soft and program

Sunday, February 1, 2009

comp.lang.c++ - 25 new messages in 11 topics - digest

No comments:

Blog Archive

About Me