soft and program: comp.lang.c++ - 26 new messages in 13 topics

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

comp.lang.c++@googlegroups.com

Today's topics:

* Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? - 3 messages, 3
authors
http://groups.google.com/group/comp.lang.c++/t/40783f7f814400c9?hl=en
* How can I use unqualified names? (Possibly hard or impossible?) - 2 messages,
1 author
http://groups.google.com/group/comp.lang.c++/t/e2f24a95fe72b591?hl=en
* New release of the Dynace OO extension to C - 4 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/ee8689156295093c?hl=en
* strcpy vs memcpy - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/71a5945deead500c?hl=en
* template error - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/1d7d6b77e8753579?hl=en
* Can iterator be checked to be at end of vector? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/04f21bec592f548d?hl=en
* How to split this string correctly? - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/1845370483de2cfa?hl=en
* Creating a valid XML processing instruction node - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/38ff83230c0d7c31?hl=en
* ♬ ♫ ♪Hot sale Fashion Lady Handbags Juicy,Burberry,Gucci,LV,Prada,D&G,
Edhardy,Chanel,Coach, Jimmy-Hoo ♡www.toptradea.com♡ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/bada1d4049399f6f?hl=en
* wholesale Iphone,Nokia,Samsung,Blackberry,etc brand mobile phones, TV
mobiles,Music Mobiles, Touch Mobiles, Dual sim card dual standby Chinese
mobile phones - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/94fbc2e2d0700890?hl=en
* ♂◆♀ Wholesale Fashion Jeans Prada,RMC,G-star,Cavalli,Iceberg,Levis,Coogi,BBC,
Laguna,True Religion Jeans www.toptradea.com - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/b3966380749ed631?hl=en
* dealing with lower level programmers - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/f708a2c0cfa8ce2d?hl=en
* Yellowfin 4.1 Released with iPhone BI application - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/090b9ac57310c936?hl=en

==============================================================================
TOPIC: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?
http://groups.google.com/group/comp.lang.c++/t/40783f7f814400c9?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Jul 30 2009 1:58 am
From: Stephen Horne

Appols. for continuing this off-topic stuff - I hope it isn't too
annoying.

After replying, I got curious, and spent some time looking at the Ada
95 rationale. As a result...

On Thu, 30 Jul 2009 04:58:57 +0100, Stephen Horne
<sh006d3592@blueyonder.co.uk> wrote:

>The transition from C to Ada 83 is pretty good, especially if (like
>me) you used Pascal and/or Modula 2 before you used C. There are
>run-time costs, but those costs are there for a reason.

There are exceptions to this that I had forgotten about. Access types
(pointers) have quite severe restrictions, for instance - derestricted
somewhat in Ada 95, but the bad-pointer risk-aversion may still be a
touch excessive.

I have no idea what Ada 2005 adds to the mix.

>Basically, you don't have classes, you have tagged types - ie variant
>records - which support inheritance. That isn't a big deal. But you
>don't have methods. You have normal non-member functions/procedures,
>but some parameters can be designated as special 'classwide'
>parameters - parameters that are run-time bound rather than
>compile-time overloaded.
>
>This approach *IS* justifiable, as it supports multiple dispatch. But
>I haven't used this in Ada. By 1998 I had moved on to C++, I only used
>Ada 83 professionally, and I never got very familiar with Ada 95.

Actually, it doesn't support multiple dispatch. The term is used in
documentation, but refers to a coding trick in which a sequence of
single-dispatch calls give the effect of multiple dispatch - an
approach which is sometimes used in C++ and other languages too, but
which has a significant manual coding overhead.

The syntax of Ada 95 would clearly support multiple dispatch, but the
semantics disallow it. Based on what the rationale says, the reason is
basically that there are insufficient features to manage the dispatch
decision specification properly.

My impression is that the Ada 95 syntax (if you simply remove the
semantic restrictions) would allow the same degree of control as the
treecc domain-specific language, though it has been about 18 months
since I used that. So - based on one tool that has apparently found a
niche - those semantic restrictions may have been a mistake.

That said, I wrote my own DSL because I didn't like the restrictions
in treecc, and since Ada 95 takes a different approach to treecc and
my DSL WRT dispatch handling.

Treecc and my DSL use a distinction between what I call the operation
and the variants (different implementations) of that operation. In
implementation terms, and in my DSL, each variant maps to an inline
function containing the code for one case. Each operation maps to a
normal function which evaluates the dispatch decision, then calls the
appropriate variant-function inline. Variants are inline because they
only really exist as a way of getting the environment right (parameter
types etc) for the code fragments. Each variant inline is called from
precisely one location in the operations dispatch handler.

Having this syntactic concept of a variant means I can have special
kinds of variants, including some that have no implementation code at
all. My DSL defines final variants (can't be overridden), noinherit
variants (handles exact match only), block variants (no implementation
- prevent higher level variants from being inherited, thus causing
compile-time errors if lower level cases aren't all covered), fail
variants (no implementation - if the case occurs, throw an exception)
and more.

Ada 95 tagged types support only early binding, but each tagged type
has an associated "classwide" type which is the true
variant-record-like entity, though Ada has a separate mechanism for
standard variant records. A "classwide" type can have the value of the
basis tagged type, or of any descendant tagged type (or any descendant
tagged types classwide type, if I read it correctly).

Passing a classwide type to a normal Ada function doesn't trigger
run-time binding. The function sees the variant-record-style entity.
However, if I read correctly, a call using a classwide type to a
function that has a range of non-classwide tagged-type-accepting
overloads causes dispatch resolution to be done at the call site.

The point here is that the non-classwide tagged-type-accepting
overloads are just normal overloaded functions - they can be called
using early binding too. They aren't variants of an operation, as in
my DSL - they are full functions in their own right. The called
function isn't special - the call is special.

It's interesting but, truth told, disappointing. No true multiple
dispatch, at least in Ada 95 - don't know about Ada 2005.

>One problem with multiple dispatch, however, is that it isn't really
>compatible with separate compilation. A new compilation unit may
>include definitions that affect dispatch decisions in an already
>compiled unit, by overriding some special cases. DSLs such as mine
>handle this by being DSLs - by limiting their scope, basically, and
>leaving larger scale issues to the main language.

This may also be part of why Ada95 doesn't support true multiple
dispatch.

>though the Ada build process is a bit non-conventional
>anyway due to things like having types which are named in a package
>specification, but are only defined privately in the body - a bit
>better hidden than you get in C/C++, and it means that separate
>compilation has what-size-is-that and similar issues.

This is just wrong - my excuse being that it has been more than a
decade since I used Ada. An Ada package specification has a public
part in which a type can be declared as simply 'private', but if so,
the specification must also have a private part at the end which fills
in the detail of that type so that the compiler can work out the
instance size etc.

== 2 of 3 ==
Date: Thurs, Jul 30 2009 5:28 am
From: Colin Paul Gloster

On Thu, 30 Jul 2009, tmoran@acm.org wrote:

|-----------------------------------------------------------------|
|"[..] |
|When comparing to C, you should remember to turn off all run-time|
|checking, [..]" |
|-----------------------------------------------------------------|

What would be the point of using Ada then? Ada is good, partially
because it has checks.

== 3 of 3 ==
Date: Thurs, Jul 30 2009 4:49 am
From: Martin

On Jul 30, 1:28 pm, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:
> On Thu, 30 Jul 2009, tmo...@acm.org wrote:
>
> |-----------------------------------------------------------------|
> |"[..] |
> |When comparing to C, you should remember to turn off all run-time|
> |checking, [..]" |
> |-----------------------------------------------------------------|
>
> What would be the point of using Ada then? Ada is good, partially
> because it has checks.

The shootout is /completely/ about speed / resource usage "bragging
rights" and nothing to do with how languages are actually used day-to-
day.

You could alternatively start a separate 'shootout' that emphasised
other aspects of programming to highly strengths in other languages,
e.g. "Without recourse to non-language defined libraries, start 2
tasks that..." etc :-)

Cheers
-- Martin

==============================================================================
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 2 ==
Date: Thurs, Jul 30 2009 2:03 am
From: James Kanze

On Jul 30, 2:56 am, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> In article <5477e597-b39d-440b-b1d1-
> c70dcbfe4...@d4g2000yqa.googlegroups.com>, james.ka...@gmail.com
> says...

> [ ... ]
> That's where I see a substantial difference between the set I
> mentioned and something like Cygwin. It at least attempts to
> make some concessions to looking and acting a little bit like
> it was written for Windows. Cygwin, at least from my
> viewpoint, simply attempts to act like Windows is just a
> rather strange version of Unix that takes more than the usual
> porting effort -- but that it should still do its best to BE
> Unix, regardless of the oddities of the kernel on which it's
> running.

Exactly. And that's also a problem with most of the other
Unix-like tool kits I've used. Where as, if I wanted Unix, I'd
use Linux, and drop Windows entirely. What I want is Windows,
but with most of the tools I'm familiar with. I recognize that
they will have to work somewhat differently---it wouldn't bother
me too much if they adopted the / for options, for example,
rather than the -, and used \ for the directory separator (with
some other character---whatever is usual under Windows---for the
escape). Handling white space in filenames is a bit trickier,
and might require some compromises, but for the rest, there's no
real reason to pretend you're under Unix when you're not.

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

== 2 of 2 ==
Date: Thurs, Jul 30 2009 2:06 am
From: James Kanze

On Jul 30, 2:56 am, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> In article <5477e597-b39d-440b-b1d1-
> c70dcbfe4...@d4g2000yqa.googlegroups.com>, james.ka...@gmail.com
> says...

[...]
> That's where I see a substantial difference between the set I
> mentioned and something like Cygwin. It at least attempts to
> make some concessions to looking and acting a little bit like
> it was written for Windows.

I've looked a little bit more at it. I don't see a shell.
Using Unix-like tools means linking them together---the shell is
the glue. And the default Windows command interpreter (what
executes .bat files) is pretty weak. What do Windows users use
for this?

==============================================================================
TOPIC: New release of the Dynace OO extension to C
http://groups.google.com/group/comp.lang.c++/t/ee8689156295093c?hl=en
==============================================================================

== 1 of 4 ==
Date: Thurs, Jul 30 2009 2:06 am
From: "Tech07"

"Jerry Coffin" <jerryvcoffin@yahoo.com> wrote in message
news:MPG.24cf8f111e6208e99896e7@news.sunsite.dk...
> In article <h43b06$msl$1@news.albasani.net>, cr88192@hotmail.com
> says...
>
> [ ... ]
>
>> this is a "convinience" matter, not a "functionality" matter.
>>
>> it is slightly less convinient to use an API call for cleanup.
>> so?...
>
> This is a bit like saying it's slightly more convenient to build a
> house using a saw to cut the wood instead of turning a bunch of
> termites loose and hoping they eat through the wood in exactly the
> way you need it cut.

You're exagerating with the analogy. Analogies are never good when the issue
is understood and you're only using one to argue (read, "escalating analogy
wars").

>
> In theory, I can't prove that it's impossible to explicitly free
> objects when needed -- quite the contrary, it clearly IS _possible_.
> Experience has shown, however, that it's done incorrectly often
> enough that it's a constant source of problems. Nearly every C
> program of any size I've ever seen has sometimes continued to use
> some memory after it was freed, and failed to free to memory after it
> was no longer in use.
>
> The same happens with things like closing files and telling a GUI
> system you no longer need a handle to a resource. In theory, you
> _could_ do all these manually, and you can even do so in fact for
> programs that are really trivial. For a program of any size or
> complexity, however, remains a mostly theoretical possibility.

You're suggesting that the only options are: 1.) C++ RAII, or 2.) "manual"
coding using C. Another alternative is to invent something(s) new, perhaps
to get "adequate" coverage of the concerns. In C, of course, one has no
choice but to invent something, C++ may not be an option, or risk the kind
of inconsistency you described above.

>> yep, but as noted, it is a convinience...
>
> As noted, no, not really. It's about giving yourself a fighting
> chance to create code that might work correctly.

That's not impossible in C and not hardly "an order of magnitude" better in
C++ just because of RAII. It's just incrementatlly better in a number of
scenarios. But again, if C++ isn't an option, then it behooves one to R&D
something(s) consistent for use in C.

>
> [ ... ]
>
>> I also have some belief that, if C++ were "universally better", it
>> would have also "universally displaced C", and such an argument
>> would not have likely taken place.
>
> It seems to me that you're changing the argument considerably in an
> attempt at creating a straw man that nobody can reasonably defend.

Don't look now, but you have made unqualified extreme statements above:

"It's about giving yourself a fighting chance to create code that might work
correctly."

"This is a bit like saying it's slightly more convenient to build a house
using a saw to cut the wood instead of turning a bunch of termites loose
and hoping they eat through the wood in exactly the way you need it cut."

Do you expect the dude to just run out and get a C++ compiler after
unscientific/moot statements?

>
> Look back to the beginning of the thread -- it didn't start out as a
> discussion of whether there was ever a reason to use C. It started
> out with a claim that Dynace was categorically superior to C++, and
> at least strongly implied (if not quite directly stated) that there
> was never a good reason to use C++.

But "claiming" that C++ is "categorically superior" to C or Dynace is OK?

== 2 of 4 ==
Date: Thurs, Jul 30 2009 2:11 am
From: Miles Bader

Juha Nieminen <nospam@thanks.invalid> writes:
>> You almost persuaded me to have another look at C++ myself. Almost, then
>> I realised that as soon as I had another look at it's ghastly syntax and
>> general incomprehensibility, I would go back to C with considerable relief.
>
> I honestly can't understand what you are talking about. I'm sorry, but
> it just sounds like you are being really prejudiced.

I agree bartc's comment sounds silly, but I think there's a certain vibe
you need to get into with any language; if you do, it feels right; if
you don't, it's confusing and seems horrible.

I think C++ may require a bit more practice to get into than some other
languages, but once you do, and if it fits your problem space, it's a
very nice language.

-Miles

--
`There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.'

== 3 of 4 ==
Date: Thurs, Jul 30 2009 2:47 am
From: "Tech07"

"Jerry Coffin" <jerryvcoffin@yahoo.com> wrote in message
news:MPG.24ce9aabebda5dc49896e3@news.sunsite.dk...

> In real use, RAII makes a
> substantial (I'm tempted to say "huge") difference in how you write
> most typical code.

You are comparing apples & orangutans. You seem to mean "typical C code"
compared with "OO C++ code". A more relevant comparison would compare C++
style of resource management with something built on top of C (and I'm not
suggesting something as big as Dynace but rather just some new mechanisms
and consistent style in user land, not language land) given the knowledge of
what was learned with C++. One may find then that "an 80%" solution with C
is decidedly better than a wholistic move to C++. Hence, I say RAII is only
an incremental improvement, if any at all considering the
lock-stock-and-barrel shift needed for the C++ solution.

== 4 of 4 ==
Date: Thurs, Jul 30 2009 2:57 am
From: Miles Bader

"Tech07" <tech07@nospam.hia> writes:
> Hence, I say RAII is only an incremental improvement, if any at all
> considering the lock-stock-and-barrel shift needed for the C++
> solution.

Why is a "lock-stock-and-barrel shift" needed for C++?

You can easily use very C-like subsets if that seems nicer...
(e.g., "only class, no overloading, no templates, no exceptions")

-miles

--
Freebooter, n. A conqueror in a small way of business, whose annexations lack
of the sanctifying merit of magnitude.

==============================================================================
TOPIC: strcpy vs memcpy
http://groups.google.com/group/comp.lang.c++/t/71a5945deead500c?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Jul 30 2009 2:12 am
From: James Kanze

On Jul 29, 11:50 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> In article <X_0cm.123$TB5...@read4.inet.fi>, nos...@thanks.invalid
> says...

> [ ... ]

> > memcpy() might be more efficient because its implementation
> > might be able to copy entire words at a time, rather than
> > single bytes at a time (as strcpy() is forced to do).

> It's not really forced to do so. At least at one time,
> Microsoft used an implementation that scanned for the end,
> then did the copying in a separate pass -- and the copying
> itself was done in 32-bit words.

> With a modern CPU, that would probably be a pessimization
> though -- except under rather special circumstances, anything
> with a cache will combine the reads and writes so all
> transactions with the main memory happen in cache-line sized
> chunks (typically substantially larger than a full word). Such
> a copy will normally be memory-bound anyway, so the difference
> between a really simplistic byte-at-a-time implementation and
> a much more complex one that copies entire words when possible
> will generally be minuscule.

With a modern CPU, the CPU should take care of merging the byte
accesses into word accesses, and copying bytes or words should
not make a significant difference.

With an older CPU, of course, std::copy should be significantly
faster than either, because the compiler can regerate the code
each time it sees the call, taking into account the actual size
and the alignments of the pointers---doing this in memcpy means
you have a lot of extra tests, which slow it down significantly
for small blocks. This is why many compilers actually defined
memcpy and strcpy as macros, expanding to something like
__builtin_memcpy and __builtin_strcpy---the compiler can do a
better job expanding the function each time it is invoked.

== 2 of 3 ==
Date: Thurs, Jul 30 2009 4:08 am
From: ytrembla@nyx.nyx.net (Yannick Tremblay)

In article <8li075ptptkt8bb42q4h3ac6dbcrou8m5k@4ax.com>,
Tim Slattery <Slattery_T@bls.gov> wrote:
>Pallav singh <singh.pallav@gmail.com> wrote:
>
>>when we should use strcpy( ) and when memcpy( ) ? is it w.r.t. to
>>Data Type
>
>strcpy() is more convenient for strings, because it stops when it
>finds a null byte. With memcpy you have to tell it when to stop. Use
>whichever meets your needs.

And any sane programmer will prefer strncpy() over strcpy() for safety
reason unless you do not know the size of the destination.

Of course, since this is a C++ newsgroup, strcpy and strncpy have
little reasons to be used. Prefer std::string. memcpy is probably
better replaced by std::copy()

Yan

== 3 of 3 ==
Date: Thurs, Jul 30 2009 4:15 am
From: ytrembla@nyx.nyx.net (Yannick Tremblay)

In article <MPG.24dabcec87c274b998970e@news.sunsite.dk>,
Jerry Coffin <jerryvcoffin@yahoo.com> wrote:
>In article <4A710164.1070709@matthews.cox.net>,
>Thomas_Really_Hates_Spam@matthews.cox.net says...
>>
>> Remember that strcpy will copy until it finds a '\0'.
>> This could lead to buffer overruns and reading from
>> undefined places in memory.
>>
>> strncpy(), notice the 'n', is a lot safer.
>
>Despite the similarity in the name, strncpy is quite a bit different
>from strcpy, and despite it's "safety", almost nobody ever really
>wants what it does.
>
>1) strncpy does NOT zero-terminate the destination string if the
>source string is longer than the specified length.
>2) If he source is _shorter_ than the specified length, strncpy not
>only zero terminates the string, but also zero-fills the entire rest
>of the buffer (up to the specified length).
>
>As a result, any time strncpy prevents a buffer overrun, we're still
>left with a relatively unsafe condition (a string with no
>terminator).

Agree, strncpy has a somewhat counter intuitive behaviour. But it is
easy to fix the non-terminated string issue using a single line of
code:

char dest[SOME_SIZE];
dest[SOME_SIZE-1] = 0;
strncpy( buffer, source, sizeof(buffer)-1);

Annoying that they did not include it internally in strncpy but not a
justification to use the unsafe strcpy.

As for the filling with nulls... yeah, it might have a very very minor
performance impact but avoiding strncpy because of that would be a
very bad case of premature optimisation.

>In C++ there's rarely a good reason (or even an excuse) for using any
>of the above. Despite its (many) faults, std::string is still clearly
>better.

Absolutely in agreement.

Yan

==============================================================================
TOPIC: template error
http://groups.google.com/group/comp.lang.c++/t/1d7d6b77e8753579?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Jul 30 2009 2:14 am
From: James Kanze

On Jul 30, 8:11 am, red floyd <no.spam.h...@its.invalid> wrote:
> Jerry Coffin wrote:

> > There are times that a using directive (or at least a using
> > declaration) can be useful, and there's no real alternative
> > to it.

> > The canonical example is something like a sort routine. If
> > swap has been specialized for the type being sorted, we want
> > to use that swap. If swap has not been specialized for the
> > type, we want to fall back on using std::swap instead.

> > We can get that with code something like this:

> > using std::swap;

> > template <class T>
> > void sort(/* ... */) {

> > // ...
> > // x1 and x2 are T's.
> > if (x2 < x1)
> > swap(x1, s2);
> > // ...
> > }

> Isn't this the one case where the user is allowed to add to
> std::? That is, specializing a template in std::? Why not
> just specialize std::swap<> for your type T, instead? e.g.:

> class my_expensive_to_swap_class {
> // ...
> public:
> void swap(T&);
> };

> template<>
> std::swap<my_expensive_to_swap_class>(
> my_expensive_to_swap_class& x,
> my_expensive_to_swap_class& y)
> {
> x.swap(y);
> }
> // etc....

That's what I'd generally recommend, but it doesn't work if the
class in question is actually a template; you can specialize a
function in std:: over a single type, but you can't provide an
overload which would work with a template type (officially, at
least---in practice, you almost certainly can).

== 2 of 3 ==
Date: Thurs, Jul 30 2009 2:21 am
From: "Alf P. Steinbach"

* SG:
> On 30 Jul., 08:32, "Alf P. Steinbach" wrote:
>> But if there's a language lawyer nearby it may be highly provocative.
>>
>> For the standard (probably through some mishap) only allows specialization of
>> 'std' namespace classes, not routines,
>
> Are you sure?

No, I made a too sweeping statement. :-)

> Can you quote the standard on that?

Yeah. §17.4.3.1/1 states that "A program may add template specializations for
any standard library template to namespace std."

And this works fine for Jerry's example (at least when fixed, it was evidently
written in haste just as my article), sorry for that over-generalization, mea culpa.

/However/, what I should have written if my memory hadn't over-generalized, was
that you cannot, within strict standard-conformance, do e.g.

namespace std {
template< typename T > void swap( MyArray<T>&, MyArray<T>& );
}

And the reason is that this is /not/ a template specialization (as Jerry's
example was) -- in particular, it's not a partial specialization.

This is an overload.

> If my memory serves me well, Scott Meyers wrote in "Effective C++"
> that it is legal to specialize a function template in std::.

He he. I think we're perhaps in the "slow zone" of the galaxy. But, our Usenet
ruminations will perhaps find their way all the way up to Top Relay. :-)

Cheers & thanks,

- Alf

== 3 of 3 ==
Date: Thurs, Jul 30 2009 2:23 am
From: James Kanze

On Jul 30, 8:32 am, "Alf P. Steinbach" <al...@start.no> wrote:
> * red floyd:
> > Jerry Coffin wrote:

> >> There are times that a using directive (or at least a using
> >> declaration) can be useful, and there's no real alternative
> >> to it.

> >> The canonical example is something like a sort routine. If
> >> swap has been specialized for the type being sorted, we
> >> want to use that swap. If swap has not been specialized
> >> for the type, we want to fall back on using std::swap
> >> instead.

> >> We can get that with code something like this:

> >> using std::swap;

> >> template <class T>
> >> void sort(/* ... */) {

> >> // ...
> >> // x1 and x2 are T's.
> >> if (x2 < x1) swap(x1, s2);
> >> // ...
> >> }

> > Isn't this the one case where the user is allowed to add to
> > std::? That is, specializing a template in std::? Why not
> > just specialize std::swap<> for your type T, instead? e.g.:

> > class my_expensive_to_swap_class {
> > // ...
> > public:
> > void swap(T&);
> > };

> > template<>
> > std::swap<my_expensive_to_swap_class>(
> > my_expensive_to_swap_class& x,
> > my_expensive_to_swap_class& y)
> > {
> > x.swap(y);
> > }
> > // etc....

> I agree that this would be nice, and that it's even what one
> would choose to do in practice.

> But if there's a language lawyer nearby it may be highly provocative.

> For the standard (probably through some mishap) only allows
> specialization of 'std' namespace classes, not routines,

That's wrong. You're mixing it up with another issue.

> and so, perhaps because that arbitrary restriction appears to
> be very mysterious and subtle to those who think the standard
> must be perfect where it's not obviously self-contradictory,
> the established Perfect Standard Code practice is to Not Do
> That(TM).

The problem is when the user defined type isn't a type, but a
template. Something like:

class MyClass { /* ... */ } ;
namespace std {
void swap( MyClass& a, MyClass& b ) { /* ... */ }
}

is perfectly legal, and approved by the standard. If, on the
other hand, you have something like:

template< typename T >
class MyClass { /* ... */ } ;
namespace std {
template< typename T >
void swap( MyClass< T >& a, MyClass< T >& b )
{ /* ... */ }
}

you don't have an explicit specialization, you've defined a new
function template (which overloads with the existing one). And
that is formally forbidden (but is IMHO still the preferred
solution---since it will, in practice, work).

It's interesting, because I think with a little work, the
wording could be extended to officially allow the above. No one
has done that work, however.

==============================================================================
TOPIC: Can iterator be checked to be at end of vector?
http://groups.google.com/group/comp.lang.c++/t/04f21bec592f548d?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jul 30 2009 2:19 am
From: Richard Herring

In message <m3dcm.35$9g2.16@read4.inet.fi>, Juha Nieminen
<nospam@thanks.invalid> writes
>cornelis van der bent wrote:
>> Is there a meaningful (not technical) reason why an iterator does not
>> have this information?
>
> I suppose the designers of the language wanted iterators to be as
>small as possible

I think one motivation was to allow raw pointers to be iterators, so
that standard algorithms could be applied to arrays. If a pointer "is-a"
(in the duck-typing sense) iterator, that puts quite a constraint on
what an iterator can do.

>and figured that all relevant algorithms could be
>implemented without the iterators needing to know the data container
>which owns the data they are pointing to, as all the algorithms can be
>implemented by making them take iterator pairs (ie. two iterators
>specifying a range of values). In fact, most algorithms wouldn't even
>benefit from the iterators knowing their parent containers, so this data
>would only be useless overhead.

--
Richard Herring

==============================================================================
TOPIC: How to split this string correctly?
http://groups.google.com/group/comp.lang.c++/t/1845370483de2cfa?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Jul 30 2009 2:32 am
From: James Kanze

On Jul 30, 12:26 am, Digital Puer <digital_p...@hotmail.com> wrote:
> On Jul 29, 2:27 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:

> > Digital Puer wrote:
> > > I have the following std::string contents:

> > > "I want to go"--and with emphasis--"right now," he said.

> > > I would like to split this string into six substrings:

> > > "I want to go"
> > > --
> > > and with emphasis
> > > --
> > > "right now,"
> > > he said.

> > Why? What makes those substrings especially interesting?

> They are not interesting because it is a contrived example
> representing a larger class of problem.

But it's not at all evident what. One example is not a
specification.

> > > Is there a way to do this splitting?

Only if you specify exactly what you want to do.

[...]
> > > I am on Linux and can use Boost libraries (I know there is
> > > some regex library, but I have never used it).

> > So don't. You don't need to. The Standard library has
> > enough mechanism for you to do what you need. Start with
> > figuring out the formal algorithm of splitting your string.
> > Then become familiar with the standard string class
> > (std::string), most likely with its member 'find' or
> > 'find_first_of', and its member 'substr'.

> > > I can potentially use another language. Does Python or
> > > Java have support for this?

> > Yes, they do.

> No. That is not what I am looking for. Let me be more
> specific. Is there a way to do the split on a pattern? In my
> example, I would like to split:

> "I want to go"--and with emphasis--"right now," he said.

> I don't really care what the the "--" is, only that it is not
> an alphanumeric charater or a quotation mark. I would like to
> split between go" and -- and retain both as tokens.

> I know that std::string.find() does not allow you to use a
> pattern.

I've got a class (and some subclasses) at my site that can be
used to split up strings fairly effectively---on of the
sub-classes uses regular expressions to define the delimiter
patterns. The classes (my FieldArray) drop the separators, but
it would be fairly easy to modify them so that they kept them,
resulting in something like:
fieldArray = someString ;
// fieldArray[ 0 ] == someString
// odd numbered indexes contain fields
// even numbered indexes contain the separator text
// between the fields.
Alternatively, if you more or less know separators before hand, and
how many fields you will have, you can effectively use
boost::regex directly. I don't know what you're trying to do,
really, so I can't say which, if either, corresponds to your
needs.

== 2 of 3 ==
Date: Thurs, Jul 30 2009 3:18 am
From: Vladimir Jovic

Digital Puer wrote:
> I have the following std::string contents:
>
> "I want to go"--and with emphasis--"right now," he said.
>
>
> I would like to split this string into six substrings:
>
> "I want to go"
> --
> and with emphasis
> --
> "right now,"
> he said.
>
>
> Is there a way to do this splitting? I am on Linux and can use
> Boost libraries (I know there is some regex library, but I have never
> used it).

Either that, or you can use the std::string class and it's find() method

== 3 of 3 ==
Date: Thurs, Jul 30 2009 4:08 am
From: migroslinx

On Jul 29, 10:24 pm, Digital Puer <digital_p...@hotmail.com> wrote:
> I have the following std::string contents:
>
> "I want to go"--and with emphasis--"right now," he said.
>
> I would like to split this string into six substrings:
>
> "I want to go"
> --
> and with emphasis
> --
> "right now,"
> he said.

You could use boost::regex. In example (sorry I don't test it):

boost::match_results<std::string::const_iterator> what;
boost::regex regx( " (([[:alpha:]])|(--)|(\.))*" );
if ( boost::regex_match( sourceStr, what, regx, boost::match_extra ) )
{
// Iterate over what[*] to see patterns matched....
// see boost::regex_match..
}

==============================================================================
TOPIC: Creating a valid XML processing instruction node
http://groups.google.com/group/comp.lang.c++/t/38ff83230c0d7c31?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Jul 30 2009 3:30 am
From: "Hapa"

Hello all,

we are using MSXML.dll version1 (VC++6.0) and we are trying to write into
the processing instruction node some more text to be confirm to our
customers specification.

CComBSTR PITarget = ("xml");
CComBSTR PITarget1 = ("version=\"1.0\" encoding=\"UTF-8\"");
V_I4(&NodeType) = MSXML::NODE_PROCESSING_INSTRUCTION;
CVCXMLDOMNodePtr pProcInstr=NULL;

//case 1:
HRESULT hr = m_pXMLDocumentNode->createNode(NodeType, PITarget, PITarget1,
&pProcInstr)
->>hr == 1???? and pProcInstr=0xcccccc?

//case 2:
HRESULT hr = m_pXMLDocumentNode->createNode(NodeType, PITarget, NULL,
&pProcInstr)
->>hr == 0 and pProcInstr=valid pointer

So the Node could not be created in case PITarget1 points to a string
object!
What is wrong with case 1?

Thanks
hapa.

== 2 of 2 ==
Date: Thurs, Jul 30 2009 5:11 am
From: mzdude

On Jul 30, 6:30 am, "Hapa" <H...@apah.org> wrote:
> Hello all,
>
> we are using MSXML.dll version1 (VC++6.0) and we are trying to write into
> the processing instruction node some more text to be confirm to our
> customers specification.
>
> CComBSTR PITarget = ("xml");
> CComBSTR PITarget1 = ("version=\"1.0\" encoding=\"UTF-8\"");
> V_I4(&NodeType) = MSXML::NODE_PROCESSING_INSTRUCTION;
> CVCXMLDOMNodePtr pProcInstr=NULL;
>
> //case 1:
> HRESULT hr = m_pXMLDocumentNode->createNode(NodeType, PITarget, PITarget1,
> &pProcInstr)
> ->>hr == 1???? and pProcInstr=0xcccccc?
>
> //case 2:
> HRESULT hr = m_pXMLDocumentNode->createNode(NodeType, PITarget, NULL,
> &pProcInstr)
> ->>hr == 0 and pProcInstr=valid pointer
>
> So the Node could not be created in case PITarget1 points to a string
> object!
> What is wrong with case 1?

Please don't cross post. You have already recieved your answer
on microsoft.public.vc.language

http://tinyurl.com/meawv8

==============================================================================
TOPIC: ♬ ♫ ♪Hot sale Fashion Lady Handbags Juicy,Burberry,Gucci,LV,Prada,D&G,
Edhardy,Chanel,Coach, Jimmy-Hoo ♡www.toptradea.com♡
http://groups.google.com/group/comp.lang.c++/t/bada1d4049399f6f?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jul 30 2009 4:54 am
From: "www.toptradea.com Toptradea"

==============================================================================
TOPIC: wholesale Iphone,Nokia,Samsung,Blackberry,etc brand mobile phones, TV
mobiles,Music Mobiles, Touch Mobiles, Dual sim card dual standby Chinese
mobile phones
http://groups.google.com/group/comp.lang.c++/t/94fbc2e2d0700890?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jul 30 2009 4:58 am
From: "www.toptradea.com Toptradea"

wholesale Iphone,Nokia,Samsung,Blackberry,etc brand mobile phones, TV
mobiles,Music Mobiles, Touch Mobiles, Dual sim card dual standby
Chinese mobile phones
Iphone http://www.toptradea.com/category.php?id=435
Nokia http://www.toptradea.com/category.php?id=436
Blackberry http://www.toptradea.com/category.php?id=437
HTC http://www.toptradea.com/category.php?id=438
Samsung http://www.toptradea.com/category.php?id=440
Motorola http://www.toptradea.com/category.php?id=439
Chinese mobile phones http://www.toptradea.com/category.php?id=442

Iphone http://www.toptradea.com/category.php?id=435
Nokia http://www.toptradea.com/category.php?id=436
Blackberry http://www.toptradea.com/category.php?id=437
HTC http://www.toptradea.com/category.php?id=438
Samsung http://www.toptradea.com/category.php?id=440
Motorola http://www.toptradea.com/category.php?id=439
Chinese mobile phones http://www.toptradea.com/category.php?id=442

==============================================================================
TOPIC: ♂◆♀ Wholesale Fashion Jeans Prada,RMC,G-star,Cavalli,Iceberg,Levis,
Coogi,BBC,Laguna,True Religion Jeans www.toptradea.com
http://groups.google.com/group/comp.lang.c++/t/b3966380749ed631?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jul 30 2009 5:02 am
From: "www.toptradea.com Toptradea"

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

== 1 of 1 ==
Date: Thurs, Jul 30 2009 5:08 am
From: Andrew Tomazos

On Jul 30, 10:57 am, James Kanze <james.ka...@gmail.com> wrote:
> And that there is no 100x factor between the best and the worst.

Actually the 100x figure is between the best and the average. The
worst programmers actually do damage to a project, so their
productivity is negative.
-Andrew.

==============================================================================
TOPIC: Yellowfin 4.1 Released with iPhone BI application
http://groups.google.com/group/comp.lang.c++/t/090b9ac57310c936?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jul 30 2009 5:11 am
From: JTP PR

Yellowfin, leading web-based Business Intelligence software providers,
today announced the release of Yellowfin 4.1, the next generation of
the Yellowfin product suite.

With more than 80 new features, Yellowfin helps organisations see and
understand their data better than ever. New dashboard and
visualization capabilities, along with federated queries and a host of
improvements to spatial BI, make 4.1 ideal for rapid BI deployments.
Yellowfin 4.1 is available for download at http://www.yellowfinbi.com

Glen Rabie, CEO of Yellowfin says, "Yellowfin continues to strive to
make business intelligence easy. 4.1 is another step in that
journey. We have made a significant amount of usability and
functional enhancements that make Yellowfin the leader in web based BI
software."

Yellowfin now offers unparalleled capabilities to create analytic
dashboards and interactive visualizations that enable people anywhere
in an organization to track and explore their most important metrics.
Dashboards are now more intuitive, while at the same time providing a
greater level of analytic capability.

"The recent changes to our dashboards are being driven by an increased
demand for highly interactive dashboards that allow users to explore
their data intuitively. The days of static dashboards are long gone,
users expect to be able to slice and dice and drill into data
effortlessly. 4.1 sets the benchmark in terms of flexibility and
usability for creating different styles of tabs – but best of all they
are fun to use and quickly deliver insight to the user," says Glen
Rabie.

The growing trend of Mobile BI is supported through the release of
both a native iPhone application, and a generic mobile interface, that
provide full featured delivery of both dashboards and reports to a
mobile workforce.

Unlike most BI applications for the iPhone that just post static
reports on a mobile screen, which may be marginally helpful but
creates a tremendously frustrating user experience, Yellowfin for the
iPhone provides the opportunity to interact with the data. This
allows mobile users to access to the specific answers they need.

Federated Queries will enable users to query more than one data source
at a time and combine the results in memory into a single report and /
or table. This enhancement allows you to treat all your data sources
as one virtual database and access them as a single query – enabling
you to focus on building reports, not joining data sources.

The latest release delivers a wide range of improvements to Spatial BI
including: GIS layering and enabling Web Map Service (WMS) layers on
GIS reports. Multiple condition ranges enable users to divide a range
of results into several smaller subsets and display them clearly on
the one chart.

eSite is one of the first of Yellowfin's partners to benefit from the
enhanced GIS capabilities. "In my career I've used 12 or 13 different
database/reporting systems…and I have to say that the elegance and
practicality of the Yellowfin 4.1 design, and being totally web based,
is just awesome compared to those systems." Says Larry Manire, CTO of
eSite.

More than 80 New Features

Yellowfin 4.1 has over 80 new features. Additional capabilities
include:
• Additional charting and visualisations - Z charts, funnel charts and
more.
• Improved Report List manager
• Filter Parameter caching for enhanced usability
• Additional administrative and configuration options
• Additional clustering support for improved scalability

About Yellowfin

www.yellowfin.bi

Yellowfin is passionate about making Business Intelligence easy.
Recently recognised among 25 rising companies that CIO's must know
about, Yellowfin is a leading web-based BI solution can be easily
integrated into any third-party application or delivered as a stand-
alone enterprise platform. Yellowfin is an innovative and flexible
solution for reporting and analytics, providing a full range of data
access, presentation and information delivery capabilities.

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

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

Thursday, July 30, 2009

comp.lang.c++ - 26 new messages in 13 topics - digest

No comments:

Blog Archive

About Me