Saturday, November 29, 2008

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

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

comp.lang.c++@googlegroups.com

Today's topics:

* binary format of the number. - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/bf11dd6e68624537?hl=en
* Who gets higher salary a Java Programmer or a C++ Programmer? - 16 messages,
5 authors
http://groups.google.com/group/comp.lang.c++/t/4017272356b778c8?hl=en
* Object pointer casted to int* , wont increment with ++ - 2 messages, 2
authors
http://groups.google.com/group/comp.lang.c++/t/56fc5b72c8602df0?hl=en
* The Java vs C++ higher salary thread - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/be2a8dac2cb503c3?hl=en
* question about private member - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/a6df0a5b67849ef0?hl=en
* dealing with large csv files - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/67015284d3d3652f?hl=en
* ===Welcome to comp.lang.c++! Read this first. - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/d1056f435c150129?hl=en

==============================================================================
TOPIC: binary format of the number.
http://groups.google.com/group/comp.lang.c++/t/bf11dd6e68624537?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Nov 29 2008 1:25 pm
From: George Kettleborough


On 28/11/08 09:19, Tarmo Kuuse wrote:
> Bill wrote:
>> Why would you prefer to write down strings of 0s and 1s anyway? Seems like
>> it would increase your chance of error. If you really wanted to, you could
>> write your own function which translates binary character strings to an
>> integral data type. For instance, int binary2Int(const char *).
>
> When working at low level (embedded, device drivers, ...), bit fields
> are scattered throughout code. It is quite annoying to convert binary to
> hexadecimal and vice versa for 32-bit values.
>
> Let's see now, is bit 22 set in mask 0x03C00000? OK, give me a minute...

For bit fields wouldn't it be a lot easier to use vector<bool>?

--
George Kettleborough


== 2 of 3 ==
Date: Sat, Nov 29 2008 1:37 pm
From: Pete Becker


On 2008-11-29 16:25:24 -0500, George Kettleborough
<g.kettleborough@member.fsf.org> said:

> On 28/11/08 09:19, Tarmo Kuuse wrote:
>> Bill wrote:
>>> Why would you prefer to write down strings of 0s and 1s anyway? Seems like
>>> it would increase your chance of error. If you really wanted to, you could
>>> write your own function which translates binary character strings to an
>>> integral data type. For instance, int binary2Int(const char *).
>>
>> When working at low level (embedded, device drivers, ...), bit fields
>> are scattered throughout code. It is quite annoying to convert binary to
>> hexadecimal and vice versa for 32-bit values.
>>
>> Let's see now, is bit 22 set in mask 0x03C00000? OK, give me a minute...
>
> For bit fields wouldn't it be a lot easier to use vector<bool>?

No. vector<bool> doesn't require any particular representation. Device
drivers, etc. typically need a particular bit set or cleared. That's
usually done with bitfields (implementation-dependent) or with masks.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

== 3 of 3 ==
Date: Sat, Nov 29 2008 4:36 pm
From: "Bill"

"George Kettleborough" <g.kettleborough@member.fsf.org> wrote in message
news:7riYk.16560$8r3.8950@newsfe24.ams2...
> On 28/11/08 09:19, Tarmo Kuuse wrote:
>> Bill wrote:
>>> Why would you prefer to write down strings of 0s and 1s anyway? Seems
>>> like
>>> it would increase your chance of error. If you really wanted to, you
>>> could
>>> write your own function which translates binary character strings to an
>>> integral data type. For instance, int binary2Int(const char *).
>>
>> When working at low level (embedded, device drivers, ...), bit fields
>> are scattered throughout code. It is quite annoying to convert binary to
>> hexadecimal and vice versa for 32-bit values.
>>
>> Let's see now, is bit 22 set in mask 0x03C00000? OK, give me a minute...
>
> For bit fields wouldn't it be a lot easier to use vector<bool>?

Easier for the programmer or the processor? I suspect that people who write
software for embedded devices avoid such data strucutres. I could be wrong.

Bill


>
> --
> George Kettleborough

==============================================================================
TOPIC: Who gets higher salary a Java Programmer or a C++ Programmer?
http://groups.google.com/group/comp.lang.c++/t/4017272356b778c8?hl=en
==============================================================================

== 1 of 16 ==
Date: Sat, Nov 29 2008 1:40 pm
From: LR


James Kanze wrote:
> On Nov 29, 5:27 pm, LR <lr...@superlink.net> wrote:

>> Also, AFAICR all of the sciences have some relation to an
>> engineering discipline, or at least off hand I can't think of
>> one that doesn't. What engineering disciplines are the three
>> things you named related to?
>
> [snip] Engineering and
> science tend to subdivide differently.

I think there's a possibility that you didn't understand what I meant,
and I'm certain that I don't understand what you mean. So could you
please expand on that?

LR


== 2 of 16 ==
Date: Sat, Nov 29 2008 1:43 pm
From: LR


James Kanze wrote:

> It depends on what the application is. Someone writing a pay
> program in Cobol isn't very far from the brick layer.

Their status doesn't depend on their methodology? It's the application
and language that drive that?

Could you please clarify this?

LR


== 3 of 16 ==
Date: Sat, Nov 29 2008 1:50 pm
From: LR


Martin Gregorie wrote:
> On Sat, 29 Nov 2008 11:44:22 -0500, LR wrote:

>> "Most movies are constructed out of bits and pieces of other movies,
>> like little engines built from cinematic Erector sets."
>>
> Thats somewhat of a red herring.

Yeah, ok, a little bit of one.


>
>> Is there any reason in principle why C++ code can't run on a machine?

[I snipped the part about interpreters because that's not exactly what I
was asking above]

> I don't think anybody could design and build hardware that could act
> directly on a C++ source file (or any other language for that matter) but
> in any case doing that would be hideously expensive and you'd end up with
> hardware that could only run one particular version of one programming
> language.

I don't think anyone _would_. I was asking if it could be done in
principle. I think that the answer is yes.

LR


== 4 of 16 ==
Date: Sat, Nov 29 2008 1:54 pm
From: LR


blmblm@myrealbox.com wrote:
> In article <49316d1b$0$19155$cc2e38e6@news.uslec.net>,
> LR <lruss@superlink.net> wrote:
>> James Kanze wrote:
>>> On Nov 29, 4:04 am, LR <lr...@superlink.net> wrote:
>
> [ snip ]
>
>> It's less clear to me, perhaps because I don't know enough about them
>> that psychology and sociology are sciences.
>
> Is this where someone should mention the joke(?) about how anything
> with "science" in its name isn't one ..... As I heard it, the
> is-it-a-joke continues along these lines: "Think about it --
> social science? political science? hm, computer science?"

Good one!

> Not taking sides in this argument, mostly lurking and observing
> with interest.

That's good to know.

LR


== 5 of 16 ==
Date: Sat, Nov 29 2008 2:22 pm
From: LR


Lew wrote:
> James Kanze wrote:
>> Sorry, but telling someone in public you're a doctor when you
>> don't meet the legal qualifications is illegal.
>
> I'm a doctor.
>
> :-)
>
> --
> Lew
> Doctor of love.

Very amusing.

I can't recall who said it,
I know I never read it,
but here's a grand quote: "The law is blunt instrument."

You may want to search for it at google.


IANAL

LR


== 6 of 16 ==
Date: Sat, Nov 29 2008 2:24 pm
From: Tom Anderson


On Sat, 29 Nov 2008, James Kanze wrote:

> On Nov 29, 5:41 pm, "Daniel T." <danie...@earthlink.net> wrote:
>> James Kanze <james.ka...@gmail.com> wrote:
>>> On Nov 29, 2:57 am, "Daniel T." <danie...@earthlink.net> wrote:
>>>> I argue that C++/Java programmers do help design the application.
>>>
>>> But doesn't this depend on the process.  In most cases I've
>>> seen, the software developers are responsible for many
>>> aspects of low level design.  But it's not a given; a
>>> process could have a separate design team, which specified
>>> everything in detail, to the point where the developers only
>>> had to "pisser les lignes"; there responsibility wouldn't be
>>> much more than that of a bricklayer.
>
>> Many orginazations have attempted to relegate the programmer
>> to "brick layer" status. The effort has been so phenomenally
>> unsuccessful that there has been a backlash and now even
>> attempts at reasonable high-level design are often met with
>> derision.
>
> It depends on what the application is. Someone writing a pay
> program in Cobol isn't very far from the brick layer.

Or, in the java world, someone writing a straightforward CRUD application
which just puts a web interface on a database.

tom

--
This is your life and it's ending one minute at a time.

== 7 of 16 ==
Date: Sat, Nov 29 2008 2:29 pm
From: LR


Martin Gregorie wrote:
> On Sat, 29 Nov 2008 11:47:55 -0500, LR wrote:
>
>> Then please allow me to ask what an engineer should do if a client wants
>> an analysis done on the resonant frequency of a bridge, but not any work
>> done on wind loading,
>>
> If the client has asked for an analysis then presumably the bridge
> already exists and the project is simply to measure what the client wants
> measured or inspected.

Or it could be that this particular work is being subcontracted?

>
> If the bridge doesn't exist then its a design project.

The engineer who is contracted for the work, might not know that.

> Don't forget that all major civil engineering projects are one-off
> structures: its very unlikely that anybody has previously built this type
> of object on this spot using the specified materials and methods.

Yes. In that way, I think that software development is like engineering.
Lots of people make word processors but very few with the same
language or interface.

>> would be, let's call it static deck loading, or transient deck loading.
>>
> I'm not a civil engineer, but deck loadings would be determined entirely
> by traffic predictions and the bridge building regulations in force at
> the site. These are design constraints rather that things to be analysed.

Sorry, perhaps I wasn't clear. The design would be analyzed to see if
it meant those design constraints, wouldn't it?

>> Or another fluids problem bridges encounter, water on their supports.
>> Can an engineer take that work?
>>
> Same considerations apply, except that an analysis of the effect of water
> on the mid-stream supports is most likely to involve divers making an
> inspection after the bridge has been in place long enough to have settled
> down and for flow disturbances from the supports to have modified the
> river bed.

But there would be upfront analysis of the water on the supports,
wouldn't there? Perhaps even models built?

I would imagine that would be very specialized work, and a bridge
designer might not have all those facilities in house. If so, then I
guess there's some interesting opportunity for passing on only partial
information about how the supports might deform under high wind conditions.

LR

== 8 of 16 ==
Date: Sat, Nov 29 2008 2:31 pm
From: "Daniel T."


James Kanze <james.kanze@gmail.com> wrote:
> On Nov 29, 5:41 pm, "Daniel T." <danie...@earthlink.net> wrote:
> > James Kanze <james.ka...@gmail.com> wrote:
> > > On Nov 29, 2:57 am, "Daniel T." <danie...@earthlink.net> wrote:

> > > > I argue that C++/Java programmers do help design the
> > > > application.
> > >
> > > But doesn't this depend on the process.  In most cases I've
> > > seen, the software developers are responsible for many aspects
> > > of low level design.  But it's not a given; a process could have
> > > a separate design team, which specified everything in detail, to
> > > the point where the developers only had to "pisser les lignes";
> > > there responsibility wouldn't be much more than that of a
> > > bricklayer.
> >
> > Many orginazations have attempted to relegate the programmer to
> > "brick layer" status. The effort has been so phenomenally
> > unsuccessful that there has been a backlash and now even attempts
> > at reasonable high-level design are often met with derision.
>
> It depends on what the application is. Someone writing a pay
> program in Cobol isn't very far from the brick layer.

I guess some applications don't require much design in general. I may
have to concede the point simply because of my lack of experience. I
have only ever worked in the video game industry.


== 9 of 16 ==
Date: Sat, Nov 29 2008 2:33 pm
From: Tom Anderson


On Sat, 29 Nov 2008, Martin Gregorie wrote:

> On Sat, 29 Nov 2008 11:44:22 -0500, LR wrote:
>
>> Is there any reason in principle why C++ code can't run on a machine?
>
> That's been done for Algol 68,

A machine that ran Algol 68 *source*? That sounds fascinating - could you
tell me any more about it?

> so in theory you could write a C++ interpreter, but it would probably be
> complex and slow. Doing this wouldn't sidestep any of the correctness
> issues posed by the compiler and, indeed, would probably add some
> extras.

Yes, i struggle to imagine how you could do it without having what would
effectively be software somewhere in the middle.

Languages like FORTH are more plausibly implemented in hardware.

> I don't think anybody could design and build hardware that could act
> directly on a C++ source file (or any other language for that matter)
> but in any case doing that would be hideously expensive and you'd end up
> with hardware that could only run one particular version of one
> programming language. You want Java or COBOL as well? Thats two more
> chunks of hardware to be built from the ground up.

Since there's at least one JVM written in C++, not so.

tom

--
This is your life and it's ending one minute at a time.


== 10 of 16 ==
Date: Sat, Nov 29 2008 2:39 pm
From: LR


Keith H Duggar wrote:

> The Four Color Theorem is an enjoyable and clear example of
> mathematics describing a physical phenomenon.

I don't think anyone ever, or at least not since Newton, suggested that
quite a bit of math wasn't invented (or discovered, or whatever word
will suffice here, because I read somewhere, I don't remember where,
that this is under some debate too) in order to describe real world
phenomena.

But even if that is the case, the math doesn't have to be about
something real.

The Four Color Theorem may have been proven to answer a real world
question, but did the proof use a map of the counties of Texas?

LR


== 11 of 16 ==
Date: Sat, Nov 29 2008 3:27 pm
From: Lew


LR wrote:
> IANAL

IAAL.

--
Lew


== 12 of 16 ==
Date: Sat, Nov 29 2008 3:38 pm
From: LR


Daniel T. wrote:
> James Kanze <james.kanze@gmail.com> wrote:

>> It depends on what the application is. Someone writing a pay
>> program in Cobol isn't very far from the brick layer.
>
> I guess some applications don't require much design in general.

I don't think that payroll is one of those. Payroll is one of those
apps with an "arbitrary" set of rules to follow. Things like the place
an individual works, where they reside, what kind of work they do,
possibly even their physical characteristics, might all make a
difference to how the app should handle that case.

Payroll is also different from some kinds of engineering apps, and I
suspect games as well, in that your results had better work to the penny
or cent or farthing. Otherwise angry hourly workers with pitchforks and
torches will show up at your cubicle. There's no margin of error for
safety, either the compensation and deductions are right or not.

And I suspect that lots of, well, let's call them "bricks and mortar"
apps, have to work this way. Imagine for example the work for figuring
the basis points for tax purposes for a sale of AT&T stock, where much
of it was purchased in some sort of reinvestment plan and where some of
the purchased stock has already been sold.

Honestly, I don't understand why anyone would think why someone doing
these apps is close to being what is implied here by "brick layer",
unless the person writing the app is doing it completely by the seat of
their pants.

No one speaks of an engineer who works on nuts and bolts as being close
to a brick layer. So I'm curious about this, because I don't understand it.

But then, the one of the few people I've met who was working on payroll
and whose programming skills were described by other people working with
him in a somewhat derogatory manner had a background in mech engineering.


> I may
> have to concede the point simply because of my lack of experience. I
> have only ever worked in the video game industry.

Full of its own set of complications, I'd bet.

LR


== 13 of 16 ==
Date: Sat, Nov 29 2008 4:39 pm
From: Martin Gregorie


On Sat, 29 Nov 2008 17:29:30 -0500, LR wrote:

>
> Sorry, perhaps I wasn't clear. The design would be analyzed to see if
> it meant those design constraints, wouldn't it?
>
I'm guessing here, but I think it would be designed so it doesn't
resonate as an integral part of the design phase, which could easily be
an iterative process, rather than having recognisable 'design' and
'analyse' phases.

If structural analysis was subcontracted during the design that's not, in
principle, different from passing that section of the job to a specialist
within the design team.


>
>
>>> Or another fluids problem bridges encounter, water on their supports.
>>> Can an engineer take that work?
>>>
>> Same considerations apply, except that an analysis of the effect of
>> water on the mid-stream supports is most likely to involve divers
>> making an inspection after the bridge has been in place long enough to
>> have settled down and for flow disturbances from the supports to have
>> modified the river bed.
>
> But there would be upfront analysis of the water on the supports,
> wouldn't there? Perhaps even models built?
>
One would hope so, but the unexpected can happen. Suppose the bridge is
downstream of a volcano and a lahar had occurred. For an example, see:

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

or better yet, Google for "tangiwai disaster" and look at the image
results. This is the sort of thing that can't be readily calculated in
advance, since the composition and volume of the flow will vary between
events on the same mountain and (I think) between successive events in
the same stream bed.

> I would imagine that would be very specialized work, and a bridge
> designer might not have all those facilities in house. If so, then I
> guess there's some interesting opportunity for passing on only partial
> information about how the supports might deform under high wind
> conditions.
>
If wind speeds at the site are known, and weather records should be able
to provide that data in much of the world, wind loadings and safety
margins are calculable.

--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |


== 14 of 16 ==
Date: Sat, Nov 29 2008 4:43 pm
From: Martin Gregorie


On Sat, 29 Nov 2008 20:33:39 +0000, blmblm@myrealbox.com wrote:

> In article <ggrost$fcp$1@localhost.localdomain>, Martin Gregorie
> <martin@see.sig.for.address.invalid> wrote:
>> On Sat, 29 Nov 2008 10:35:53 -0500, LR wrote:
>>
>> > Martin Gregorie wrote:
>> >> On Fri, 28 Nov 2008 14:16:19 -0500, LR wrote:
>
> [ snip ]
>
>> BTW, Cheney should not have been rubbished for his "unknown unknowns":
>
> Nitpick: Wasn't that Donald Rumsfeld, and the wording was slightly
> different .... Or maybe they both said something along those lines.
>
Yes, you're right. It was a longer statement but 'unknown unknowns' was
part of it and IIRC that was the bit the meeja picked on as a
particularly stupid thing to say.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |


== 15 of 16 ==
Date: Sat, Nov 29 2008 4:53 pm
From: "Daniel T."


LR <lruss@superlink.net> wrote:
> Daniel T. wrote:
> > James Kanze <james.kanze@gmail.com> wrote:
>
> > > It depends on what the application is. Someone writing a pay
> > > program in Cobol isn't very far from the brick layer.
> >
> > I guess some applications don't require much design in general.
>
> I don't think that payroll is one of those. Payroll is one of those
> apps with an "arbitrary" set of rules to follow. Things like the
> place an individual works, where they reside, what kind of work they
> do, possibly even their physical characteristics, might all make a
> difference to how the app should handle that case.
>
> Payroll is also different from some kinds of engineering apps, and I
> suspect games as well, in that your results had better work to the
> penny or cent or farthing. Otherwise angry hourly workers with
> pitchforks and torches will show up at your cubicle. There's no
> margin of error for safety, either the compensation and deductions
> are right or not.
>
> And I suspect that lots of, well, let's call them "bricks and
> mortar" apps, have to work this way. Imagine for example the work
> for figuring the basis points for tax purposes for a sale of AT&T
> stock, where much of it was purchased in some sort of reinvestment
> plan and where some of the purchased stock has already been sold.
>
> Honestly, I don't understand why anyone would think why someone
> doing these apps is close to being what is implied here by "brick
> layer", unless the person writing the app is doing it completely by
> the seat of their pants.
>
> No one speaks of an engineer who works on nuts and bolts as being
> close to a brick layer. So I'm curious about this, because I don't
> understand it.
>
> But then, the one of the few people I've met who was working on
> payroll and whose programming skills were described by other people
> working with him in a somewhat derogatory manner had a background in
> mech engineering.

My next door neighbor works on credit card processing programs for a
major bank. He makes more money than me (about twice as much,) but oddly
assumes I'm a more skilled engineer... Take that as you will.

> > I may have to concede the point simply because of my lack of
> > experience. I have only ever worked in the video game industry.
>
> Full of its own set of complications, I'd bet.

Talk about arbitrary, we have complications just for the sake of having
them.

"Why does this part of the game have to work so different from that
part? They are effectively the same thing."

"Because that would be boring."


== 16 of 16 ==
Date: Sat, Nov 29 2008 5:08 pm
From: Martin Gregorie


On Sat, 29 Nov 2008 22:33:15 +0000, Tom Anderson wrote:

> A machine that ran Algol 68 *source*? That sounds fascinating - could
> you tell me any more about it?
>
No, an interpreter: http://www.xs4all.nl/~jmvdveer/algol.html

I haven't tried using it, but I maintain an interest since back in 1977 I
rewrote the George 3 job accounting program in Algol 68R and I liked the
language a lot.

>> so in theory you could write a C++ interpreter, but it would probably
>> be complex and slow. Doing this wouldn't sidestep any of the
>> correctness issues posed by the compiler and, indeed, would probably
>> add some extras.
>
> Yes, i struggle to imagine how you could do it without having what would
> effectively be software somewhere in the middle.
>
You might choose to microcode it, even though thats not really a hardware
implementation, since that's good way to handle complex machine
architectures at a much lower level than the JVM.

The ancient Burroughs B6700 was a classic example: each language it ran
had its own specialised VM though they were still compiled languages: it
used a byte-addressed VM, optimised for string operations for COBOL and a
word-addressed stack oriented VM for running Algol 60 and FORTRAN. It
doesn't take a lot of imagination to generalize that into a set of VMs
that could interpret source code.

> Languages like FORTH are more plausibly implemented in hardware.
>
FORTH is dead easy: the 6809 port has about 100 machine code instructions
making up the 20-30 lowest level words that form the guts of the
interpreter. Everything else is written in pure FORTH and interpreted at
run time. Unfortunately, its one of the two classic examples of a write-
only language (APL is the other) and not helped by the attitude that
"real FORTH programmers don't write comments and keep all variables on
the stack".


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

==============================================================================
TOPIC: Object pointer casted to int* , wont increment with ++
http://groups.google.com/group/comp.lang.c++/t/56fc5b72c8602df0?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Nov 29 2008 3:43 pm
From: juanvicfer


> > If I change line 46 to:
>
> >         double *pd = (double *)((int *)px1++);
>
> > The pointer doesn't increment as shown by the output at stdout.
>
> Doesn't increment? Sorry, but that doesn't make any sense. Nowhere in
> your code after line 46 I see anything that would demonstrate whether
> the pointer got incremented or not. You don't output the new value of
> 'px1', you don't output anything that depends on the new value of 'px1'.
> What made you conclude that it doesn't increment then?

I suppose that he is expecting to have the address of px1 + size_of
(int);

This can be achieved with the following expression:

double *pd = (double *)(++(int *)px1);

, although the behaviour is undefined in this case


Regards


== 2 of 2 ==
Date: Sat, Nov 29 2008 5:07 pm
From: "Thomas J. Gritzan"


juanvicfer wrote:
>>> If I change line 46 to:
>>> double *pd = (double *)((int *)px1++);
>>> The pointer doesn't increment as shown by the output at stdout.
>> Doesn't increment? Sorry, but that doesn't make any sense. Nowhere in
>> your code after line 46 I see anything that would demonstrate whether
>> the pointer got incremented or not. You don't output the new value of
>> 'px1', you don't output anything that depends on the new value of 'px1'.
>> What made you conclude that it doesn't increment then?
>
> I suppose that he is expecting to have the address of px1 + size_of
> (int);
>
> This can be achieved with the following expression:
>
> double *pd = (double *)(++(int *)px1);

This doesn't (or should not) compile. (int*)px1 yields an rvalue in this
case, but the increment operator only works on lvalues, because it
changes the operand.

> , although the behaviour is undefined in this case

--
Thomas

