comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Working with Large Values (double) - 12 messages, 9 authors
http://groups.google.com/group/comp.lang.c++/t/e42843c9cdf13724?hl=en
* How to download Microsoft Visuail c++ software - 8 messages, 6 authors
http://groups.google.com/group/comp.lang.c++/t/1aa05d6584f1e293?hl=en
* OT: Problem building libc++ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/177ee9b847d7540f?hl=en
* EVOLUTIONISTS DESTROYED IN 5 SECONDS - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/e18502459ce73309?hl=en
* calling placement new for elements of a deque - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/a896b7c648e29553?hl=en
==============================================================================
TOPIC: Working with Large Values (double)
http://groups.google.com/group/comp.lang.c++/t/e42843c9cdf13724?hl=en
==============================================================================
== 1 of 12 ==
Date: Tues, Feb 25 2014 4:46 pm
From: Robert Wessel
On Wed, 26 Feb 2014 09:39:11 +1300, Ian Collins <ian-news@hotmail.com>
wrote:
>Scott Lurndal wrote:
>> Gerhard Fiedler <gelists@gmail.com> writes:
>>
>>> Try letting the compiler check the argument types when using a variable
>>> as formatting string.
>>
>> I've never seen a case where it makes sense to use a variable as a
>> formatting string[*]. Can you describe a case where it does make sense
>> and it doesn't cause a potential security problem?
>
>Simple internationalisation. I've worked on embedded projects where we
>used different sets of format strings for different languages. No
>security risks there.
Unfortunately the strictly positional nature of the input parameters
in the printf functions has always led us to use our own replacement.
== 2 of 12 ==
Date: Tues, Feb 25 2014 4:50 pm
From: Ian Collins
David Brown wrote:
> On 25/02/14 21:39, Ian Collins wrote:
>> Scott Lurndal wrote:
>>> Gerhard Fiedler <gelists@gmail.com> writes:
>>>
>>>> Try letting the compiler check the argument types when using a variable
>>>> as formatting string.
>>>
>>> I've never seen a case where it makes sense to use a variable as a
>>> formatting string[*]. Can you describe a case where it does make sense
>>> and it doesn't cause a potential security problem?
>>
>> Simple internationalisation. I've worked on embedded projects where we
>> used different sets of format strings for different languages. No
>> security risks there.
>
> That would be my thought. You might have something like this:
>
> typedef enum { formatUK, formatUS } dateFormatChoices;
> static const char dateFormatStrings[] = {
> "%1$02d/%2$02d/%3$04d", "%2$02d/%1$02d/%3$04d"
> }
> void printDate(dateFormatChoices i, int day, int month, int year) {
> printf(dateFormatStrings[i], day, month, year);
> }
>
> (That particular example relies on posix printf with parameters - if you
> can't re-arrange parameter order like that, variable format strings are,
> I think, significantly less useful.)
The case I was thinking of was a monitoring device that displayed the
name of a unit (such as "Battery Time Remaining") or menu items in the
language selected by the user. Nothing fancy.
--
Ian Collins
== 3 of 12 ==
Date: Tues, Feb 25 2014 5:09 pm
From: Robert Wessel
On Tue, 25 Feb 2014 14:41:41 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:
>Robert Wessel <robertwessel2@yahoo.com> writes:
>>On Mon, 24 Feb 2014 22:05:44 +0100, jacob navia <jacob@spamsink.net>
>>wrote:
>>
>>>Le 24/02/2014 21:40, Victor Bazarov a écrit :
>>>> What Wouter wrote was to show you that to make a mistake using the
>>>> "preferred" form is just as easy as with the other form, and it's just
>>>> as _undiagnosable_.
>>>Yes.
>>>
>>>There is no way to specify a list of arguments of the same type in C (or
>>>in C++ for that matter).
>>>
>>>So, that could crash.
>>>
>>>Contrary to what many people here believe, I do not think that a trivial
>>>error like that is very difficult to solve/fix/find.
>>>
>>>Yes, it is a PITA, as all bugs, but not as bad as MANY other bugs that
>>>can happen also with the overloaded functions. For instance typing a
>>>wrong variable name in a function call, etc. The compiler can warn you
>>>if the type is wrong, but if it is right that is also
>>>
>>>_undiagnosable_
>>>
>>>Let's face it, the perfect compiler/language combination doesn't exist.
>>>
>>>My point was that operator overloading is NOT the best paradigm for
>>>output formatting, to come back to the original discussion. The C
>>>paradigm in *that* case is (for the time being) much better.
>>>
>>>C gives you a mini-language and a fast run time interpreter for it. This
>>>is a very fast and flexible solution that can be used in the C++
>>>context. It wouldn't be very hard to figure out a standard way of
>>>expanding the mini-language with wild cards that would give it the
>>>possibility of formatting arrays/ new types/ etc.
>>>
>>>But no, C++ got driven away from sanity by an initial WRONG DESIGN
>>>DECISION that persists to this day.
>>>
>>>That's all I am saying.
>>>
>>>Printf extensions have been proposed and implemented. The trio printf
>>>proposed array formatting for instance. Having implemented printf in my
>>>compiler system I find the whole idea simple yet incredibly powerful.
>>>
>>>Like the C language. A simple yet powerful language.
>>>
>>>It would be more productive for everyone if C++recognized that design
>>>mistake and would work towards a better implementation of output
>>>formatting (maybe) using that simple idea:
>>>
>>>A simple and small formatting LANGUAGE and an associated run time
>>>interpreter.
>>
>>
>>I don't think anyone really thinks C++ streams are pretty. IMO,
>>they're darn ugly. And overloading the shift operators is at least a
>>little perverse. OTOH, the shift operators as such are fairly rare in
>>code, so while a new operator might have been a bit better, it's
>>really not that big a deal.
>>
>>OTOH, streams *are* type safe and extensible (please don't bother
>>reiterating your argument that many compilers add partial type safety
>>to the printf functions, I've heard you, and, IMO, the argument is
>>insufficient, but we're unlikely to convince each other).
>
>I think one might argue that type-safety is a red-herring in the
>snprintf case, but YMMV.
Just don't use %n...
But seriously, while on (many) systems messing up the match between
the format string and the parameters results in nothing worse than
garbage output (memory overflows on sprintf and the like excepted),
that's still a place where type safety is useful in allowing the
compiler to diagnose that problem.
== 4 of 12 ==
Date: Wed, Feb 26 2014 1:09 am
From: David Brown
On 26/02/14 01:50, Ian Collins wrote:
> David Brown wrote:
>> On 25/02/14 21:39, Ian Collins wrote:
>>> Scott Lurndal wrote:
>>>> Gerhard Fiedler <gelists@gmail.com> writes:
>>>>
>>>>> Try letting the compiler check the argument types when using a
>>>>> variable
>>>>> as formatting string.
>>>>
>>>> I've never seen a case where it makes sense to use a variable as a
>>>> formatting string[*]. Can you describe a case where it does make
>>>> sense
>>>> and it doesn't cause a potential security problem?
>>>
>>> Simple internationalisation. I've worked on embedded projects where we
>>> used different sets of format strings for different languages. No
>>> security risks there.
>>
>> That would be my thought. You might have something like this:
>>
>> typedef enum { formatUK, formatUS } dateFormatChoices;
>> static const char dateFormatStrings[] = {
>> "%1$02d/%2$02d/%3$04d", "%2$02d/%1$02d/%3$04d"
>> }
>> void printDate(dateFormatChoices i, int day, int month, int year) {
>> printf(dateFormatStrings[i], day, month, year);
>> }
>>
>> (That particular example relies on posix printf with parameters - if you
>> can't re-arrange parameter order like that, variable format strings are,
>> I think, significantly less useful.)
>
> The case I was thinking of was a monitoring device that displayed the
> name of a unit (such as "Battery Time Remaining") or menu items in the
> language selected by the user. Nothing fancy.
>
In cases like that (if I am reading you correctly), for printing a
variable char* p
printf(p);
you could use
printf("%s", p);
That version is arguably safer (it is /definitely/ safer if your strings
come from elsewhere, but I don't expect that applies in your case), and
probably runs faster.
== 5 of 12 ==
Date: Wed, Feb 26 2014 1:10 am
From: David Brown
On 26/02/14 01:46, Robert Wessel wrote:
> On Wed, 26 Feb 2014 09:39:11 +1300, Ian Collins <ian-news@hotmail.com>
> wrote:
>
>> Scott Lurndal wrote:
>>> Gerhard Fiedler <gelists@gmail.com> writes:
>>>
>>>> Try letting the compiler check the argument types when using a variable
>>>> as formatting string.
>>>
>>> I've never seen a case where it makes sense to use a variable as a
>>> formatting string[*]. Can you describe a case where it does make sense
>>> and it doesn't cause a potential security problem?
>>
>> Simple internationalisation. I've worked on embedded projects where we
>> used different sets of format strings for different languages. No
>> security risks there.
>
>
> Unfortunately the strictly positional nature of the input parameters
> in the printf functions has always led us to use our own replacement.
>
If you've got a posix extended printf, then the input parameters don't
have to be strictly positional (see my example).
== 6 of 12 ==
Date: Wed, Feb 26 2014 4:00 am
From: Gerhard Fiedler
Scott Lurndal wrote:
> Gerhard Fiedler <gelists@gmail.com> writes:
>
>> Try letting the compiler check the argument types when using a
>> variable as formatting string.
>
> I've never seen a case where it makes sense to use a variable as a
> formatting string[*]. Can you describe a case where it does make
> sense and it doesn't cause a potential security problem?
Not sure what you call a security problem, but user-selectable output
languages are a pretty common requirement.
Gerhard
== 7 of 12 ==
Date: Wed, Feb 26 2014 6:46 am
From: scott@slp53.sl.home (Scott Lurndal)
Gerhard Fiedler <gelists@gmail.com> writes:
>Scott Lurndal wrote:
>
>> Gerhard Fiedler <gelists@gmail.com> writes:
>>
>>> Try letting the compiler check the argument types when using a
>>> variable as formatting string.
>>
>> I've never seen a case where it makes sense to use a variable as a
>> formatting string[*]. Can you describe a case where it does make
>> sense and it doesn't cause a potential security problem?
>
>Not sure what you call a security problem, but user-selectable output
>languages are a pretty common requirement.
I've seen poorly written software where user-input is provided as the
format string. That's a security problem waiting to happen.
I81n is a legitimate use, in which case the compiler cannot verify
the correctness of the format string with respect to the arguments.
== 8 of 12 ==
Date: Wed, Feb 26 2014 11:51 am
From: Seungbeom Kim
On 2014-02-24 06:30, jacob navia wrote:
> Because there is no ADDITION being done when a and b are STRINGS but a
> concatenation of two strings, what is *completely different*. If a and
> b are strings we have
>
> a+b != b+a
>
> what goes against all the mathematical basis of addition as normal
> people use that word.
>
> That is why string "addition" is an ABUSE of overloading.
Mathematical operators do not define the abuse of C++ operator
overloading. If they did,
* '=' as assignment (instead of equality),
* '<<' as left-shift (instead of 'much less than'),
* '%' as remainder (instead of percent), or
* '|' as bitwise OR (instead of 'divides'), etc.
would all be an abuse as well.
> In the same vein, shifting left an object to print it just because the
> opeartor << looks like the head of a left arrow or suggests "put into"
> is NONSENSE and an abuse of the overloading concept.
'<<' is defined both as a left-shift operator and a stream insert
operator in the same document that defines C++. The fact that << is
used for one doesn't automatically make the other usage an abuse.
--
Seungbeom Kim
== 9 of 12 ==
Date: Wed, Feb 26 2014 2:30 pm
From: Jorgen Grahn
On Mon, 2014-02-24, Wouter van Ooijen wrote:
> jacob navia schreef op 24-Feb-14 3:34 PM:
>> Besides, if you want to support SEVERAL print functions for instance for
>> formatting a customer with name, age or name, SS number, or just
>> initials, etc you will need anyway several print functions in C++ also,
>> if I remember correctly isn't it?
>
> In true C++: if that is what you want it is cetainly possible, just like
> you can have print_xxx functions if you want to.
>
> I think I would prefer to reserve operator<<(person) for (debug)
> printing of ALL data in person, and have separate getters for the items
> that you might want to print, like
>
> std::cout
> << std::setw( 30 ) << person.name()
> << " lives at "
> << std::setw( 60 ) << person.adress();
>
> This keeps *what* you want to print separate from *how* you want to
> print it.
I think what jacob navia is after would be better done as a bunch of
classes which only know how to format a Customer, each in its unique
fashion:
std::cout << ForMailingLabel(some_customer);
std::cout << ForGreetingMessage(some_customer);
std::cout << ForTheNSA(some_customer);
(Sorry about the bad naming; I don't deal with customers so I don't
know what you want to print or why.)
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 10 of 12 ==
Date: Wed, Feb 26 2014 2:35 pm
From: jacob navia
Le 26/02/2014 23:30, Jorgen Grahn a écrit :
> On Mon, 2014-02-24, Wouter van Ooijen wrote:
>> jacob navia schreef op 24-Feb-14 3:34 PM:
>>> Besides, if you want to support SEVERAL print functions for instance for
>>> formatting a customer with name, age or name, SS number, or just
>>> initials, etc you will need anyway several print functions in C++ also,
>>> if I remember correctly isn't it?
>>
>> In true C++: if that is what you want it is cetainly possible, just like
>> you can have print_xxx functions if you want to.
>>
>> I think I would prefer to reserve operator<<(person) for (debug)
>> printing of ALL data in person, and have separate getters for the items
>> that you might want to print, like
>>
>> std::cout
>> << std::setw( 30 ) << person.name()
>> << " lives at "
>> << std::setw( 60 ) << person.adress();
>>
>> This keeps *what* you want to print separate from *how* you want to
>> print it.
>
> I think what jacob navia is after would be better done as a bunch of
> classes which only know how to format a Customer, each in its unique
> fashion:
>
> std::cout << ForMailingLabel(some_customer);
> std::cout << ForGreetingMessage(some_customer);
> std::cout << ForTheNSA(some_customer);
>
> (Sorry about the bad naming; I don't deal with customers so I don't
> know what you want to print or why.)
>
> /Jorgen
>
Exactly, and I like specially the last one:
std::cout << ForTheNSA(some_customer);
!!!
== 11 of 12 ==
Date: Thurs, Feb 27 2014 12:01 am
From: Stuart
On 02/26/2014, Jorgen Grahn wrote:
>> I think what jacob navia is after would be better done as a bunch of
>> classes which only know how to format a Customer, each in its unique
>> fashion:
>>
>> std::cout << ForMailingLabel(some_customer);
>> std::cout << ForGreetingMessage(some_customer);
>> std::cout << ForTheNSA(some_customer);
[snip]
On 02/26/14, jacob navia:
> Exactly, and I like specially the last one:
>
> std::cout << ForTheNSA(some_customer);
>
> !!!
+1.
If the NSA was really that good, they should slip it into the C++
standard and make it a required method for each class ;-)
Regards,
Stuart
== 12 of 12 ==
Date: Thurs, Feb 27 2014 12:55 am
From: David Brown
On 27/02/14 09:01, Stuart wrote:
> On 02/26/2014, Jorgen Grahn wrote:
>>> I think what jacob navia is after would be better done as a bunch of
>>> classes which only know how to format a Customer, each in its unique
>>> fashion:
>>>
>>> std::cout << ForMailingLabel(some_customer);
>>> std::cout << ForGreetingMessage(some_customer);
>>> std::cout << ForTheNSA(some_customer);
> [snip]
>
> On 02/26/14, jacob navia:
>> Exactly, and I like specially the last one:
>>
>> std::cout << ForTheNSA(some_customer);
>>
>> !!!
>
> +1.
>
> If the NSA was really that good, they should slip it into the C++
> standard and make it a required method for each class ;-)
>
This explains the "hidden overheads" in C++ that C fans always complain
about...
==============================================================================
TOPIC: How to download Microsoft Visuail c++ software
http://groups.google.com/group/comp.lang.c++/t/1aa05d6584f1e293?hl=en
==============================================================================
== 1 of 8 ==
Date: Tues, Feb 25 2014 8:22 pm
From: 893756098a@gmail.com
Recently,our class had studied Microsoft Visuail c++.So I want to practice after school,but I can't install this.I would appreciate it if someone could do me a favour!
== 2 of 8 ==
Date: Tues, Feb 25 2014 10:42 pm
From: Robert Wessel
On Tue, 25 Feb 2014 20:22:02 -0800 (PST), 893756098a@gmail.com wrote:
> Recently,our class had studied Microsoft Visuail c++.So I want to practice after school,but I can't install this.I would appreciate it if someone could do me a favour!
You can download the Visual Studio Express products from:
http://www.visualstudio.com/products/visual-studio-express-vs
You probably want the "Express 2013 for Windows Desktop" version.
If you need a version that runs on version of Windows prior to 7,
there's a link to the VS2010 downloads on that page (you'd probably
want to "C++" version).
== 3 of 8 ==
Date: Wed, Feb 26 2014 2:00 am
From: Javier López
El 26/02/2014 5:22, 893756098a@gmail.com escribió:
> Recently,our class had studied Microsoft Visuail c++.
> So I want to practice after school,but I can't install this.I would
> appreciate it if someone could do me a favour!
>
You can download Windows SDK 7.1 instead (or in addition to) if you only
want the toolchain (compiler, linker, etc. but not the IDE) or if you
want to compile 64-bit executables.
== 4 of 8 ==
Date: Wed, Feb 26 2014 3:50 am
From: "Rick C. Hodgin"
On Tuesday, February 25, 2014 11:22:02 PM UTC-5, 89375...@gmail.com wrote:
> Recently,our class had studied Microsoft Visuail c++.So I want to practice after school,but I can't install this.I would appreciate it if someone could do me a favour!
If you would like an older version (lighter weight), you can download Visual Studio 2008 Express C++ here:
http://www.libsf.org/software/other/microsoft/visual-studio-2008-express-enu-x1397868.iso
Best regards,
Rick C. Hodgin
== 5 of 8 ==
Date: Wed, Feb 26 2014 8:31 am
From: Bo Persson
Javier López skrev 2014-02-26 11:00:
> El 26/02/2014 5:22, 893756098a@gmail.com escribió:
>> Recently,our class had studied Microsoft Visuail c++.
>> So I want to practice after school,but I can't install this.I would
>> appreciate it if someone could do me a favour!
>>
> You can download Windows SDK 7.1 instead (or in addition to) if you only
> want the toolchain (compiler, linker, etc. but not the IDE) or if you
> want to compile 64-bit executables.
Nowadays, even the Express edition contains the 64-bit compiler.
Bo Persson
== 6 of 8 ==
Date: Wed, Feb 26 2014 11:28 am
From: "Rick C. Hodgin"
On Wednesday, February 26, 2014 11:31:07 AM UTC-5, Bo Persson wrote:
> Javier López skrev 2014-02-26 11:00:
> > You can download Windows SDK 7.1 instead (or in addition to) if you only
> > want the toolchain (compiler, linker, etc. but not the IDE) or if you
> > want to compile 64-bit executables.
>
> Nowadays, even the Express edition contains the 64-bit compiler.
I have no experience with Visual Studio 2012 or later. Once I saw that you
needed to be logged in to a Microsoft account to do certain things, I said,
"Check, please!"
-----
The only real difference is you can't use the Express Edition for creating
commercial software after 30 days without registering it. But, you can
create and sell commercial software for up to 30 days, or if you register
it, forever thereafter.
Plugins do not work with the express edition either, so tools like Whole
Tomato's Visual Assist X won't work.
From: http://social.msdn.microsoft.com/Forums/en-US/0782e1b0-db87-4de3-b79d-ba56a481e750/visual-studio-2010-express-is-now-available?forum=Vsexpressinstall
According to Adrian Collier:
"Provided that you comply with all the License Terms for a
particular Express release, the 2010 Express SKUS can be
used to create commercial software. Before you register
the express SKU you are effectively running a trial version
of the Express product, which expires after 30 days. There
is no limit on creating commercial software during the trial
period. Once you register the product, the 'Evaluation' text
changes to show it is a licensed copy."
Best regards,
Rick C. Hodgin
== 7 of 8 ==
Date: Thurs, Feb 27 2014 1:29 am
From: 893756098a@gmail.com
在 2014年2月26日星期三UTC+8下午2时42分58秒，robert...@yahoo.com写道：
> On Tue, 25 Feb 2014 20:22:02 -0800 (PST), 893756098a@gmail.com wrote:
>
>
>
> > Recently,our class had studied Microsoft Visuail c++.So I want to practice after school,but I can't install this.I would appreciate it if someone could do me a favour!
>
>
>
>
>
> You can download the Visual Studio Express products from:
>
>
>
> http://www.visualstudio.com/products/visual-studio-express-vs
>
>
>
> You probably want the "Express 2013 for Windows Desktop" version.
>
>
>
> If you need a version that runs on version of Windows prior to 7,
>
> there's a link to the VS2010 downloads on that page (you'd probably
>
> want to "C++" version).
== 8 of 8 ==
Date: Thurs, Feb 27 2014 8:58 am
From: woodbrian77@gmail.com
Does anyone know if the last CTP for the C++ part
of VS has been incorporated yet into the version
of VS available for download? And if it hasn't
been yet, when it will be? Tia.
==============================================================================
TOPIC: OT: Problem building libc++
http://groups.google.com/group/comp.lang.c++/t/177ee9b847d7540f?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 26 2014 2:45 am
From: Öö Tiib
On Tuesday, 25 February 2014 16:55:47 UTC+2, Scott Lurndal wrote:
> woodbrian77@gmail.com writes:
> >Previously all I had to do to switch from gcc to
> >clang was uncomment this line:
> >
> >#CXX=clang++
> >
> >So it was easy to switch between the two. Now it's
> >kind of troublesome.
>
> See, that's what I call obsessive :-)
>
> Pick a compiler and stick with it.
There are different problem domains. For some software it is
fine advice I guess. For what Brian does it it feels not that good
advice. Reason is that one of Brian's key requirements is
portability.
I have used different compilers (up to 3) as tools of additional
automatic diagnosing even where portability is not required. It
is cheap to set up compiling and running the unit-tests
automatically on several compilers in continuous integration
(if there already are named things anyway).
The differences tend to come up from dim regions of C++
language as rule. Such code (that fails or runs depending on
compiler) can be correct for language lawyer; still it is always
better idea to rewrite it. C++ compilers feel to be among
smartest tools in human disposal and if some of those do not
parse a piece of code then very high chances are that next
human engineer who reads it is stuck with it as well (and that
is expensive).
==============================================================================
TOPIC: EVOLUTIONISTS DESTROYED IN 5 SECONDS
http://groups.google.com/group/comp.lang.c++/t/e18502459ce73309?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 26 2014 8:51 am
From: Thrinaxodon
=================
>BREAKING NEWS!!!
=================
>
THRINAXODON FOUND 300 FOSSILS FROM DEVONIAN STRATA FROM GREENLAND LAST
TUESDAY, ONE WAS A COMPLETE HUMAN PELVIS!
>
THRINAXODON ALSO FOUND 6 PRIMITIVE STONE TOOLS FROM THE SITE, AS WELL AS
CHARCOAL!
>
PETER NYIKOS WAS FORCED TO ACCEPT THAT HUMANS HAVE ORIGINS IN THE
DEVONIAN AND HUMAN EVOLUTION IS A SCAM.
>
THE SMITHSONIAN IS GOING NUTS OVER THIS FIND, I WILL HAVE TO PATENT IT
BEFORE ANYONE ELSE!
>
SEE YA FUCKERS!
============================
EVIDENCE THAT HUMANS LIVED IN THE DEVONIAN:
https://groups.google.com/group/sci.bio.paleontology/browse_thread/thread/6f501c469c7af24f#
https://groups.google.com/group/sci.bio.paleontology/browse_thread/thread/3aad75c16afb0b82#
====================================
http://thrinaxodon.wordpress.com/
===================================
THRINAXODON ONLY HAD THIS TO SAY:
"I..I...I...Can't believe it. This completely disproved Darwinian
orthodoxy."
===================================
THE BASTARDS AT THE SMITHSONIAN, AND THE LEAKEY FOUNDATION ARE ERODING
WITH FEAR.
===========================
THESE ASSHOLES ARE GOING TO DIE:
THOMAS AQUINAS;
ALDOUS HUXLEY;
BOB CASANVOVA;
SkyEyes;
DAVID IAIN GRIEG;
MARK ISAAK;
JOHN HARSHAM;
RICHARD NORMAN;
DR. DOOLITTLE;
CHARLES DARWIN;
MARK HORTON;
ERIK SIMPSON;
HYPATIAB7;
PAUL J. GANS;
JILLERY;
WIKI TRIK;
THRINAXODON;
PETER NYIKOS;
RON OKIMOTO;
JOHN S. WILKINS
===========================
THRINAXODON WAS SCOURING ANOTHER DEVONIAN FOSSIL BED, AND FOUND A
HUMAN SKULL, AND A HUMAN FEMUR. HE ANALYSED THE FINDS, AND SAW THAT
THEY WERE NOT NORMAL ROCKS. THESE WERE FOSSILIZED BONES. THEY EVEN HAD
TOOTH MARKS ON THEM. SO, THRINAXODON BROUGHT THEM TO THE LEAKEY
FOUNDATION, THEY UTTERLY DISMISSED IT, AND SAID, "We want to keep
people thinking that humans evolved 2 Ma." THRINAXODON BROUGHT HIS
SWORD, AND SAID, "SCIENCE CORRECTS ITSELF." RICHARD LEAKEY SAID, "That
is a myth, for people to believe in science." THRINAXODON PLANS TO
BRING DOOM TO SCIENCE, ITSELF.
============================
THRINAXODON IS NOW ON TWITTER
--
---Thrinaxodon
==============================================================================
TOPIC: calling placement new for elements of a deque
http://groups.google.com/group/comp.lang.c++/t/a896b7c648e29553?hl=en
==============================================================================
== 1 of 4 ==
Date: Wed, Feb 26 2014 9:50 pm
From: hbdevelop1@gmail.com
Hello
For optimisation reasons, I am re-using not used objects in my deque for new objects.
I am doing that this way :
void Score::Add(const char *str, Coordinates &sp)
{
for(deque<Text>::iterator it=scores.begin();it!=scores.end(); ++it)
{
if(it->notUsed==1)
{
it->Reset(str,sp);
return;
}
}
scores.push_back(Text(str,sp));
}
I thought it would be more convenient to call the placement new on the notUsed object instead of Reset.
How can I do this ?
How can I get the address of the not used object so I can use it in the new placement operator?
Thank you in advance
== 2 of 4 ==
Date: Thurs, Feb 27 2014 5:43 am
From: Victor Bazarov
On 2/27/2014 12:50 AM, hbdevelop1@gmail.com wrote:
> For optimisation reasons, I am re-using not used objects in my deque for new objects.
> I am doing that this way :
> void Score::Add(const char *str, Coordinates &sp)
> {
> for(deque<Text>::iterator it=scores.begin();it!=scores.end(); ++it)
> {
> if(it->notUsed==1)
> {
> it->Reset(str,sp);
> return;
> }
> }
>
> scores.push_back(Text(str,sp));
> }
>
> I thought it would be more convenient to call the placement new on the notUsed object instead of Reset.
> How can I do this ?
> How can I get the address of the not used object so I can use it in the new placement operator?
You can get a reference to the object through operator* of the iterator.
Then you can use the operator& to get the address of the object. Keep
in mind, however, that generally the constructor calls need to match the
destructor calls, so don't forget to destroy the object using a direct
call to the destructor before constructing a new one there. Something like
if (it->notUsed == 1)
{
Text *pUnused = &(*it);
pUnused->~Text(); // destroy
new (pUnused) Text(str, sp);
return;
}
Remember to include <memory> for placement new operator.
Not sure this is the best approach, though. Why do you think that using
Reset is inconvenient?
V
--
I do not respond to top-posted replies, please don't ask
== 3 of 4 ==
Date: Thurs, Feb 27 2014 9:53 am
From: red floyd
On 2/27/2014 5:43 AM, Victor Bazarov wrote:
>
> if (it->notUsed == 1)
> {
> Text *pUnused = &(*it);
> pUnused->~Text(); // destroy
> new (pUnused) Text(str, sp);
> return;
> }
>
> Remember to include <memory> for placement new operator.
>
> Not sure this is the best approach, though. Why do you think that using
> Reset is inconvenient?
The only reason I can see for using placement new instead of a reset is
that some const members may need updating for the new data. Otherwise
a reset should be fine.
== 4 of 4 ==
Date: Thurs, Feb 27 2014 2:39 pm
From: hbdevelop1@gmail.com
The reason why I don't want to use Reset is because it holds the same code as the constructor and is only used in this case.
So I just wondered if I could get rid of Reset and use the constructor, for both, when pushing for the first time and when resetting.
And now, red floyd has given another reason why I might want to use the placement new in future.
Thank you very much Victor and red for your help and constructive feed back
hbdevelop1
On Thursday, February 27, 2014 8:43:12 AM UTC-5, Victor Bazarov wrote:
> On 2/27/2014 12:50 AM, hbdev...@gmail.com wrote:
>
> > For optimisation reasons, I am re-using not used objects in my deque for new objects.
>
> > I am doing that this way :
>
> > void Score::Add(const char *str, Coordinates &sp)
>
> > {
>
> > for(deque<Text>::iterator it=scores.begin();it!=scores.end(); ++it)
>
> > {
>
> > if(it->notUsed==1)
>
> > {
>
> > it->Reset(str,sp);
>
> > return;
>
> > }
>
> > }
>
> >
>
> > scores.push_back(Text(str,sp));
>
> > }
>
> >
>
> > I thought it would be more convenient to call the placement new on the notUsed object instead of Reset.
>
> > How can I do this ?
>
> > How can I get the address of the not used object so I can use it in the new placement operator?
>
>
>
> You can get a reference to the object through operator* of the iterator.
>
> Then you can use the operator& to get the address of the object. Keep
>
> in mind, however, that generally the constructor calls need to match the
>
> destructor calls, so don't forget to destroy the object using a direct
>
> call to the destructor before constructing a new one there. Something like
>
>
>
> if (it->notUsed == 1)
>
> {
>
> Text *pUnused = &(*it);
>
> pUnused->~Text(); // destroy
>
> new (pUnused) Text(str, sp);
>
> return;
>
> }
>
>
>
> Remember to include <memory> for placement new operator.
>
>
>
> Not sure this is the best approach, though. Why do you think that using
>
> Reset is inconvenient?
>
>
>
> V
>
> --
>
> I do not respond to top-posted replies, please don't ask
==============================================================================
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
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment