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

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

comp.lang.c++@googlegroups.com

Today's topics:

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

== 1 of 1 ==
Date: Mon, Dec 28 2009 8:34 pm
From: "xfan"

i don't speak english!~~sorry!~~

"xfan" <xfan1216@qq.com> Ð´ÈëÏûÏ¢ÐÂÎÅ:hgt5jh$8uo$1@www.shinco.com...
>
>
>

==============================================================================
TOPIC: branches (if) and iterations (for)
http://groups.google.com/group/comp.lang.c++/t/62cf21e8adcb5b4f?hl=en
==============================================================================

== 1 of 5 ==
Date: Tues, Dec 29 2009 1:53 am
From: s

Hello all,

I was wondering on the following:

Regarding modern C++ compilers, is there a performance difference
between the following pseudo
code snips regarding the effects of:

* the taken/not taken conditions/branches and the CPU branch
prediction;
* and/or pipeline invalidations on missed branches;

And if there's no performance difference, which version would you
choose (regarding maintainability,etc.)?

## version 1 with `break`

for (int i=0; i < array_len; i++ )
{
if ( array[i] == requested_item )
{
found = true;
break;
} // if

} // for

if found ....

## version 2 with `continue`

for (int i=0; i < array_len; i++ )
{
if ( array[i] != requested_item )
{
continue;
} // if

found = true;
break;
} // for

if found ....

----

Thanks for your time,
Karoly

== 2 of 5 ==
Date: Tues, Dec 29 2009 8:46 am
From: Jonathan Lee

On Dec 29, 4:53 am, s <die9...@gmail.com> wrote:
> for (int i=0; i < array_len; i++ )
> {
> if ( array[i] == requested_item )
> {
> found = true;
> break;
> } // if
>
> } // for

Well, presumably you don't want i to go out of scope
so I'd end up writing

int i = 0;
while (i < array_len && array[i] != requested_item) {
// if (!found) ...
++i;
}
if (i < array_len) { /* i.e., found */ } else { ... }

This is easier to read for me. Performance wise I doubt
you'd find any significant difference between the
versions.

--Jonathan

== 3 of 5 ==
Date: Tues, Dec 29 2009 9:02 am
From: Jeff Flinn

Jonathan Lee wrote:
> On Dec 29, 4:53 am, s <die9...@gmail.com> wrote:
>> for (int i=0; i < array_len; i++ )
>> {
>> if ( array[i] == requested_item )
>> {
>> found = true;
>> break;
>> } // if
>>
>> } // for
>
> Well, presumably you don't want i to go out of scope
> so I'd end up writing
>
> int i = 0;
> while (i < array_len && array[i] != requested_item) {
> // if (!found) ...
> ++i;
> }
> if (i < array_len) { /* i.e., found */ } else { ... }
>
> This is easier to read for me. Performance wise I doubt
> you'd find any significant difference between the
> versions.

or since the op didn't define the type of array, and since this is 2009
and the op should be using a std container:

Array::iterator itr =
std::find(array.begin(), array.end(), requested_item);

if( itr != array.end())
{
...
}

and if it's not a std container

requested_item_type* itr =
std::find(array, array + array_len, requested_item);

if( itr != (array + array_len))
{
...
}

Jeff

== 4 of 5 ==
Date: Tues, Dec 29 2009 9:17 am
From: Jonathan Lee

On Dec 29, 12:02 pm, Jeff Flinn <TriumphSprint2...@hotmail.com> wrote:
> or since the op didn't define the type of array, and since this is 2009
> and the op should be using a std container:

I think he's asking about the form of the loop, as opposed
to how to find things in an array.

--Jonathan

== 5 of 5 ==
Date: Tues, Dec 29 2009 10:56 am
From: Pavel

s wrote:
> Hello all,
>
> I was wondering on the following:
>
> Regarding modern C++ compilers, is there a performance difference
> between the following pseudo
> code snips regarding the effects of:
>
> * the taken/not taken conditions/branches and the CPU branch
> prediction;
> * and/or pipeline invalidations on missed branches;
>
> And if there's no performance difference, which version would you
> choose (regarding maintainability,etc.)?
>
>
>
> ## version 1 with `break`
>
> for (int i=0; i< array_len; i++ )
> {
> if ( array[i] == requested_item )
> {
> found = true;
> break;
> } // if
>
> } // for
>
> if found ....
>
> ## version 2 with `continue`
>
> for (int i=0; i< array_len; i++ )
> {
> if ( array[i] != requested_item )
> {
> continue;
> } // if
>
> found = true;
> break;
> } // for
>
> if found ....
>
> ----
>
> Thanks for your time,
> Karoly
>

The modern compilers sometimes provide implementation-specific means for
a programmer to let compiler know what branch is likely to happen in the
program (see __builtin_expect in gcc or

http://kerneltrap.org/node/4705

for some discussion).

The "old-school" thinking was that you wanted to put the break on a
condition that happens rarely in the loop header (the compiler would
commonly generate a forward jump for that) and the one you check within
a loop will be assumed to happen more often but I am not sure if it is
still a common assumption by the compiler writers.

On a side note, if you use loop unrolling optimization (such as
-funroll-loops for gcc), you may end up with a completely unexpected
generated code (gcc especially loves unrolling the form of "for" loop
you used in your example).

As every modern compiler is even more different than way back, your best
bet is probably just reading the assembly listing of the code generated
by your compiler of choice with the particular set of options you are
going to use in your release configuration.

-Pavel

==============================================================================
TOPIC: c++ as scripting language
http://groups.google.com/group/comp.lang.c++/t/8b6a860779bd7319?hl=en
==============================================================================

== 1 of 8 ==
Date: Tues, Dec 29 2009 4:02 am
From: balajee

Hi,
I am new bee to C++. Basically I am TCL pogrammer, write scripts to
automate interactive applications such as telnet,ftpetc. Can we use C+
+ also for the same purpose? as scripting language for above
applications?

== 2 of 8 ==
Date: Tues, Dec 29 2009 4:16 am
From: Sam

balajee writes:

> Hi,
> I am new bee to C++. Basically I am TCL pogrammer, write scripts to
> automate interactive applications such as telnet,ftpetc. Can we use C+
> + also for the same purpose? as scripting language for above
> applications?

C++ is not a scripting language. It is a compiled language.

Perhaps you mean if you use C++ to control external programs, like TCL does.
Yes, you'll just have to do everything that TCL does: fork and run the
external program as a child process, read and write to the external programs
standard input and output accordingly, etc.

== 3 of 8 ==
Date: Tues, Dec 29 2009 4:36 am
From: balajee

On Dec 29, 5:16 pm, Sam <s...@email-scan.com> wrote:
> balajee writes:
> > Hi,
> > I am new bee to C++. Basically I am TCL pogrammer, write scripts to
> > automate interactive applications such as telnet,ftpetc. Can we use C+
> > + also for the same purpose? as scripting language for above
> > applications?
>
> C++ is not a scripting language. It is a compiled language.
>
> Perhaps you mean if you use C++ to control external programs, like TCL does.
> Yes, you'll just have to do everything that TCL does: fork and run the
> external program as a child process, read and write to the external programs
> standard input and output accordingly, etc.
>
> application_pgp-signature_part
> < 1KViewDownload

HI,
Thanks for the reply. I am not able to open your attachment. I just
want to write telnet application using c++. Can you guide me on how to
do this? I know C++ basics.

Thanks,
Balajee

== 4 of 8 ==
Date: Tues, Dec 29 2009 5:14 am
From: Michael Doubez

On 29 déc, 13:16, Sam <s...@email-scan.com> wrote:
> balajee writes:
> > Hi,
> > I am new bee to C++. Basically I am TCL pogrammer, write scripts to
> > automate interactive applications such as telnet,ftpetc. Can we use C+
> > + also for the same purpose? as scripting language for above
> > applications?
>
> C++ is not a scripting language. It is a compiled language.

It is not.
An interpreter engine does exists:
http://root.cern.ch/drupal/content/cint

[snip]

--
Michael

== 5 of 8 ==
Date: Tues, Dec 29 2009 8:31 am
From: "Fred Zwarts"

Michael Doubez wrote:
> On 29 déc, 13:16, Sam <s...@email-scan.com> wrote:
>> balajee writes:
>>> Hi,
>>> I am new bee to C++. Basically I am TCL pogrammer, write scripts to
>>> automate interactive applications such as telnet,ftpetc. Can we use
>>> C+ + also for the same purpose? as scripting language for above
>>> applications?
>>
>> C++ is not a scripting language. It is a compiled language.
>
> It is not.
> An interpreter engine does exists:
> http://root.cern.ch/drupal/content/cint

The C++ language is not by definition a compiled language.
But CINT is a bad example. It is not really C++.
Scoping rules, catching exceptions, dynamic_cast, amongst others,
are all very different from the C++ rules.

== 6 of 8 ==
Date: Tues, Dec 29 2009 10:49 am
From: "BGB / cr88192"

"balajee" <balajee4@gmail.com> wrote in message
news:e4c97abd-aeba-4c6f-a583-a2968cc9009b@m38g2000yqd.googlegroups.com...
> Hi,
> I am new bee to C++. Basically I am TCL pogrammer, write scripts to
> automate interactive applications such as telnet,ftpetc. Can we use C+
> + also for the same purpose? as scripting language for above
> applications?

another person has mentioned CINT, which is, sadly, the best I know of as
far as scripting in C++ goes...

I think LLVM / CLang was also working on C++ support, but am not at present
sure of their current status.

granted, the task is much easier if one is willing to live with C, given
there are several different options as far as C interpretation and dynamic
compilation goes.

LLVM / CLang;
TinyC;
CINT (again);
...

I am also using C as a scripting language (via a custom written VM-ish
framework).
I don't support C++ as it is horridly complicated (vs C), and don't
personally have the motivation or resources to beat together an
implementation (unless maybe it were an extreme subset, I had looked briefly
at EC++ in the past).
I may eventually have Java and others added to the mix, but not much can be
said here at the moment (Java support is woefully incomplete).

of course, if you are talking about using it for scripting an already
existing app, well, that is a bit more of an issue, as then one is usually
limited to whatever language(s) the app already supports.

== 7 of 8 ==
Date: Tues, Dec 29 2009 1:03 pm
From: Michael DOUBEZ

Le 29/12/2009 17:31, Fred Zwarts a �crit :
> Michael Doubez wrote:
>> On 29 d�c, 13:16, Sam<s...@email-scan.com> wrote:
>>> balajee writes:
>>>> Hi,
>>>> I am new bee to C++. Basically I am TCL pogrammer, write scripts to
>>>> automate interactive applications such as telnet,ftpetc. Can we use
>>>> C+ + also for the same purpose? as scripting language for above
>>>> applications?
>>>
>>> C++ is not a scripting language. It is a compiled language.
>>
>> It is not.
>> An interpreter engine does exists:
>> http://root.cern.ch/drupal/content/cint
>
> The C++ language is not by definition a compiled language.
> But CINT is a bad example.

But it is the only interpreter I know of.

> It is not really C++.
> Scoping rules, catching exceptions, dynamic_cast, amongst others,
> are all very different from the C++ rules.

Brand new version 7 is a bit better in this regard. But if I have read
correctly, they may switch to LLVM.

--
Michael

== 8 of 8 ==
Date: Tues, Dec 29 2009 3:32 pm
From: Sam

balajee writes:

> On Dec 29, 5:16 pm, Sam <s...@email-scan.com> wrote:
>> balajee writes:
>> > Hi,
>> > I am new bee to C++. Basically I am TCL pogrammer, write scripts to
>> > automate interactive applications such as telnet,ftpetc. Can we use C+
>> > + also for the same purpose? as scripting language for above
>> > applications?
>>
>> C++ is not a scripting language. It is a compiled language.
>>
>> Perhaps you mean if you use C++ to control external programs, like TCL does.
>> Yes, you'll just have to do everything that TCL does: fork and run the
>> external program as a child process, read and write to the external programs
>> standard input and output accordingly, etc.
>>
>> application_pgp-signature_part
>> < 1KViewDownload
>
>
>
> HI,
> Thanks for the reply. I am not able to open your attachment. I just
> want to write telnet application using c++. Can you guide me on how to
> do this? I know C++ basics.

This is not something that can be described in a few paragraphs, but if all
you're trying to do is emulate telnet, you don't need to script telnet at
all. All that telnet does is create a socket and connect to the server. You
can do that yourself, without involving telnet. Use socket() to create a
socket, then connect() to your server, then read() and write() from the
socket connection to your heart's desire.

See your man pages for a full description of these library calls.

==============================================================================
TOPIC: Design patterns
http://groups.google.com/group/comp.lang.c++/t/c99eb0b17c6ad648?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Dec 29 2009 10:50 am
From: Daniel Pitts

Jayson Cormier wrote:
> Bean it! Everything... bean-able. Enterprise Java Bean, Netbeans...
>
>
Kicked in the beans.

The Java folks had a great idea with JavaBeans, but they failed at
implementing it in a consistent and useful way. There is no language
level support for property-change listeners, so it becomes extremely
burdensome trying to create a functional bean which is useful as a GUI
model.

Don't get me wrong, I'm primarily a Java programmer. I just think that
the Bean hype has caused many people to forget basic abstraction
concepts, and the benefits of Beans have yet to been fully realized.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

==============================================================================
TOPIC: Factories, handles, and handle wrappers
http://groups.google.com/group/comp.lang.c++/t/256b13c75b2cc8db?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Dec 29 2009 10:55 am
From: DeMarcus

>
> * Sorry for the obtuse language; OBJHANDLE is intentionally not
> directly associated with the type of the class it identifies, because
> it's imperative that those class instances not be used without
> checking for their validity. If I go ahead and call it a pointer, then
> confusion would arise based on the assumption that it's already
> directly usable as such. Hence the term "handle". I'm open to
> becoming familiarized with clearer language and/or terminology.
>

Instead of OBJHANDLE, what about call it an OBJ_PROXY?

http://en.wikipedia.org/wiki/Proxy_pattern

==============================================================================
TOPIC: String not printing data on next line despite \n in the string
http://groups.google.com/group/comp.lang.c++/t/35658d761ffe5130?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Dec 29 2009 11:01 am
From: "BGB / cr88192"

"James Kanze" <james.kanze@gmail.com> wrote in message
news:fc78f0bf-b3f5-4cfe-805b-86bef9189fb4@22g2000yqr.googlegroups.com...
> On Dec 26, 9:35 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
>> Paavo Helde wrote:
>> >> (not wanting to make debate here, but there are reasons to
>> >> choose one or another in different contexts, many not
>> >> particularly relevant to the language as seen/written by
>> >> humans, and many not related to the "majority" of
>> >> projects).
>
>> > I cannot see any reason to knowingly leave a potential UB
>> > bug in the program. God knows there are many of them already
>> > left unknowingly, no reason to add one!
>
>> Hm, microsoft had practice to allow write in deallocated
>> memory in order for some important applications to work on
>> windows.
>
> In the earliest versions of C (pre-standard), the rule was that
> the pointer to realloc had to be the last pointer that was
> freed. In those days, it was considered acceptable to use freed
> memory up until the next call to malloc.
>
> In those days, of course, there was no multithreading, and
> programs weren't connected to the internet.
>
>> I don;t see how this is problem.
>
> Using a dangling pointer is a serious security hole.
>

as well as a serious crash hazard, IMO...

granted, I am a little less concerned over buffer overflows, granted, they
may be a bit more of a worry if the app actually matters as far as security
goes (connected to the internet, getting input from "untrusted" sources,
...).

even then, it is not often "as bad" in practice, for example, for calls like
'fgets()' one supplies the maximum string length anyways (typically a few
chars less than the buffer size), so this much is self-limiting. one can
know the call will not return an oversize string, since it will be cut off
and returned on the next line.

in many other cases, one knows the code that both produces and accepts the
strings, and so can know that code further up the chain will not exceed the
limit.

as well, 256 is an "accepted" maximum string length (a tradition since long
past that something is seriously wrong if a string is longer than this).

much like how something is wrong if a line in a text file is longer than 80
chars, and it is usually best to limit output to 76 chars just to be safe...
(except in certain file formats, where longer lines tend to pop up a
lot...).

this does allow "some" safety with fixed-size char arrays, which is good
since these are one of the fastest ways I know of to implement certain
string operations.

> --
> James Kanze

==============================================================================
TOPIC: Interfacing C++ and assembler code
http://groups.google.com/group/comp.lang.c++/t/79272d2bf39c62ec?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Dec 29 2009 11:23 am
From: Pavel

Bo Persson wrote:
> Jorgen Grahn wrote:
>> On Sat, 2009-12-26, Branimir Maksimovic wrote:
>> ...
>>> This is implementation of my Window class, I think, everything is
>>> clear here, how you can do it in win32, unfortunately microsoft
>>> has banned assembler from 64 bit environment there you can only
>>> write separate assembler modules:
>>
>> I don't do Win32 programming, but your example makes it reasonably
>> clear that they did *not* ban assembly; they simply removed the C++
>> extensions for inline assembly from their compiler. Some would say
>> that was a wise choice.
>>
>
> Yes, most of the "interesting" instructions are available as compiler
> intrinsics, so you can still use them.
>
> Mixing a few assembly instructions in the middle of a C or C++
> function tended to disturb the optimizer so that the surrounding code
> was less well optimized. That took away most of the advantage of using
> assembly to gain extra speed
I am not sure about Visual C++ in particular but in case of gcc it is
currently not quite so. Gcc inline assembler provides a nice set of
means for inline assembler snippet to cooperate with the optimizer.

In my practice, I often use "GCC-Inline-Assembly-HOWTO" by Sandeep.S and
I am usually satisfied with the generated code. See for example
http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#ss5.3
for the discussion of how to let the compiler know which exactly
registers are clobbered by an inline assembler fragment.

, so any performance bottlenecks would
> generally have to be coded separately anyway.
In my practice, the required assembler fragments are usually small (most
often, I resort to them to use a particularly beneficial instruction
that compiler would not be able to infer); putting them in separate
included files is sometimes feasible but not to separate compilation
units. At my desired optimization level, the compilers I use perform
global in-lining within a compilation unit (I mean optimizer's
opportunistic inlining which is not limited by C++ functions declared
inline); having assembler snippets in separate units would prevent this
from happening.

>
>
> Bo Persson
>
>

== 2 of 3 ==
Date: Tues, Dec 29 2009 2:08 pm
From: "Bo Persson"

Pavel wrote:
> Bo Persson wrote:
>> Jorgen Grahn wrote:
>>> On Sat, 2009-12-26, Branimir Maksimovic wrote:
>>> ...
>>>> This is implementation of my Window class, I think, everything is
>>>> clear here, how you can do it in win32, unfortunately microsoft
>>>> has banned assembler from 64 bit environment there you can only
>>>> write separate assembler modules:
>>>
>>> I don't do Win32 programming, but your example makes it reasonably
>>> clear that they did *not* ban assembly; they simply removed the
>>> C++ extensions for inline assembly from their compiler. Some
>>> would say that was a wise choice.
>>>
>>
>> Yes, most of the "interesting" instructions are available as
>> compiler intrinsics, so you can still use them.
>>
>> Mixing a few assembly instructions in the middle of a C or C++
>> function tended to disturb the optimizer so that the surrounding
>> code was less well optimized. That took away most of the advantage
>> of using assembly to gain extra speed
> I am not sure about Visual C++ in particular but in case of gcc it
> is currently not quite so. Gcc inline assembler provides a nice set
> of means for inline assembler snippet to cooperate with the
> optimizer.
> In my practice, I often use "GCC-Inline-Assembly-HOWTO" by
> Sandeep.S and I am usually satisfied with the generated code. See
> for example
> http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#ss5.3
> for the discussion of how to let the compiler know which exactly
> registers are clobbered by an inline assembler fragment.
> , so any performance bottlenecks would
>> generally have to be coded separately anyway.
> In my practice, the required assembler fragments are usually small
> (most often, I resort to them to use a particularly beneficial
> instruction that compiler would not be able to infer); putting them
> in separate included files is sometimes feasible but not to
> separate compilation units. At my desired optimization level, the
> compilers I use perform global in-lining within a compilation unit
> (I mean optimizer's opportunistic inlining which is not limited by
> C++ functions declared inline); having assembler snippets in
> separate units would prevent this from happening.

Yes, but the interesting instructions that do not map to C or C++
constructs are available as compiler intrinsics (equivalent to
__builtin_x for gcc). These instructions are known to the optimizer,
and that knowledge is taken advantage of.

http://msdn.microsoft.com/en-us/library/azcs88h2%28VS.100%29.aspx

Therefore the lack of inline assembly for x64 is hardly ever
important.

Bo Persson

== 3 of 3 ==
Date: Tues, Dec 29 2009 2:54 pm
From: Branimir Maksimovic

Bo Persson wrote:
> Pavel wrote:
>> Bo Persson wrote:
>>> Jorgen Grahn wrote:
>>>> On Sat, 2009-12-26, Branimir Maksimovic wrote:
>>>> ...
>>>>> This is implementation of my Window class, I think, everything is
>>>>> clear here, how you can do it in win32, unfortunately microsoft
>>>>> has banned assembler from 64 bit environment there you can only
>>>>> write separate assembler modules:
>>>> I don't do Win32 programming, but your example makes it reasonably
>>>> clear that they did *not* ban assembly; they simply removed the
>>>> C++ extensions for inline assembly from their compiler. Some
>>>> would say that was a wise choice.
>>>>
>>> Yes, most of the "interesting" instructions are available as
>>> compiler intrinsics, so you can still use them.
>>>
>>> Mixing a few assembly instructions in the middle of a C or C++
>>> function tended to disturb the optimizer so that the surrounding
>>> code was less well optimized. That took away most of the advantage
>>> of using assembly to gain extra speed
>> I am not sure about Visual C++ in particular but in case of gcc it
>> is currently not quite so. Gcc inline assembler provides a nice set
>> of means for inline assembler snippet to cooperate with the
>> optimizer.
>> In my practice, I often use "GCC-Inline-Assembly-HOWTO" by
>> Sandeep.S and I am usually satisfied with the generated code. See
>> for example
>> http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#ss5.3
>> for the discussion of how to let the compiler know which exactly
>> registers are clobbered by an inline assembler fragment.
>> , so any performance bottlenecks would
>>> generally have to be coded separately anyway.
>> In my practice, the required assembler fragments are usually small
>> (most often, I resort to them to use a particularly beneficial
>> instruction that compiler would not be able to infer); putting them
>> in separate included files is sometimes feasible but not to
>> separate compilation units. At my desired optimization level, the
>> compilers I use perform global in-lining within a compilation unit
>> (I mean optimizer's opportunistic inlining which is not limited by
>> C++ functions declared inline); having assembler snippets in
>> separate units would prevent this from happening.
>
> Yes, but the interesting instructions that do not map to C or C++
> constructs are available as compiler intrinsics (equivalent to
> __builtin_x for gcc). These instructions are known to the optimizer,
> and that knowledge is taken advantage of.
>
> http://msdn.microsoft.com/en-us/library/azcs88h2%28VS.100%29.aspx
>
>
> Therefore the lack of inline assembly for x64 is hardly ever
> important.
>
>

It is important, because with __declspec(naked) you could
implement function in assembler, and use c++ as macro assembler.
Problem is that if you want to write something that you cannot
do in c++, like to thunk winprocs, in 64 bit environment
you have to embed binary code, instead of assembly, which is
step backwards...assembler is easier to read....

You don;t wont optimizer to mess with code in this case anyway...
For example my window remembers pointer in run time generated
thunk (same thing is implemented in WTL, but they use
binary code, instead of assembly)...
This is faster way of implementing it than using global table of
window pointers like mfc does, because there is no lookup
every time proc is called...

Greets

--
http://maxa.homedns.org/

==============================================================================
TOPIC: How do I wirte a .hpp file? (template, friend ,class,overload )?
http://groups.google.com/group/comp.lang.c++/t/22cc444eb98ed60d?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Dec 29 2009 12:25 pm
From: red floyd

On Dec 28, 5:23 am, maigre_dragon <maigre_dra...@126.com> wrote:
[redacted]

See the FAQ, in particular 5.4, 5.7, and 5.8.

Since there was no question in your post, I'm going to assume the
subject line is your question.

How do you write a .hpp file? With a text editor.

==============================================================================
TOPIC: Saving a binary file into a string
http://groups.google.com/group/comp.lang.c++/t/ddc89ddf30293133?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Dec 29 2009 3:14 pm
From: Kaz Kylheku

On 2009-12-28, Joshua Maurice <joshuamaurice@gmail.com> wrote:
> On Dec 28, 1:07 am, Kaz Kylheku <kkylh...@gmail.com> wrote:
>> void SaveFile(string FilePath, string FileContent)
>> void SaveFile(const string& path, const string& s)
>>
>> Under any sanely implemented compiler, there is no difference.
>>
>> So this is like writing x >> 2 instead of x / 2.

Of course, that should have been x >> 1; sorry.

>> The caller passes pointers to the objects; the callee will make copy
>> if it modifies the arguments, otherwise it works with the caller's
>> objects directly.
>
> Really? This surprises me, considering this is the first I've heard
> about such magics, and many longtime posters here seem to assume /
> know otherwise.

Re-reading paragraph 15 of 12.8 of ISO/IEC 14882-2003, I'm not so sure any
more.

It's quite certain that copy construction can be elided when a class value is
returned, but it's not so clear that the optimization is allowed in parameter
passing, except when a temporary is involved.

That is to say, if we have a function void f(string s); and we call it such
that the parameter is initialized with a temporary object, for instance:

f(string("abc"))

the copying of the temporary can be elided; the parameter is simply
constructed from "abc". Argument passing of non-temporaries does not meet the
listed criteria for elision. I.e. it really is the case that the C++
programmer must manually arrange this by using the const reference syntax.

The optimization can only be done for classes with implicitly declared copy
constructors and destructors, in keeping with the as-if principle.

==============================================================================
TOPIC: std::map element in heap or stack?
http://groups.google.com/group/comp.lang.c++/t/c9389bfe3bb26d37?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Dec 29 2009 3:25 pm
From: Kaz Kylheku

On 2009-12-26, Michael Tsang <miklcct@gmail.com> wrote:
>
> shuisheng wrote:
>
>> Dear All,
>>
>> I am wondering the inserted element in std::map is located in heap or
>> stack? For example
>>
>> std::map<int, double> a;
>> a[0] = 3.14;
>>
>> The element of the map: pair<int, double>(0, 3.14) is in heap or
>> stack? I think to know it is important for memory management.
>>
>> Thank you a lot ahead,
>>
>> Shuisheng
>
> The C++ standard does not actually define the terms "heap" and "stack". The
> only part which the standard uses "stack" is "stack unwinding", which is
> related to exception handling.

The C++ standard doesn't define every technical term that it uses. however,
it includes a technical glossary via a normative reference to this
document:

ISO/IEC 2382 (all parts), Information technology---Vocabulary

which makes that document (all parts of it, evidently) part of the C++
standard.

If you do not have that document, then you effectively do not have the complete
C++ standard; you don't know whether or not the C++ standard defines the term
"stack".

If the C++ standard doesn't define that term, then its use in the description
of exception handling is a defect.

It would be astonishing if the definition of stack (if it exists) were at odds
with what nearly every computer scientist understands as a minimal definition
of a stack: namely that it is a data structure whose principal operations
provide a LIFO storage and access discipline.

Local variable storage in C++ demonstrates the LIFO property, therefore
it is probably acceptable to to refer to it as a stack, barring an unusual
or missing definition in ISO 2382.

``Heap'' isn't used in the standard, but it's a widely understood term which
refers to exactly the same kind of abstraction as ``free store'' in C++ or
``dynamic storage'' in C. In that context, it doesn't describe any particular
structure (contrast with ``binomial heap'' which is something else). It doesn't
pose any obstruction to meaningful or correct dialog.

==============================================================================
TOPIC: Writing good articles that have much better chance to be seen by others
http://groups.google.com/group/comp.lang.c++/t/ddbe20a354342370?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Dec 29 2009 3:29 pm
From: Kaz Kylheku

On 2009-12-24, tanix <tanix@mongo.net> wrote:
> So, from this standpoint, try to keep the context of the article
> intact. No not delete some section of the article you are following
> upon because you think it is "insignificant" in YOUR opinion.

In my opinion, it is bad netiquette not to trim the quoted article
as much as possible.

A Usenet archive to be useful must preserve the tree structure of
threads.

If you can't navigate to a parent article to recover context,
find a better quality Usenet archive search tool.

> Because it may turn out to be significant in readers opinion.

Nice sentiment; but the reader of an archive isn't a paying customer of the
article author, so he doesn't get to dictate how the article should have been
structured to serve him best.

== 2 of 2 ==
Date: Tues, Dec 29 2009 3:33 pm
From: Kaz Kylheku

On 2009-12-25, red floyd <no.spam.here@its.invalid> wrote:
> On 12/24/2009 12:05 PM, tanix wrote:
>> [redacted]
>
> Here's another one.
>
> Avoid ad-hominem attacks against people who have professional
> reputations you could only dream about having. People such as
> Pete Becker.

Argumento ad hominem does not refer to disagreeing with someone in a rude way.

One perfect example of ad hominem would be something like ``whatever P___ B___
writes is holy scripture because of /who/ he is and his professional
reputation, not because of what is actually written''.

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

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

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

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

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

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

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

soft and program

Tuesday, December 29, 2009

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

No comments:

Blog Archive

About Me