==============================================================================
TOPIC: The Java vs C++ higher salary thread
http://groups.google.com/group/comp.lang.c++/t/be2a8dac2cb503c3?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Nov 29 2008 3:49 pm
From: Jack Klein


On Sat, 29 Nov 2008 19:27:15 GMT, Zjargands <Zjargands@gmail.com>
wrote in comp.lang.c++:

> Can we, as a group, please stop posting to this thread? It has over 100
> posts, many of them (most) unrelated to the original question or simply
> restatements of what others have already said.
>
> Many of the sub threads have devolved into arguments between 2 or three
> people going back and forth with petty arguments that should be resolved
> in private e-mail.
>
> A good example would be the "what constitutes an engineer" sub thread.
> This topic has nothing to do with c++.
>
> Thank you for your constructive comments and consideration.
>
>
> --------------enig04EA43C58B861B7CEE0EB849
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: OpenPGP digital signature
> Content-Disposition: attachment; filename="signature.asc"
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkkxl5AACgkQlsOBXZ7DoXYYbwCggSISk6QZnHxj2oeBaMcXWImW
> Eq0An1Go2LDf8CBJfoZ2q5HdqQoX9eNS
> =ARf3
> -----END PGP SIGNATURE-----
>
> --------------enig04EA43C58B861B7CEE0EB849--

Can we, as a group, and you, as an individual, please stop posting
MIME encoded crap like this to text-only usenet groups?

If you think there is any useful purpose at all to PGP signatures on
usenet, you are mistaken.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

==============================================================================
TOPIC: question about private member
http://groups.google.com/group/comp.lang.c++/t/a6df0a5b67849ef0?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Nov 29 2008 4:13 pm
From: Juha Nieminen


zhangyefei.yefei@gmail.com wrote:
> according to Principle of Encapsulation ,a boject can not access other
> object's private memeber.

How would you implement a copy constructor or copy assignment operator
if an object cannot access the private members of another object of the
same type?

If you have a pointer to an object of the same type as the current
one, how would the compiler know if that pointer is pointing to another
object or to 'this'?

==============================================================================
TOPIC: dealing with large csv files
http://groups.google.com/group/comp.lang.c++/t/67015284d3d3652f?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Nov 29 2008 6:04 pm
From: brzak


hi

I was hoping for a few pointers on how to best go about
processing large csv files.

The files:
a typical file has 100K-500K records
approx 150 chars per line (10 'fields')
so file sizes of 15MB-75MB.

The processing:
summarise numerical fields based on conditions applied to other
fields

the resulting summary is a table;
the column headers of which are the list of unique values of one
field
the row headers are decided upon by conditions on other fields
(this may include lookups, exclusions, reclassifications)

Taking into account the size of the files, and number of operations
requierd on each record...

What if any of thse considerations do I need to take into account:

-is the file read in line by line / or in one go?
+if in one go, there would be issues with available memory?
+if it's line by line, is tehre a significant difference in time
taken to process? (i.e from my limited personal experience with
VBA, reading/writing a cell at a time in a spreasheet is far
slower than reading/writing in 'batches')
+or would it be an idea to read a limited number in one go?
e.g. deal with 20,000 at a time in memory
i suppose this question demonstrates a lack of experience with C++
but hey, that's why i'm posting in the learner's forum :)

-however much of the file is read, is it worth writing a bespoke
solution
or look for a parser/class that's been written for csv files?
+perhaps there is a module that i can import?
+since the csv files are *supposed* to be of a standard format,
would
there be much to gain iin writing something specific to this - this
would be done with the aim of reducing processing time

-data types... should i read the value fields as floating point
numbers (range approx. +/- 500000.00)
+will using floating point data types save memory?


As anyone reading would be able to tell, I'm still quite new to this
language, and am missing some of the basics which I've had a bit of
trouble locating solutions to.

Any advice would be much appreciated!

Brz

==============================================================================
TOPIC: ===Welcome to comp.lang.c++! Read this first.
http://groups.google.com/group/comp.lang.c++/t/d1056f435c150129?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Nov 29 2008 9:29 pm
From: Shiva


Welcome to comp.lang.c++! Read this first.

This post is intended to give the new reader an introduction to reading
and posting in this newsgroup. We respectfully request that you read
all the way through this post, as it helps make for a more pleasant
and useful group for everyone.

First of all, please keep in mind that comp.lang.c++ is a group for discussion
of general issues of the C++ programming language, as defined by the ANSI/ISO
language standard. If you have a problem that is specific to a particular system
or compiler, you are much more likely to get complete and accurate answers in a
group that specializes in your platform. A listing of some newsgroups is given
at the end of this post.

The FAQ (Frequently Asked Question) list has a wealth of information for
both the new and veteran C++ programmer. No matter what your experience
level, you are encouraged to read the entire list, if only to familiarize
yourself with what answers are available to minimize redundant replies.
The comp.lang.c++ FAQ is available at http://www.parashift.com/c++-faq-lite/

If the FAQ list does not help, then many regular readers of this group
are happy to assist with problems of standard C++. We have only a few
requests that we ask be adhered to, for the benefit of all:

* Please put a short summary in the subject line. Descriptions such as
"HELP!!!!!!" are not helpful, and many regular posters ignore such
requests. A good example is, "Problem with Virtual Functions."

* State the question or the problem clearly and concisely. Describe what
you are trying to do, and the problem you are running into. Include all
relevant error messages.

* Include the smallest, complete and compilable program that exhibits your
problem. As a rule, posters in comp.lang.c++ will not do homework, but will
give helpful hints if you have shown some willingness to try a solution.

* comp.lang.c++ is forum for discussion, and as such some regular posters do
not give E-mail replies. Very often follow-ups to postings have corrections,
so plan on taking part in the discussion if you post a question. If you
do receive e-mail replies, it is considered polite to post a summary.

* Don't post in HTML format. Many readers of this newsgroup don't use
newsreaders which can handle HTML postings.

* If you have to include source code in your post, include the
source in the message body. Don't use attachments. A lot
of contributors to this newsgroup won't even notice the existence
of attachments or won't open them. You try to get any help
you can get, don't you?

Some netiquette topics which frequently crop up on comp.lang.c++ are
also answered in the FAQ.

* Should I post job advertisements and/or resumes on comp.lang.c++?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.10

* What if I really need a job; should I post my resume on comp.lang.c++?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.11

* What should I do to someone who posts something off-topic?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.12

A note on comp.lang.c++ etiquette: Accuracy is valued very highly in this
newsgroup; therefore posts are frequently corrected, sometimes perhaps
too harshly, and often to the annoyance of new posters who consider the
correction trivial. Do not take it personally; the best way to fit in
with comp.lang.c++ is to express gratitude for the correction, move on,
and be more careful next time.

This is a very busy group, so these requests are designed to make it as
pleasant and efficient an experience as possible. We hope it proves
a valuable commodity to you.

A list of some Newsgroups :
Languages and Programming
-------------------------
comp.lang.c The C Programming Language
comp.lang.asm.x86 x86 assembly language programming
comp.programming Non-language specific programming
comp.graphics.algorithms Issues of computer graphics

Operating Systems
-----------------
comp.os.msdos.programmer DOS, BIOS, Memory Models, interrupts,
screen handling, hardware
comp.os.ms-windows.programmer.win32 MS/Windows: Mice, DLLs, hardware
comp.os.os2.programmer.misc OS/2 Programming
comp.sys.mac.programmer.misc Macintosh Programming
comp.unix.programmer General Unix: processes, pipes, POSIX,
curses, sockets
comp.unix.[vendor] Various Unix vendors

Microsoft VC++
-------------
microsoft.public.vc.language VC++ issues
microsoft.public.vc.mfc MFC Issues
microsoft.public.dotnet.languages.vc C++/CLR Issues
microsoft.public.dotnet.framework .Net Framework


Borland C++ Builder
-------------------
borland.public.cppbuilder.language Borland C++ Builder
borland.public.cpp.language
borland.public.cppbuilder

-Shiva
http://www.slack.net/~shiva/welcome.txt


Sun Nov 30 00:30:00 EST 2008

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

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

No comments: