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:

* template error - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/1d7d6b77e8753579?hl=en
* How to split this string correctly? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/1845370483de2cfa?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
* Clojure vs Java speed - 10 messages, 6 authors
http://groups.google.com/group/comp.lang.c++/t/40783f7f814400c9?hl=en
* strcpy vs memcpy - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/71a5945deead500c?hl=en
* ☆◆☆Wholesale Blackberry 9000,8100,8700,7290,8310 Nokia N97,N96,N95,E71,E66,
8800arte,5800,8600 }{ Our policy: order 1-3pce brand mobile with a free polo
Tshirt, order more than 5 pcs brand mobiles with a free nike sneaker (time
limited) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/7065aad5bf24e326?hl=en
* New release of the Dynace OO extension to C - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/ee8689156295093c?hl=en
* ♡◆→Sneaker of Nike,Jordan,Gucci,Adidas,Puma,EdhardyShox,Max,Free,Rift%Polo,
Lacoste,BBC,Gucci,Armani,LV,Christina Audigier Tshirt and Jeans - 1 messages,
1 author
http://groups.google.com/group/comp.lang.c++/t/c35f253fd93fb682?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/2b19dd7153fecb15?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/9f16337444dd9273?hl=en
* ◆田◆Wholesale Nokia ,Iphone, Samsung, Blackberry, Sony, Motorola,etc brand
mobiles "www.toptradea.com" ◆ Our policy: order 1-3pce brand mobile with a
free polo Tshirt, order more than 5 pcs brand mobiles with a free nike sneaker
(time limited) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/f0f5ce594281f19d?hl=en

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

== 1 of 4 ==
Date: Wed, Jul 29 2009 3:39 pm
From: Jerry Coffin

In article <R21cm.128$TB5.88@read4.inet.fi>, nospam@thanks.invalid
says...

[ ... ]

> How about not using the 'using' directive at all? My code has
> become much more readable after I stopped using it. Don't believe
> dissenting opinions, they are wrong. The code *does* become more
> readable.

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);
// ...
}

The trick here is simple: if we specify std::swap, then that's what
will be used, even if T provides its own swap. On the other hand, if
we try to specify T's namespace, the code won't compile unless T
actually _does_ provide its own swap (and we don't want that
restriction -- just for example, it would then fail for all built-in
types).

The cure is pretty simple, as shown above. If there's a 'swap' in T's
namespace, argument dependent lookup will find it, and that's what
will get used. Otherwise, because of the using declaration, std::swap
will be found instead.

In the case above, I've used a using declaration, but if (for
example) we were using quite a few different things like this, a
using directive would become more convenient. Just for example, the
code above uses the less-than operator, but for genericity it should
really use a comparison function. Again, std::less<T> might be the
appropriate version (it would be equivalent to what's above) but
again, if T provides its own less(), we'd prefer to use that. In this
case there's not nearly as big a problem though, simply because
std::less<T> will use T's operator< (so all that's usually needed is
to supply operator< if ordering is at all appropriate).

--
Later,
Jerry.

== 2 of 4 ==
Date: Wed, Jul 29 2009 11:11 pm
From: 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....

== 3 of 4 ==
Date: Wed, Jul 29 2009 11:32 pm
From: "Alf P. Steinbach"

* 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, 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).

Cheers & hth.,

- Alf

== 4 of 4 ==
Date: Wed, Jul 29 2009 11:53 pm
From: 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? Can you quote the standard on that?

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

Cheers!
SG

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

== 1 of 2 ==
Date: Wed, Jul 29 2009 3:52 pm
From: Jonathan Lee

On Jul 29, 6:26 pm, Digital Puer <digital_p...@hotmail.com> wrote:
> That is not what I am looking for. Let me be
> more specific. Is there a way to do the split
> on a pattern?

Not in the standard libs. You could code your own easily enough
using isalpha(), isdigit(), and ispunct(), I expect. Just walk
along the string and use substr() whenever the grouping changes.
Use a std::vector to build up your list.

Googling "C++ tokenizer" returns a few examples. With some minor
modifications you would have what you want.

If you need more advanced pattern matching I would use an
already made regex library. Boost is always a good place to
start for such things.

--Jonathan

== 2 of 2 ==
Date: Wed, Jul 29 2009 11:14 pm
From: red floyd

Digital Puer wrote:
> On Jul 29, 2:27 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
>> Digital Puer wrote:
>>>[contrived example redacted]
>> Why? What makes those substrings especially interesting?
> They are not interesting because it is a contrived
> example representing a larger class of problem.

And such a contrived example reeks of "Do My Homework For Me".

>>> Is there a way to do this splitting?
>> Yes. The field is called "programming", the area is "string
>> manipulation". You figure out the algorithm and then you write that
>> algorithm in terms of the language of your choice.
>>
>> For example, you want to concatenate "Do" and "my homework" with a space
>> between them. Suppose you have two strings:
>>
>> std::string do("Do");
>> std::string my_homework("my homework");
>>
>> the concatenation can be done using operator + :
>>
>> std::string result = do + ' ' + my_homework;
>
>
> Good job. That is string concatentation, not splitting.
> Did you learn software engineering through a
> Cracker Jack box? Congratulations.

Victor is well aware that it was concatenation.
Did you even read his reply? In particular the strings
he used?

==============================================================================
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: Wed, Jul 29 2009 5:56 pm
From: Jerry Coffin

In article <5477e597-b39d-440b-b1d1-
c70dcbfe457f@d4g2000yqa.googlegroups.com>, james.kanze@gmail.com
says...

[ ... ]

> I know that. I was using a Unix-like tool kit under MS-DOS in
> the late 1908's. But I'm hardly a typical Windows user; I was
> wondering what typical Windows developers use.

That's a tougher question -- I'm honestly not sure about typical
developers. Personally, I use a rather hodgepodge collection of
"stuff". In fact, it was only quite recently (with a switch to 64-bit
Windows) that I quit using some utilities that were written for MS-
DOS...

[ ... ]

> Yes. I mentioned CygWin more as a placeholder for any Unix-like
> tool kit, rather than with the idea of CygWin, and only CygWin.
> I'm aware of at least three others: UWin, MSys and MKS (the
> latter commercial, and rather expensive---although it wasn't too
> expensive in the MS-DOS days), and I don't doubt that there are
> others. (I'm still looking for one which integrates well,
> however. Most of them seem to go out of their way to make it
> difficult to use tools other than those in the toolset. And if
> I'm running Windows, and not Linux, on a machine, it's because I
> want to use the Windows tools when appropriate.)

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.

--
Later,
Jerry.

==============================================================================
TOPIC: Clojure vs Java speed
http://groups.google.com/group/comp.lang.c++/t/40783f7f814400c9?hl=en
==============================================================================

== 1 of 10 ==
Date: Wed, Jul 29 2009 7:06 pm
From: Arne Vajhøj

Oxide Scrubber wrote:
> fft1976 wrote:
>> Is this what Clojure fanboys must resort to when they lose an
>> argument?
>
> I wouldn't know, since that's never happened to me.

Thanks for that very informative comment !

:-)

Arne

== 2 of 10 ==
Date: Wed, Jul 29 2009 7:11 pm
From: tmoran@acm.org

> Ada is also 2x slower,
Where'd you get that idea?
When comparing to C, you should remember to turn off all run-time
checking, but even with it all on normal code shouldn't have more than a
10-15% slowdown. Note that Gnat uses the same code generator as Gnu C, so
one would expect the same semantics to generate the same code and run at
the same speed. And if you are calling a library of course they would be
the same. Note also that it's very easy, and safer, in Ada to use
multiple cores, on those occasions when that would help.

== 3 of 10 ==
Date: Wed, Jul 29 2009 7:11 pm
From: fft1976

On Jul 29, 12:24 pm, Jon Harrop <j...@ffconsultancy.com> wrote:

> > This is fanboy fantasy, not reality.
>
> Yes. Clojure has some nice features but its most serious deficiencies are
> inherited from the JVM and there is nothing Clojure can do about it, e.g.
> value types and TCO.

Not as far as speed is concerned, in practice. If you give up 1.5x
speed by going from C++ to Java, and 5-10 by going from Java to
Clojure [1], than the latter is much more relevant.

I actually think 1.5x is a good trade for memory safety, as I stated.
It's beyond me why this "jharriman@hatlop.de" fella decided to argue
about it, when he obviously knows nothing about number crunching. What
a nut case.

[1] http://groups.google.com/group/clojure/msg/92b33476c0507478

== 4 of 10 ==
Date: Wed, Jul 29 2009 7:19 pm
From: Lew

fft1976 wrote:
> I actually think 1.5x is a good trade for memory safety, as I stated.
> It's beyond me why this "jharriman@hatlop.de" fella decided to argue
> about it, when he obviously knows nothing about number crunching. What
> a nut case.

Flame war, flame war, flame war. Go on to comp.programming and have a great time.

--
Lew

== 5 of 10 ==
Date: Wed, Jul 29 2009 7:34 pm
From: fft1976

On Jul 29, 7:11 pm, tmo...@acm.org wrote:
> > Ada is also 2x slower,
>
> Where'd you get that idea?

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gnat&box=1

Of the languages I commented on, I actually know Ada the least, so
take it up with the shootout authors (no bitching to me, please). I
actually think the Ada was run in the shootout with all safety OFF.

== 6 of 10 ==
Date: Wed, Jul 29 2009 7:48 pm
From: Paul Rubin

fft1976 <fft1976@gmail.com> writes:
> > Where'd you get that idea?
> http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gnat&box=1

Given that Ada is such a verbose language, the generally smaller
source sizes of the Ada programs suggests that they weren't optimized
very carefully. I know that some C, Java, and functional language
users treat the shootouts fairly competitively and tune their code
carefully, but I don't know if the Ada users are the same way. Ada
is unfortunately kind of a niche language these days.

== 7 of 10 ==
Date: Wed, Jul 29 2009 8:04 pm
From: fft1976

On Jul 28, 3:01 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> fft1976 wrote:
> > Ada is also 2x slower [than C], but less suitable for your purposes (verbose,
> > less memory safe than OCaml, free compilers produce GPL-only code)
>
> Correction: the Ada run-time library from GCC (from the Free Software
> Foundation) is licensed under GPLv3 with run-time linking exception,
> so does not cause the executables to be under GPL. But that wasn't
> the OP's concern, anyway.

I've read somewhere that the quality of those FSF Ada tools/libraries
is not as good (if it were, what would keep the commercial vendors in
business?)

== 8 of 10 ==
Date: Wed, Jul 29 2009 8:40 pm
From: fft1976

On Jul 29, 7:48 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> fft1976 <fft1...@gmail.com> writes:
> > > Where'd you get that idea?
> >http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=gna...
>
> Given that Ada is such a verbose language, the generally smaller
> source sizes of the Ada programs suggests that they weren't optimized
> very carefully. I know that some C, Java, and functional language
> users treat the shootouts fairly competitively and tune their code
> carefully, but I don't know if the Ada users are the same way. Ada
> is unfortunately kind of a niche language these days.

This is a hypotheses you are entertaining, right? Or did you notice
anything "suboptimal" in the Ada code?

== 9 of 10 ==
Date: Wed, Jul 29 2009 8:53 pm
From: Paul Rubin

fft1976 <fft1976@gmail.com> writes:
> This is a hypotheses you are entertaining, right?

Yes.

> Or did you notice anything "suboptimal" in the Ada code?

I haven't looked at the code. I do notice from the shootout that in
some examples, the Ada code is significantly smaller both code size
and memory consumption than the C++ code, but the Ada code is slower.
Since Ada and C/C++ have pretty similar semantics, it suggests there
was a time/memory tradeoff that was resolved in different ways between
the programmers.

== 10 of 10 ==
Date: Wed, Jul 29 2009 8:58 pm
From: Stephen Horne

On Wed, 29 Jul 2009 08:19:07 -0700 (PDT), Andrea Taverna
<a.tavs@hotmail.it> wrote:

>> Ada is also 2x slower,
>Are you sure?

I'm not going to say yes or no, but it isn't unreasonable.

Ada compilers are required to do range checking on array bounds,
integer types etc, along with other checks that C simply doesn't
bother with. A lot of that is handled using static analysis, but where
static checks can't be sure, run-time checks are done instead.

>I have to say that translating my C graph library with Ada, leaving
>aside memory management, lead to shorter and readable code, something
>I've been dreaming of for the past 3 years

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.

If you want object oriented, Ada has OO features since Ada 95 - but
they are not what a C++/Java/whatever developer would expect. IIRC,
the original designer of the Ada language (back when it was called
Green) resigned over language design decisions for the Ada 95
standardisation.

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.

That said, I have a DSL I have written that supports multiple
dispatch, targetting C++ as an output language, which is based on a
program called treecc that does very similar. My DSL translates
'nodes' (it is primarily aimed at AST handling) to C++ structs with
inheritance, but with a minimal set of methods. Multiple dispatch
operations are translated to C++ functions with dispatch resolution
code built in so that, as in Ada, you don't really have traditional
"methods".

IIRC one of the OOP gurus - Bertrand Meyer? - in the 90s described
classes as a combination of two concepts - records/structs (WRT data
members) and modules/packages (WRT method ownership). An additional
issue, however, of method "ownership" is that one parameter (in C++,
"this") is treated as special. Only this parameter participates in
run-time binding resolution. In fact, we often forget that it *is* a
parameter.

With multiple dispatch, the idea that classes "own" methods makes less
sense. Any or all parameters may influence the run-time binding
resolution. It still makes sense for a method to be placed in a module
for the usual modularity and data hiding reasons, but the logic for
that module being the class itself is much more tenuous. In
particular, despite the old OOP theory claims, classes very often need
to work in closely-coupled subsystems. Having classes and functions
wrapped in a separate subsystem-level module, so that the class doing
module/data hiding duties, makes a lot of sense.

BTW - Multiple dispatch isn't just about ASTs. For example, using
multiple dispatch (and a sufficiently rich specification of what cases
each implementation of a function covers), the visitor pattern is
completely unnecessary.

Multiple dispatch is certainly more complex than single dispatch, but
remember that it isn't wasted effort. Using multiple dispatch is
simply a way of implementing a decision that would otherwise have to
be implemented manually, just like single dispatch but more so. Some
decisions are easier to handle using multiple dispatch (exploiting the
fact that the compiler is responsible for the low-level
decision-making code) whereas others are easier to handle manually. In
efficiency terms, if the compiler is doing a good job, there should be
little or no difference.

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. Presumably, Ada has
to delay the dispatch decision code generation to what is essentially
link-time, 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.

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

== 1 of 2 ==
Date: Wed, Jul 29 2009 7:11 pm
From: Thomas Matthews

Pallav singh wrote:
> when we should use strcpy( ) and when memcpy( ) ? is it w.r.t. to
> Data Type
>
> Thanks
> Pallav

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.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

== 2 of 2 ==
Date: Wed, Jul 29 2009 8:09 pm
From: Jerry Coffin

In article <4A710164.1070709@matthews.cox.net>,
Thomas_Really_Hates_Spam@matthews.cox.net says...
>
> Pallav singh wrote:
> > when we should use strcpy( ) and when memcpy( ) ? is it w.r.t. to
> > Data Type
> >
> > Thanks
> > Pallav
>
> 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).

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.

--
Later,
Jerry.

==============================================================================
TOPIC: ☆◆☆Wholesale Blackberry 9000,8100,8700,7290,8310 Nokia N97,N96,N95,E71,
E66,8800arte,5800,8600 }{ Our policy: order 1-3pce brand mobile with a free
polo Tshirt, order more than 5 pcs brand mobiles with a free nike sneaker (
time limited)
http://groups.google.com/group/comp.lang.c++/t/7065aad5bf24e326?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jul 29 2009 8:22 pm
From: "www.toptradea.com Toptradea"

☆◆☆Wholesale Blackberry http://www.toptradea.com/category.php?id=437
9000,8100,8700,7290,8310 Nokia http://www.toptradea.com/category.php?id=436
N97,N96,N95,E71,E66,8800arte,5800,8600 }{ Our policy: order 1-3pce
brand mobile with a free polo Tshirt, order more than 5 pcs brand
mobiles with a free nike sneaker (time limited)

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

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

== 1 of 1 ==
Date: Wed, Jul 29 2009 8:22 pm
From: Blake McBride

Juha Nieminen wrote:
> BartC wrote:
>> I admit I know nothing about vtables and whatever, but why would it be
>> necessary to store any extra data in each /instance/ of the class?
>
> The problem with languages like Objective-C (and, I assume, Dynace) is
> that every object must be allocated dynamically (with whatever function
> the language offers for this purpose, but which is basically completely
> equivalent to malloc() + initialization), and consequently each object
> has at least one pointer pointing to it.
>
> Allocating an object dynamically always has some space overhead to it
> for the simple reason that the memory allocator used by the compiler has
> to store some ancillary data on each allocated block of memory. For
> example the C-lib memory allocator in Linux (in a 32-bit system)
> requires 4-12 bytes of ancillary data per allocated block of memory (the
> minimum allocation size is 16 bytes, and everything bigger than that is
> aligned to an 8-byte boundary, with the size of the allocated block
> being the requested size + 4 bytes).

Objects are allocated in blocks and chopped up so there is virtually no
malloc overhead. For example, if an object without malloc overhead
takes up 32 bytes, when one object is allocated I might allocate 320
bytes (enough for 10). I'd then return one. The next time you new'ed
one up I'd just cut another piece off. The malloc overhead is once for
the all 10 (and of course I could have allocated 100, etc.). Freein up
an object amounts to just linking it back to the chunk so it is very
fast. Allocations are usually simple unlinks and free's amount to
one-line re-links.

>
> If the object has a vtable pointer in it (in the cases where the
> language needs it), that adds the size of one pointer to the object size
> behind the scenes.

vtables are associated with the class not the instances. The number of
instances does not affect the vtable size at all.

>
> In this particular example (ie. the "Pixel" class consisting of 4
> bytes) the object itself, when allocated dynamically, would require 16
> bytes of memory in a (32-bit) Linux system, plus the pointer used to
> handle it. Thus each 'Pixel' object requires 20 bytes of memory. And
> this assuming the vtable pointer is not needed. If that is needed by the
> language, then each object requires 24 bytes of memory.
>
> In C++, in the optimal case (as the one I gave as example, ie. no
> dynamic binding needed, a std::vector<Pixel> as data container), each
> object requires only 4 bytes of memory. (And this is so even in 64-bit
> systems.)
>
> Of course lesser memory usage is not the only advantage: Allocating 10
> million objects dynamically, one at a time, is very expensive, even when
> using some optimized memory allocator. C++ classes allow allocating all
> the 10 million objects as one single memory block (which is what the
> std::vector in the example does), in other words, there is only one
> allocation rather than 10 million. This is a HUGE time saver.

This happens even if you allocate one too - not just when you allocate
an array of them.

Blake McBride

==============================================================================
TOPIC: ♡◆→Sneaker of Nike,Jordan,Gucci,Adidas,Puma,EdhardyShox,Max,Free,Rift%
Polo,Lacoste,BBC,Gucci,Armani,LV,Christina Audigier Tshirt and Jeans
http://groups.google.com/group/comp.lang.c++/t/c35f253fd93fb682?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jul 29 2009 8:25 pm
From: "www.toptradea.com Toptradea"

==============================================================================
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/2b19dd7153fecb15?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jul 29 2009 8:27 pm
From: "www.toptradea.com Toptradea"

==============================================================================
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/9f16337444dd9273?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jul 29 2009 8:29 pm
From: "www.toptradea.com Toptradea"

==============================================================================
TOPIC: ◆田◆Wholesale Nokia ,Iphone, Samsung, Blackberry, Sony, Motorola,etc
brand mobiles "www.toptradea.com" ◆ Our policy: order 1-3pce brand mobile with
a free polo Tshirt, order more than 5 pcs brand mobiles with a free nike
sneaker (time limited)
http://groups.google.com/group/comp.lang.c++/t/f0f5ce594281f19d?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jul 29 2009 8:31 pm
From: "www.toptradea.com Toptradea"

◆田◆Wholesale Nokia ,Iphone, Samsung, Blackberry, Sony, Motorola,etc
brand mobiles "www.toptradea.com" ◆ Our policy: order 1-3pce brand
mobile with a free polo Tshirt, order more than 5 pcs brand mobiles
with a free nike sneaker (time limited)
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

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

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

Wednesday, July 29, 2009

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

No comments:

Blog Archive

About Me