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

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

comp.lang.c++@googlegroups.com

Today's topics:

* dealing with lower level programmers - 6 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/f708a2c0cfa8ce2d?hl=en
* Need to use "volatile" for accessing variables between threads? - 7 messages,
3 authors
http://groups.google.com/group/comp.lang.c++/t/4e68d5b929c344d4?hl=en
* A silly belief shattered (happily) - 6 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/34c9bf7361966608?hl=en
* How can I use unqualified names? (Possibly hard or impossible?) - 1 messages,
1 author
http://groups.google.com/group/comp.lang.c++/t/e2f24a95fe72b591?hl=en
* How to write previous element in STL list - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/2d136691c93121bf?hl=en
* Difference between Char* ptr and char arrCh [] - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/3971db675cb4d039?hl=en
* ╰❉╮╰❉╮ Crazy Sell In Summer T-shirts==D&G,Lacoste,LV,GUCCI,Adidas,Ecko,ED
Hardy,POLO,,,etc.Paypal Payment Free Shipping - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/a071506a66f4618a?hl=en
* is this standard C++ MyClass::+ - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/a10cb21b32f40222?hl=en

==============================================================================
TOPIC: dealing with lower level programmers
http://groups.google.com/group/comp.lang.c++/t/f708a2c0cfa8ce2d?hl=en
==============================================================================

== 1 of 6 ==
Date: Mon, Jul 27 2009 11:39 pm
From: Keith H Duggar

On Jul 28, 1:29 am, Andrew Tomazos <and...@tomazos.com> wrote:
> On Jul 28, 1:37 am, Keith H Duggar <dug...@alum.mit.edu> wrote:
> > On Jul 27, 11:34 am, Andrew Tomazos <and...@tomazos.com> wrote:
> > > On Jul 27, 4:03 pm, James Kanze <james.ka...@gmail.com> wrote:
>
> > > > > I have personally seen a 400k line codebase that was written
> > > > > largely by one person that was (and maybe its latest versions
> > > > > still is) used by nearly a million people with minimal
> > > > > marketing.
>
> > > > And? A lot of people are using a lot of junk.
>
> > > The software in question won numerous high profile awards in the face
> > > of competition, and people described themselves as "huge fans" of it.
> > > It was noted not only for its nice user interface, but for its amazing
> > > robustness. It was most certainly good software. Its existence
> > > disproves your statement.
>
> > Why aren't you naming this "software in question"? Are you
> > hiding something?
>
> Yes - but nothing that effects the validity of the point.

On the contrary, it affects our ability to independently evaluate
and verify your claims. Without that we can't decide the validity
of your point (since it was just a collection of anecdotal claims
as opposed to say a deduction from shared beliefs).

KHD

== 2 of 6 ==
Date: Tues, Jul 28 2009 12:39 am
From: Andrew Tomazos

On Jul 28, 8:39 am, Keith H Duggar <dug...@alum.mit.edu> wrote:
> > > > > > I have personally seen a 400k line codebase that was written
> > > > > > largely by one person that was (and maybe its latest versions
> > > > > > still is) used by nearly a million people with minimal
> > > > > > marketing.
>
> > > > > And? A lot of people are using a lot of junk.
>
> > > > The software in question won numerous high profile awards in the face
> > > > of competition, and people described themselves as "huge fans" of it.
> > > > It was noted not only for its nice user interface, but for its amazing
> > > > robustness. It was most certainly good software. Its existence
> > > > disproves your statement.
>
> > > Why aren't you naming this "software in question"? Are you
> > > hiding something?
>
> > Yes - but nothing that effects the validity of the point.
>
> On the contrary, it affects our ability to independently evaluate
> and verify your claims. Without that we can't decide the validity
> of your point (since it was just a collection of anecdotal claims
> as opposed to say a deduction from shared beliefs).

You are correct. It is indeed merely eye witness testimony. It is up
to you how much you are swayed by it. From my point of view, I know
it's valid. From yours, I guess you can't be certain - although I
can't think what I would gain by making stuff like this up.
-Andrew.

== 3 of 6 ==
Date: Tues, Jul 28 2009 2:44 am
From: Christof Donat

>> > I don't think a professional programmer can succeed without
>> > good management, regardless of how good he is. Programming
>> > is a team effort---one person, working alone, cannot produce
>> > good code.
>
>> That is completely incorrect.
>
> I'm sorry, but it's a proven fact.

Beware of people who claim something was a "proven fact".

> Note that
> working in a team is a necessary condition, but not necessarily
> a sufficient one.

Well, if you are working in a team, then teamwork is necessary. There are
types of Software that can usually not be developed alone, because of the
complexity of the whole thing. There are very many Programmers that can not
work alone, because they either are good at Software Design or at coding or
at project management.

Nevertheless there are people who are equally good at project management,
software architecture and coding. It is not the usual case, but they can
produce high quality software alone. Sometimes they don't do it alone,
because the effort they are working on is better solved in a team.

Christof

== 4 of 6 ==
Date: Tues, Jul 28 2009 2:42 am
From: James Kanze

On Jul 27, 5:39 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> James Kanze <james.ka...@gmail.com> writes:
> > On Jul 26, 9:58 am, Ian Collins <ian-n...@hotmail.com> wrote:
> >> James Kanze wrote:
> >> > On Jul 25, 10:34 am, Ian Collins <ian-n...@hotmail.com> wrote:
> >> I still find that statement rather offensive. I done a lot
> >> of solo projects for several clients in various corners of
> >> the globe over the past decade and I've produced plenty of
> >> what I still consider to be very good code.

> > It's not offensive, it's a fact of life. I've done a lot of
> > solo work in the past, as well. Before the importance of
> > teamwork was fully recognized everywhere. At the time, I
> > considered the code "very good". And it was, compared to,
> > say, what other people working alone were producing. But in
> > the last large project I did that way, the integration and
> > test team still found four errors. For about 40
> > KLOC---that's one error per 10 thousand lines of code.
> > Where as I've seen programmers who I'd consider considerably
> > less skilled than I produce code with only one error per 100
> > KLOC, thanks to things like code review and such. Today, I
> > simply cannot meet the standards I set for myself (and
> > others) without help from others.

> Interesting. While the bug count indeed must be reduced, I
> wouldn't say that's the most important factor of code quality.
> I would put code maintainability first.

Both are important. It's just that the error count is easiest
to measure.

> But anyways, your example doesn't involves more than one
> programmer. It's good to have testers. And perhaps other
> kinds of people in a team around a programmer.

OK. I should have used some other word than programmer,
perhaps, although in the places I've worked, the testers were
also programmers. But I was talking about the total production
of the code, which does involve much more than just coding.

Of course, in order to ensure maintainability, you need code
review by people with the same profile as those who will be
called on to maintain the code, which means that they're
qualified as programmers, even if they aren't actually
"programming" when doing the review.

The important fact is that the final product is a team effort.

> That's basically what is advocated in The Mythical Man Month
> actually.

Amongst other things. That you need a team, and that not
everyone in the team should have the same qualifications.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

== 5 of 6 ==
Date: Tues, Jul 28 2009 2:46 am
From: James Kanze

On Jul 27, 5:34 pm, Andrew Tomazos <and...@tomazos.com> wrote:
> On Jul 27, 4:03 pm, James Kanze <james.ka...@gmail.com> wrote:

> > > I have personally seen a 400k line codebase that was
> > > written largely by one person that was (and maybe its
> > > latest versions still is) used by nearly a million people
> > > with minimal marketing.

> > And? A lot of people are using a lot of junk.

> The software in question won numerous high profile awards in
> the face of competition, and people described themselves as
> "huge fans" of it. It was noted not only for its nice user
> interface, but for its amazing robustness. It was most
> certainly good software. Its existence disproves your
> statement.

And of course, you won't tell us what it was, or give us any
other means of verifying your claims. (Windows NT also won some
awards, and a number of people liked it, but it's hardly what I
would call good software.)

[...]
> It has been known for some time that good programmers can be
> 100x effective than average ones.

It has been known for some time that the world is flat, too.
Actual measurements, of course, have proven the opposite, but
that doesn't bother some people.

== 6 of 6 ==
Date: Tues, Jul 28 2009 2:52 am
From: James Kanze

On Jul 28, 11:44 am, Christof Donat <c...@okunah.de> wrote:
> >> > I don't think a professional programmer can succeed
> >> > without good management, regardless of how good he is.
> >> > Programming is a team effort---one person, working alone,
> >> > cannot produce good code.

> >> That is completely incorrect.

> > I'm sorry, but it's a proven fact.

> Beware of people who claim something was a "proven fact".

Because they might be right?

> > Note that working in a team is a necessary condition, but
> > not necessarily a sufficient one.

> Well, if you are working in a team, then teamwork is
> necessary. There are types of Software that can usually not be
> developed alone, because of the complexity of the whole thing.
> There are very many Programmers that can not work alone,
> because they either are good at Software Design or at coding
> or at project management.

There are, in fact, no human beings who are perfect, and don't
make mistakes. An effectively managed team can reduces these
significantly, however, because the mistakes of one person will
be caught and corrected by another.

> Nevertheless there are people who are equally good at project
> management, software architecture and coding.

That's true, but only in a negative sense. (There are people
who are totally incompetent at all three.) No one can shine in
all possible areas, however.

But that's not the point. No one is perfect in any area. We
all make mistakes. Having some one else review our work catches
most of those mistakes (supposing that person is competent as
well); the mistakes he makes (the points he misses in the
review) will not be the same ones we make. (Statistically, at
least.)

==============================================================================
TOPIC: Need to use "volatile" for accessing variables between threads?
http://groups.google.com/group/comp.lang.c++/t/4e68d5b929c344d4?hl=en
==============================================================================

== 1 of 7 ==
Date: Tues, Jul 28 2009 12:28 am
From: "Fred Zwarts"

"Virchanza" <virtual@lavabit.com> wrote in message news:9fec04a7-3120-490b-8b9d-524a7bc25eeb@p23g2000vbl.googlegroups.com...
>
> Volatile is intended to be used where a variable's value can
> mysteriously change outside of the normal flow of code.

Normally it is used in device drivers when accessing hardware registers,
which can be updated by the hardware in a way unknown to the compiler.

> I'm still not sure whether "a separate thread" qualifies as being
> mysterious enough. Some people are telling me I need volatile. Others
> are telling me I don't need volatile. I don't know who to believe.
>
> Is it even possible to get an answer to this question, or is it simply
> "undefined"?

The C++ standard does not define the behaviour of threads.
So, the answer to this question is not in the C++ standard.
Threading is usually supported by the underlying operating system.
So, your question is best answered in other news groups.
As others have said, Linux uses posix threads. If the mutex
lock and unlock functions of posix are used, volatile is not needed.
Similarly, when using Windows' native locking, volatile is not needed.
For other operating systems consult the documentation or the appropriate
news group.

== 2 of 7 ==
Date: Tues, Jul 28 2009 1:25 am
From: Joshua Maurice

On Jul 27, 7:17 pm, Virchanza <virt...@lavabit.com> wrote:
> On Jul 28, 12:02 am, Greg Herlihy <gre...@mac.com> wrote:
> > In this case, the value of the variable can change asynchronously with
> > regard to the current execution flow - and it does not matter how or
> > why its value may change. To the compiler a value changed by another
> > thread is just as asynchronous a change as one, say, made by memory-
> > mapped I/O. And in either case, the "volatile" keyword is needed to
> > prevent the compiler from caching that variable's value.
>
> And here I have another person telling me I need volatile.

As noted by Alf, Greg might want to read on in that paper to the end
where they conclude that volatile as generally implemented is entirely
insufficient as a portable threading primitive in C++. Simply put, the
standard's intent for volatile is mostly memory mapped IO, not
threading, and most compiler writers have implemented this intent,
making volatile not useful as a threading primitive.

== 3 of 7 ==
Date: Tues, Jul 28 2009 1:46 am
From: James Kanze

On Jul 27, 7:02 pm, Greg Herlihy <gre...@mac.com> wrote:
> On Jul 27, 6:37 am, Richard Herring <junk@[127.0.0.1]> wrote:

> > In message
> > <9fec04a7-3120-490b-8b9d-524a7bc25...@p23g2000vbl.googlegroups.com>,
> > Virchanza <virt...@lavabit.com> writes

> > >Volatile is intended to be used where a variable's value
> > >can mysteriously change outside of the normal flow of code.

> ...which is exactly how changes to a variable's value made on
> one thread - appear to another thread.

> > >I'm still not sure whether "a separate thread" qualifies as
> > >being mysterious enough. Some people are telling me I need
> > >volatile. Others are telling me I don't need volatile. I
> > >don't know who to believe.

> You do need "volatile"

You might need volatile under some systems (although I don't
know of any). You don't need it under Posix (at least according
to the Posix standard).

> - but volatile is by itself is not enough to make your program
> thread-safe. You will also need some kind of memory barrier
> (or some mutual exclusion mechanism).

> > >Is it even possible to get an answer to this question, or
> > >is it simply "undefined"?

> The effect of "volatile" is clearly defined- and clearly
> needed for any variable whose value can change asynchronously
> with regard to the current execution flow.

The effect of volatile is very loosely defined, intentionally.
The effect of starting a second thread is, in the current C++
standard, undefined behavior, so you can't ask the C++ standard
anything about what is needed. Posix (and presumably Windows
and other OS's) does define this undefined behavior. If the
compiler is Posix compatible (or compatible with the OS it is
running under), then you don't need volatile. If it's not, you
can't use threads with the compiler, period.

FWIW, in practice, none of the compilers I know actually
implement volatile so that it would work, even for its intended
purposes. They do nothing to ensure that modifications "unkown
to the implementation" will be taken into account, and they do
nothing to ensure that a write to a volatile variable will
actually be seen by the hardware.

> > >I'm still not decided.

> > I think what you're being told is this:

> > 1. volatile doesn't imply atomic access, and therefore it
> > can't guarantee that another thread won't change a shared
> > variable while you're half-way through reading it.

> True. But the reason why the variable must be declared
> "volatile" has nothing to do with assuring exclusive access
> or, really, anything to do with threading in particular.

With regards to threading, the only reason possible why a
variable must be declared volatile is that the specifications of
the implementation require it. That's not the case with Posix,
nor as far as I can tell, Windows.

> > 2. Therefore you need some other mechanism to guarantee
> > thread-safe shared access.
> > 3. Once you have that other mechanism in place, there's no
> > need to use volatile.

> Not so. Declaring a variable "volatile" forces the compiler to
> load that variable's value from memory each time that value is
> needed.

In theory. (In practice, that's not the case with g++, Sun CC
or VC++.) But that's not required for threading. All that's
required is that any local copies have been purged since the
variable was last modified elsewhere. And pthread_mutex_lock
guarantees that (under Posix).

> Otherwise - if there are no apparent write operations to the
> variable within a given block of code - then the compiler is
> very likely to store the variable's value in a register once
> at the beginning of the block; and then use the register-based
> value in subsequent operations as that variable's current
> value.

Which is fine.

> In this case, the value of the variable can change
> asynchronously with regard to the current execution flow - and
> it does not matter how or why its value may change.

If the value is modified by another thread, you have undefined
behavior, according to Posix. If an object (in the C++ meaning
of the word) is modified by any thread, and accessed in any way
by more than one thread, all accesses to the object must be
synchronized. And of course, the compiler is not allowed to
store the variable's value in a register across synchronization
requests.

> To the compiler a value changed by another thread is just as
> asynchronous a change as one, say, made by memory-mapped I/O.

Certainly, but since Posix says that such asynchronous requests
are undefined behavior, even with volatile, it doesn't matter.

> And in either case, the "volatile" keyword is needed to
> prevent the compiler from caching that variable's value.

No. In the first case, Posix defines the access as undefined,
period, with or without volatile. In the second, you're very
deap in implementation defined territory, and you'll have to
follow whatever rules the implementation defines. (The original
purpose of volatile *was* to support such uses, but in practice,
most implementations don't. Thus, for example, the Sparc
architecture manual specifies very clearly that in the case of
memory mapped I/O, all accesses must use a membar instruction to
ensure synchronization, but neither g++ nor Sun CC generate a
membar instruction when accessing a volatile variable.)

== 4 of 7 ==
Date: Tues, Jul 28 2009 2:00 am
From: James Kanze

On Jul 27, 7:58 pm, "Bo Persson" <b...@gmb.dk> wrote:
> Greg Herlihy wrote:
> > On Jul 27, 6:37 am, Richard Herring <junk@[127.0.0.1]> wrote:
> >> 3. Once you have that other mechanism in place, there's no
> >> need to use volatile.

> > Not so. Declaring a variable "volatile" forces the compiler
> > to load that variable's value from memory each time that
> > value is needed. Otherwise - if there are no apparent write
> > operations to the variable within a given block of code -
> > then the compiler is very likely to store the variable's
> > value in a register once at the beginning of the block; and
> > then use the register-based value in subsequent operations
> > as that variable's current value.

> I agree with Richard here. Once the "other mechanism" is in
> place, presumably a mutex involving an OS call, the compiler
> cannot cache values across the OS call - unless it first makes
> sure that the OS is not using any callbacks previously set,
> that just might affect our protected variable. Whether it is
> volatile or not doesn't matter.

Just a nit, but it has nothing to do with callbacks or any other
particular feature. A compiler cannot cache values accross
certain OS calls because the OS specifications say that it
can't.

== 5 of 7 ==
Date: Tues, Jul 28 2009 2:12 am
From: James Kanze

On Jul 28, 4:17 am, Virchanza <virt...@lavabit.com> wrote:
> On Jul 28, 12:02 am, Greg Herlihy <gre...@mac.com> wrote:

> > In this case, the value of the variable can change
> > asynchronously with regard to the current execution flow -
> > and it does not matter how or why its value may change. To
> > the compiler a value changed by another thread is just as
> > asynchronous a change as one, say, made by memory- mapped
> > I/O. And in either case, the "volatile" keyword is needed to
> > prevent the compiler from caching that variable's value.

> And here I have another person telling me I need volatile.

> Honestly I don't know who to believe.

Believe the standard or specification of the system(s) you're
concerned with. Posix says you don't need volatile. So does
Microsoft. For other systems, I don't know; you'll have to
check their documentation.

Note too that a lot of compilers don't really implement volatile
in a way conformant to the intent of the standard. (Formally,
much of the semantics of volatile are implementation defined,
but the intent is clear that each "access" should be externally
visible in some way---a read physically reads whatever is
addressed, and a write physically writes it. On most modern
processors, this requires special instructions, membar, fence,
or at least a lock prefix on an Intel. G++, Sun CC and VC++
don't generate this special code.)

> Let's say I had a function like:

> void SetNullTerminatedArrayToAllFives(int *p)
> {
> for (;;)
> {
> if (!*p) return;
> *p++ = 5;
> }
> }

> And let's say I have a global null-terminated array:

> int my_array[6] = {5,4,3,2,1,0};

> And now let's say this will be used between threads, so I make
> it volatile:

> int volatile my_array[6] = {5,4,3,2,1,0};

Again, at least under Posix or Windows, you don't need to
declare if volatile.

> Now the problem here is that I can't pass this array to the
> above function because I'll get a type mismatch with the
> "volatile".

Yes, because if the array is volatile, the compiler must
generate special (significantly slower) code to access it. (On
a Sun Sparc, if the compiler actually implemented volatile so
that it would guarantee visibilitiy, the code would run about
five times slower.)

> Is it necessary to do something like:

> int volatile my_volatile_array[6] = {5,4,3,2,1,0};

> int (&my_array)[6] = (int (&my_array)[6])my_volatile_array;

That would result in undefined behavior. If you've declared the
array volatile (in practice, I don't think I've ever seen a case
where volatile would be applicable to an array), then you've
told the compiler that all accesses to it must obey special
rules. If you access it through a non-volatile lvalue, the
compiler won't know to apply these special rules, and you'll get
undefined behavior as a result.

> I rather create the above reference than litter my code with
> "volatile". Or will creating the reference somehow subvert the
> volatileness of the object???

It's undefined behavior. Anything might happen. (In practice,
it probably won't change anything, because volatile doesn't
actually do anything significant with most compilers.)

== 6 of 7 ==
Date: Tues, Jul 28 2009 2:24 am
From: James Kanze

On Jul 28, 12:00 am, "Alf P. Steinbach" <al...@start.no> wrote:
> * Greg Herlihy:
> > On Jul 27, 6:51 am, "Alf P. Steinbach" <al...@start.no> wrote:
> >> * Virchanza:

> >>> Volatile is intended to be used where a variable's value
> >>> can mysteriously change outside of the normal flow of
> >>> code. I'm still not sure whether "a separate thread"
> >>> qualifies as being mysterious enough. Some people are
> >>> telling me I need volatile. Others are telling me I don't
> >>> need volatile. I don't know who to believe. Is it even
> >>> possible to get an answer to this question, or is it
> >>> simply "undefined"?
> >> It was answered definitively here:
> >> <url:http://www.google.com/search?q=alexandrescu+meyers+volatile>

> > Presumably, you mean that the Meyers & Alexandrescu paper on
> > double- checked locking:

> >http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf

> > provides a definitive answer.

> > And it does. The paper concludes that "volatile" is needed
> > in order to ensure thread-safety - and in fact is needed
> > more than once:

> > "Our earlier analysis shows that pInstance needs to be
> > declared 'volatile', and in fact this point is made in the
> > papers on DCLP. However, Sherlock Holmes would certainly
> > notice that, in order to ensure correct instruction order,
> > the Singleton object -itself- must be also 'volatile'. This
> > is not noted in the original DCLP papers, and that's an
> > important oversight." [pg 7-8].

> You might read on... ;-)

Note that that paper really only addresses one side of the
issue: why you can't avoid the lock. It clearly proves that
volatile is not sufficient. It doesn't address the question as
to whether volatile is necessary or not once you use the thread
synchronization primitives. For that, you need to check the
specifications of the thread synchronization primitives, and
threading in your environment. Both Posix and the Microsoft
documentation say clearly that the thread synchronization
primitives ensure memory synchronization, and so volatile is not
necessary (assuming that your compiler is compliant with the OS,
as well as with the C++ standard)---C++0x will take this path as
well.

== 7 of 7 ==
Date: Tues, Jul 28 2009 2:33 am
From: James Kanze

On Jul 28, 7:41 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> "James Kanze" <james.ka...@gmail.com> wrote in message

> news:524fc5b3-e99e-48af-bd56-a56ca74e7366@v36g2000yqv.googlegroups.com...
> On Jul 27, 2:58 pm, Virchanza <virt...@lavabit.com> wrote:
>
> > > Volatile is intended to be used where a variable's value
> > > can mysteriously change outside of the normal flow of
> > > code. I'm still not sure whether "a separate thread"
> > > qualifies as being mysterious enough.
> > It's mysterious enough, in that sense. The point is that
> > your synchronization requests have already specified that
> > such changes can occur, outside the protected region. (In
> > fact, many compilers, such as Sun CC, g++ and VC++, don't
> > implement sufficient synchronization for volatile to be
> > usable for much of anything. Such compilers are arguably
> > broken, but you'll almost certainly have to use them.)

> [...]

> FWIW, MSVC compilers, versions 8 and above, automatically
> insert load-acquire/store-release barriers for volatile loads
> and stores on certain architectures (e.g., PowerPC):

I knew that Microsoft intended to do this; I hadn't seen it on
the compilers I'd verified. (I forget which version it was, but
it was on a 32 bit Intel.) Microsoft actually proposed this
extension to the meaning of volatile to the standardization
committee, and indicated that they were implementing it in their
compilers. (If I'm not mistaken, it corresponds to the meaning
of volatile in C#.)

==============================================================================
TOPIC: A silly belief shattered (happily)
http://groups.google.com/group/comp.lang.c++/t/34c9bf7361966608?hl=en
==============================================================================

== 1 of 6 ==
Date: Tues, Jul 28 2009 12:31 am
From: "Alf P. Steinbach"

For as long as I can remember I have, incorrectly, believed that

MACRO ( whatever )

would not be a valid macro invocation.

Of course the space before "(" wreaks havoc with a macro-with-args /definition/,
and that may be where I got the impression from.

Anyway, with the space allowed much is simplified...

Cheers,

- Alf (amazed at the macro trickery in Boost Preprocessor)

== 2 of 6 ==
Date: Tues, Jul 28 2009 12:55 am
From: Vladimir Jovic

Alf P. Steinbach wrote:
> For as long as I can remember I have, incorrectly, believed that
>
> MACRO ( whatever )
>
> would not be a valid macro invocation.
>
> Of course the space before "(" wreaks havoc with a macro-with-args
> /definition/, and that may be where I got the impression from.
>
> Anyway, with the space allowed much is simplified...

For example?

== 3 of 6 ==
Date: Tues, Jul 28 2009 1:14 am
From: "Alf P. Steinbach"

* Vladimir Jovic:
> Alf P. Steinbach wrote:
>> For as long as I can remember I have, incorrectly, believed that
>>
>> MACRO ( whatever )
>>
>> would not be a valid macro invocation.
>>
>> Of course the space before "(" wreaks havoc with a macro-with-args
>> /definition/, and that may be where I got the impression from.
>>
>> Anyway, with the space allowed much is simplified...
>
> For example?

#define FIRST( a, b, c ) a

#define BLAHBLAH( tuple ) FIRST tuple

int main()
{
BLAHBLAH( (42, 41, 43) ); // 42
}

Cheers,

- Alf

== 4 of 6 ==
Date: Tues, Jul 28 2009 1:25 am
From: Vladimir Jovic

Alf P. Steinbach wrote:
> * Vladimir Jovic:
>> Alf P. Steinbach wrote:
>>> For as long as I can remember I have, incorrectly, believed that
>>>
>>> MACRO ( whatever )
>>>
>>> would not be a valid macro invocation.
>>>
>>> Of course the space before "(" wreaks havoc with a macro-with-args
>>> /definition/, and that may be where I got the impression from.
>>>
>>> Anyway, with the space allowed much is simplified...
>>
>> For example?
>
> #define FIRST( a, b, c ) a
>
> #define BLAHBLAH( tuple ) FIRST tuple
>
> int main()
> {
> BLAHBLAH( (42, 41, 43) ); // 42
> }

Ok, so this:
BLAHBLAH ( 42, 41, 43 ); // 42
is causing a compilation error, but this:
BLAHBLAH ( (42, 41, 43) ); // 42
is not.

Is that what you are saying?

== 5 of 6 ==
Date: Tues, Jul 28 2009 1:30 am
From: Ian Collins

Vladimir Jovic wrote:
> Alf P. Steinbach wrote:
>> * Vladimir Jovic:
>>> Alf P. Steinbach wrote:
>>>> For as long as I can remember I have, incorrectly, believed that
>>>>
>>>> MACRO ( whatever )
>>>>
>>>> would not be a valid macro invocation.
>>>>
>>>> Of course the space before "(" wreaks havoc with a macro-with-args
>>>> /definition/, and that may be where I got the impression from.
>>>>
>>>> Anyway, with the space allowed much is simplified...
>>>
>>> For example?
>>
>> #define FIRST( a, b, c ) a
>>
>> #define BLAHBLAH( tuple ) FIRST tuple
>>
>> int main()
>> {
>> BLAHBLAH( (42, 41, 43) ); // 42
>> }
>
> Ok, so this:
> BLAHBLAH ( 42, 41, 43 ); // 42
> is causing a compilation error, but this:
> BLAHBLAH ( (42, 41, 43) ); // 42
> is not.
>
> Is that what you are saying?

The key is

FIRST (42, 41, 43)

works.

--
Ian Collins

== 6 of 6 ==
Date: Tues, Jul 28 2009 1:35 am
From: "Alf P. Steinbach"

* Vladimir Jovic:
> Alf P. Steinbach wrote:
>> * Vladimir Jovic:
>>> Alf P. Steinbach wrote:
>>>> For as long as I can remember I have, incorrectly, believed that
>>>>
>>>> MACRO ( whatever )
>>>>
>>>> would not be a valid macro invocation.
>>>>
>>>> Of course the space before "(" wreaks havoc with a macro-with-args
>>>> /definition/, and that may be where I got the impression from.
>>>>
>>>> Anyway, with the space allowed much is simplified...
>>>
>>> For example?
>>
>> #define FIRST( a, b, c ) a
>>
>> #define BLAHBLAH( tuple ) FIRST tuple
>>
>> int main()
>> {
>> BLAHBLAH( (42, 41, 43) ); // 42
>> }
>
> Ok, so this:
> BLAHBLAH ( 42, 41, 43 ); // 42
> is causing a compilation error, but this:
> BLAHBLAH ( (42, 41, 43) ); // 42
> is not.
>
> Is that what you are saying?

No, I'm saying that because the space is allowed one can easily let macros
produce other macro invocations, where the name of the macro to be invoked is a
parameter (otherwise, token-pasting via ## doesn't produce a valid token).

I've not done much macro stuff (obviously!).

But now I need some facility to simplify some notation, and I'm amazed at what's
possible using just the primitive C and C++ preprocessor.

Cheers,

- Alf

==============================================================================
TOPIC: How can I use unqualified names? (Possibly hard or impossible?)
http://groups.google.com/group/comp.lang.c++/t/e2f24a95fe72b591?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jul 28 2009 1:22 am
From: James Kanze

On Jul 28, 12:23 am, "Alf P. Steinbach" <al...@start.no> wrote:
> * Martin Eisenberg:

> > Alf P. Steinbach wrote:

> >> What Andrei did was to show how all the usual run time
> >> control structures had analogs in template metaprogramming,
> >> and to build up from that to a framework handling types
> >> just as for run time you handle values.

> > I believe that credit should go to Czarnecki and Eisenecker,
> > whom MC++D also references.

> As I wrote and you snipped, typelists already had some history.

> The game of credit (and of snippage) is very silly.

> I've never heard of Czarnecki and Eisenecker, and I doubt any
> reader here will be helped by that reference.

Why not? They *are* the authors of one of the original
reference works concerning meta-programming.

> On the other hand, readers might find it useful to know what
> Andrei did, in order to decide whether to buy that book. It
> also contains a lot of generic implementations of patterns,
> which perhaps was its main innovation, and at least a main
> reason for its popularity,

It would be interesting to know why one book becomes popular,
and another not. Maybe Andrei is a better writer than some
others.

Todd Veldhuizen had shown that templates in C++ formed a Turing
complete language as early as 1995; from personal discussions
with David Vandevoorde, I believe that he was doing similar work
at about the same time. In this regard, Andrei is more or less
a latecomer to the field. But perhaps is book presents a more
easily understandable synthesis than earlier works.

==============================================================================
TOPIC: How to write previous element in STL list
http://groups.google.com/group/comp.lang.c++/t/2d136691c93121bf?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jul 28 2009 1:27 am
From: James Kanze

On Jul 27, 6:16 pm, cornelis van der bent
<kees.van.der.b...@gmail.com> wrote:
> On 27 jul, 17:42, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> > cornelis van der bent wrote:

> > > In my code I want to go through all combinations of two
> > > items in a list. Here is my code:

> > > list<Instance*>::iterator i;
> > > for (i = instances.begin(); i != --instances.end(); i++)
> > > {
> > > list<Instance*>::iterator j;
> > > for (j = i + 1; j < instances.end(); j++)
> > > {
> > > // Do something!
> > > }
> > > }

> > > I get a big error message at i + 1.

> > Such an operation is only defined for random-access
> > iterators, and the list iterator isn't one.

> Do you know reason(s) why this has nog been implemented for a
> list? The list is doubly-linked, so giving back an iterator
> one postion earlier/further does not seem to be a big deal.

But operator+ isn't limited to adding one. Operator+ is defined
when it can be done in constant time; with list, it requires
linear time (with regards to what is being added).

One simple solution would be to define functions succ and prec:

template< typename ForwardIterator >
ForwardIterator
succ( ForwardIterator i )
{
++ i ;
return i ;
}

template< typename BidirectionalIterator >
BidirectionalIterator
prec( BidirectionalIterator i )
{
-- i ;
return i ;
}

More generally, one does wonder why std::advance takes a
reference to the iterator and updates it, rather than taking an
iterator, and returning the modified iterator.

==============================================================================
TOPIC: Difference between Char* ptr and char arrCh []
http://groups.google.com/group/comp.lang.c++/t/3971db675cb4d039?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jul 28 2009 1:52 am
From: Nick Keighley

X-posted to comp.lang.c++

On 27 July, 17:55, AY <techreposit...@gmail.com> wrote:

> I have a few queries regarding array of characters using array
> notation and pointer notation.
>
> [ #1 ]
>
> Is there a difference in storage of global char* and char* inside a
> function ?
>
> consider the code:
>
> char* globalCh = "MY STRING";
>
> void foo()
> {
> char* simpleCh = "My String";
> }
>
> What I understand is in the case of 'char* simpleCh' - the
> pointer .i.e. ' *simpleCh' is stored in the stack, while the value "
> My String" is stored elsewhere in a data segment. Taking the sizeof
> (simpleCh) would be 4 bytes in my machine. Once the function exits "My
> String" is no longer accessible.
>
> Taking the sizeof(globalCh) = 4 bytes and where is the value ' MY
> STRING ' and the pointer ' *globalCh ' stored ? since its a global
> variable the storage of the pointer ' *globalCh ' should be in a
> static area. That means should it be in the code segment?
>
> [ #2 ]
>
> void foo()
> {
> char* pch = new char[25];

this isn't valid C (C has no new operator). If you are coding
in C++ why not use std::vector or even std::string. This avoids
the problems you are having with assigning strings etc.

I usually find using the array form of new is a mistake
(at least it's an easy way to grep a source base for potential
mistakes!)

> strncpy(pch, "ABCD", 4);
> pch[4] = '\0';
>
> // pch = "KLMN"; // ERROR !
> }
>
> We can't de-reference pch = "KLMN"; Is it because 'pch' allocated in
> the heap, while "KLMN" is in some variable location?
>
> [ #3 ]
>
> Assuming
> char* str = "ABCD"; is same as const char* str =
> "ABCD"; [ what it points to is constant ], but we can dereference as
>
> str = "XYZ"; // OK !
> str[1] = 'L'; // ERROR !!!!
>
> Can we think of char arrCh[] = " ABCD" as ' char * const arrCh
> ' ( i.e. we can't modify the address ) ?
>
> We can't dereference
>
> arrCh = "XYZ"; // ERROR !
> arrCh[ 2 ] = 'K' ; // Fine !
>
> [ #4 ]
>
> Which one of the ' char array ' notation is the most preferred one, is
> it the pointer notation ( char *ptr = " ABCD" ) or the array notation
> ( char arrCh[] = "ABCD" ) ? Why is it one preferred over the other?
>
> Appreciate your suggestions,

pick a language

--
Nick Keighley

"I wish to God these calculations had been accomplished by steam."
--C. Babbage

==============================================================================
TOPIC: ╰❉╮╰❉╮ Crazy Sell In Summer T-shirts==D&G,Lacoste,LV,GUCCI,Adidas,Ecko,
ED Hardy,POLO,,,etc.Paypal Payment Free Shipping
http://groups.google.com/group/comp.lang.c++/t/a071506a66f4618a?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jul 28 2009 2:22 am
From: "www.guomeitrade.com"

╰❉╮╰❉╮Crazy Sell In Summer T-
shirts==D&G,Lacoste,LV,GUCCI,Adidas,Ecko,ED Hardy,POLO,,,etc.Paypal
Payment Free Shipping

T-shirts--http://www.guomeitrade.com/category-871-b0-T-Shirt.html

Online Store www.guomeitrade.com

T-shirt
http://www.guomeitrade.com/category-871-b0-T-Shirt.html

A&F T-Shirt
http://www.guomeitrade.com/category-872-b0-AF-T-Shirt.html

AFF Man T-Shirt
http://www.guomeitrade.com/category-875-b0-AFF-Man-T-Shirt.html

Armani T-Shirt
http://www.guomeitrade.com/category-876-b0-Armani-T-Shirt.html

Bape Man T-Shirt
http://www.guomeitrade.com/category-878-b0-Bape-Man-T-Shirt.html

BBC Man T-Shirt
http://www.guomeitrade.com/category-879-b0-BBC-Man-T-Shirt.html

Blar Label Man T-Shirt
http://www.guomeitrade.com/category-880-b0-Blar-Label-Man-T-Shirt.html

Burberry Man T-Shirt
http://www.guomeitrade.com/category-882-b0-Burberry-Man-T-Shirt.html

Christan Audigier T-Shirt
http://www.guomeitrade.com/category-883-b0-Christan-Audigier-T-Shirt....

Coogi Man T-Shirt
http://www.guomeitrade.com/category-884-b0-Coogi-Man-T-Shirt.html

D&G Man T-Shirt
http://www.guomeitrade.com/category-886-b0-DG-Man-T-Shirt.html

Diesel Man T-Shirt
http://www.guomeitrade.com/category-887-b0-Diesel-Man-T-Shirt.html

Ecko Man T-Shirt
http://www.guomeitrade.com/category-888-b0-Ecko-Man-T-Shirt.html

ED Hardy T-Shirt
http://www.guomeitrade.com/category-889-b0-ED-Hardy-T-Shirt.html

Evisu Man T-Shirt
http://www.guomeitrade.com/category-892-b0-Evisu-Man-T-Shirt.html

Gino Green Global Man T-Shirt
http://www.guomeitrade.com/category-893-b0-Gino-Green-Global-Man-T-Sh...

G-Star Man T-Shirt
http://www.guomeitrade.com/category-894-b0-G-Star-Man-T-Shirt.html

Juicy Women T-Shirt
http://www.guomeitrade.com/category-895-b0-Juicy-Women-T-Shirt.html

Lacoste T-Shirt
http://www.guomeitrade.com/category-896-b0-Lacoste-T-Shirt.html

LEVI'S Man T-Shirt
http://www.guomeitrade.com/category-899-b0-LEVI%E2%80%99S-Man-T-Shirt...

LV Man T-Shirt
http://www.guomeitrade.com/category-901-b0-LV-Man-T-Shirt.html

Nike Man T-Shirt
http://www.guomeitrade.com/category-902-b0-Nike-Man-T-Shirt.html

POLO T-Shirt
http://www.guomeitrade.com/category-903-b0-POLO-T-Shirt.html

SMET Man T-Shirt
http://www.guomeitrade.com/category-907-b0-SMET-Man-T-Shirt.html

Smful Man T-Shirt
http://www.guomeitrade.com/category-908-b0-Smful-Man-T-Shirt.html

Versace Man T-Shirt
http://www.guomeitrade.com/category-909-b0-Versace-Man-T-Shirt.html

GUCCI T-Shirt
http://www.guomeitrade.com/category-1625-b0-GUCCI-T-Shirt.html

Crown Holder T-Shirt
http://www.guomeitrade.com/category-1924-b0-Crown-Holder-T-Shirt.html

Baby T-Shirt
http://www.guomeitrade.com/category-1923-b0-Baby-T-Shirt.html

Akademiks T-Shirt
http://www.guomeitrade.com/category-1920-b0-Akademiks-T-Shirt.html

Adidas T-Shirt
http://www.guomeitrade.com/category-1917-b0-Adidas-T-Shirt.html

5ive Jungle T-Shirt
http://www.guomeitrade.com/category-1916-b0-5ive-Jungle-T-Shirt.html

Rocawear T-Shirt
http://www.guomeitrade.com/category-1930-b0-Rocawear-T-Shirt.html

==============================================================================
TOPIC: is this standard C++ MyClass::+
http://groups.google.com/group/comp.lang.c++/t/a10cb21b32f40222?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jul 28 2009 2:49 am
From: Nick Keighley

Is this standard C++ or some (Microsoft?) extension?

This seemed to be a member function definition

Type MyClass::+ ()
{
}

It seemed to be an alias for a function that appeared in the class
definition

--
Nick Keighley

== 2 of 2 ==
Date: Tues, Jul 28 2009 2:54 am
From: Christof Donat

Hi,

> Is this standard C++ or some (Microsoft?) extension?
>
> This seemed to be a member function definition
>
> Type MyClass::+ ()
> {
> }
>
> It seemed to be an alias for a function that appeared in the class
> definition

No, this is definatelly not standard. Just get another compiler like e.g. gcc
and check there.

Christof

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

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

Tuesday, July 28, 2009

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

No comments:

Blog Archive

About Me