Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #118220 > unrolled thread

“We are doomed”

Back to article view | Back to comp.lang.c++

Contents

  “We are doomed” Lynn McGuire <lynnmcguire5@gmail.com> - 2024-01-16 16:03 -0600
    Re: “We are doomed” Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-19 18:17 +0000
      Re: “We are doomed” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-19 18:35 +0000
        Re: “We are doomed” Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-20 13:59 +0000
          Re: “We are doomed” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-20 11:22 -0800
          Re: “We are doomed” Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 04:06 +0000
            Re: “We are doomed” Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-22 11:22 +0000
              Re: “We are doomed” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-22 12:22 -0800
      Re: “We are doomed” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-19 13:58 -0800
      Re: “We are doomed” immibis <news@immibis.com> - 2024-01-22 01:22 +0100
        Re: “We are doomed” Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-22 11:16 +0000
          Re: “We are doomed” "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-01-22 12:34 +0100
            Re: “We are doomed” Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-22 12:31 +0000
          Re: “We are doomed” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-22 12:24 -0800
          Re: “We are doomed” MarioCCCP <NoliMihiFrangereMentulam@libero.it> - 2024-01-31 01:17 +0100

#118220 — “We are doomed”

“We are doomed”
    https://www.carette.xyz/posts/we_are_doomed/

“The only system with a good software compatibility that I know is 
Windows, and this explains a ton of things keeping very old UI/UX 
frameworks, software and APIs to run, for example, Windows 95 compatible 
games like “Roller Coaster Tycoon”.”

“Otherwise, you are doomed.”

The C++ committee has screwed up and continues to screw up by not 
creating a graphics standard for C++.

Lynn

[toc] | [next] | [standalone]

#118229

On 16/01/2024 22:03, Lynn McGuire wrote:
> “We are doomed”
>     https://www.carette.xyz/posts/we_are_doomed/
> 
> “The only system with a good software compatibility that I know is 
> Windows, and this explains a ton of things keeping very old UI/UX 
> frameworks, software and APIs to run, for example, Windows 95 compatible 
> games like “Roller Coaster Tycoon”.”
> 
> “Otherwise, you are doomed.”
> 
> The C++ committee has screwed up and continues to screw up by not 
> creating a graphics standard for C++.
> 
> Lynn
One problem that could be very easily fixed is that there is no standard 
representation of a point or a vector. Whilst generally it's just a POD 
structure with x and y members, the name varies, and sometimes the 
dimensions are referred to by index instead of by letter. You can also 
have a philosophical discussion about whether points and vectors should 
be the same structures or incompatible structures.
But a simple standardisation would mean the end of pointless editing of 
code just to conform to whatever the host program has chosen.
-- 
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

[toc] | [prev] | [next] | [standalone]

#118230

On 2024-01-19, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> One problem that could be very easily fixed is that there is no standard 
> representation of a point or a vector. Whilst generally it's just a POD 
> structure with x and y members, the name varies, and sometimes the 

For code working with 2D vectors, designers should consider complex numbers.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

[toc] | [prev] | [next] | [standalone]

#118232

On 19/01/2024 18:35, Kaz Kylheku wrote:
> On 2024-01-19, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> One problem that could be very easily fixed is that there is no standard
>> representation of a point or a vector. Whilst generally it's just a POD
>> structure with x and y members, the name varies, and sometimes the
> 
> For code working with 2D vectors, designers should consider complex numbers.
> 
That's a nice idea.

But I've never seen code where the horizontal axis is "real" and the 
vertical "imaginary", except of course in code designed to demonstrate 
complex numbers as such. Mandelbrot is my favourite test program when 
getting a new system.

-- 
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

[toc] | [prev] | [next] | [standalone]

#118233

On 1/20/2024 5:59 AM, Malcolm McLean wrote:
> On 19/01/2024 18:35, Kaz Kylheku wrote:
>> On 2024-01-19, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>> One problem that could be very easily fixed is that there is no standard
>>> representation of a point or a vector. Whilst generally it's just a POD
>>> structure with x and y members, the name varies, and sometimes the
>>
>> For code working with 2D vectors, designers should consider complex 
>> numbers.
>>
> That's a nice idea.
> 
> But I've never seen code where the horizontal axis is "real" and the 
> vertical "imaginary", except of course in code designed to demonstrate 
> complex numbers as such. Mandelbrot is my favourite test program when 
> getting a new system.
> 

Same here! :^D

[toc] | [prev] | [next] | [standalone]

#118235

On 2024-01-20, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On 19/01/2024 18:35, Kaz Kylheku wrote:
>> On 2024-01-19, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>> One problem that could be very easily fixed is that there is no standard
>>> representation of a point or a vector. Whilst generally it's just a POD
>>> structure with x and y members, the name varies, and sometimes the
>> 
>> For code working with 2D vectors, designers should consider complex numbers.
>> 
> That's a nice idea.
>
> But I've never seen code where the horizontal axis is "real" and the 
> vertical "imaginary", except of course in code designed to demonstrate 
> complex numbers as such. Mandelbrot is my favourite test program when 
> getting a new system.

Complex numbers are used for expressing mappings that have geometric
interpretations.

In 2D computer graphics, they are convenient. E.g. to rotate
a vector that is a complex number z = a + ib, you just multiply by
a complex number that is on the unit circle representing that
angle   cos(theta) + i sin(theta) .

The multiplication math is exactly the same as

  [ cos -sin ] [ a ]
  [ sin  cos ] [ b ]

Because when you multiply two complex nubmers (c + id)(a + ib),
the FOIL rule produces 

   ca + icb + ida + iidb
   
  = (ca - db) + i(cb + da).

And that's just

  [ c  -d ] [ a ]  =  [ ca - db ]
  [ d   c ] [ b ]  =  [ da + cb ]

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

[toc] | [prev] | [next] | [standalone]

#118240

On 21/01/2024 04:06, Kaz Kylheku wrote:
> On 2024-01-20, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> On 19/01/2024 18:35, Kaz Kylheku wrote:
>>> On 2024-01-19, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>>> One problem that could be very easily fixed is that there is no standard
>>>> representation of a point or a vector. Whilst generally it's just a POD
>>>> structure with x and y members, the name varies, and sometimes the
>>>
>>> For code working with 2D vectors, designers should consider complex numbers.
>>>
>> That's a nice idea.
>>
>> But I've never seen code where the horizontal axis is "real" and the
>> vertical "imaginary", except of course in code designed to demonstrate
>> complex numbers as such. Mandelbrot is my favourite test program when
>> getting a new system.
> 
> Complex numbers are used for expressing mappings that have geometric
> interpretations.
> 
> In 2D computer graphics, they are convenient. E.g. to rotate
> a vector that is a complex number z = a + ib, you just multiply by
> a complex number that is on the unit circle representing that
> angle   cos(theta) + i sin(theta) .
> 
> The multiplication math is exactly the same as
> 
>    [ cos -sin ] [ a ]
>    [ sin  cos ] [ b ]
> 
> Because when you multiply two complex nubmers (c + id)(a + ib),
> the FOIL rule produces
> 
>     ca + icb + ida + iidb
>     
>    = (ca - db) + i(cb + da).
> 
> And that's just
> 
>    [ c  -d ] [ a ]  =  [ ca - db ]
>    [ d   c ] [ b ]  =  [ da + cb ]
> 
Yes I know. I did complex numbers at high school.

But whilst you could use the Argand plane as your graphics surface and 
thus represent all points as complex numbers, I've never actually seen 
anyone do so, and the axes are always given different labels. Except of 
course in Mandelbrots or other programs concerned with complex numbers 
themselves.
-- 
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

[toc] | [prev] | [next] | [standalone]

#118243

On 1/22/2024 3:22 AM, Malcolm McLean wrote:
> On 21/01/2024 04:06, Kaz Kylheku wrote:
>> On 2024-01-20, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>> On 19/01/2024 18:35, Kaz Kylheku wrote:
>>>> On 2024-01-19, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>>>> One problem that could be very easily fixed is that there is no 
>>>>> standard
>>>>> representation of a point or a vector. Whilst generally it's just a 
>>>>> POD
>>>>> structure with x and y members, the name varies, and sometimes the
>>>>
>>>> For code working with 2D vectors, designers should consider complex 
>>>> numbers.
>>>>
>>> That's a nice idea.
>>>
>>> But I've never seen code where the horizontal axis is "real" and the
>>> vertical "imaginary", except of course in code designed to demonstrate
>>> complex numbers as such. Mandelbrot is my favourite test program when
>>> getting a new system.
>>
>> Complex numbers are used for expressing mappings that have geometric
>> interpretations.
>>
>> In 2D computer graphics, they are convenient. E.g. to rotate
>> a vector that is a complex number z = a + ib, you just multiply by
>> a complex number that is on the unit circle representing that
>> angle   cos(theta) + i sin(theta) .
>>
>> The multiplication math is exactly the same as
>>
>>    [ cos -sin ] [ a ]
>>    [ sin  cos ] [ b ]
>>
>> Because when you multiply two complex nubmers (c + id)(a + ib),
>> the FOIL rule produces
>>
>>     ca + icb + ida + iidb
>>    = (ca - db) + i(cb + da).
>>
>> And that's just
>>
>>    [ c  -d ] [ a ]  =  [ ca - db ]
>>    [ d   c ] [ b ]  =  [ da + cb ]
>>
> Yes I know. I did complex numbers at high school.
> 
> But whilst you could use the Argand plane as your graphics surface and 
> thus represent all points as complex numbers, I've never actually seen 
> anyone do so, and the axes are always given different labels. Except of 
> course in Mandelbrots or other programs concerned with complex numbers 
> themselves.

Usually a vector, say 2-ary (x, y), x is the horizontal axis and y is 
the vertical axis. This matches a complex number x + yi:

      +y
      |
  -x--0--+x
      |
      -y

x is real, y is imaginary. :^)

[toc] | [prev] | [next] | [standalone]

#118231

On 1/19/2024 10:17 AM, Malcolm McLean wrote:
> On 16/01/2024 22:03, Lynn McGuire wrote:
>> “We are doomed”
>>     https://www.carette.xyz/posts/we_are_doomed/
>>
>> “The only system with a good software compatibility that I know is 
>> Windows, and this explains a ton of things keeping very old UI/UX 
>> frameworks, software and APIs to run, for example, Windows 95 
>> compatible games like “Roller Coaster Tycoon”.”
>>
>> “Otherwise, you are doomed.”
>>
>> The C++ committee has screwed up and continues to screw up by not 
>> creating a graphics standard for C++.
>>
>> Lynn
> One problem that could be very easily fixed is that there is no standard 
> representation of a point or a vector. Whilst generally it's just a POD 
> structure with x and y members, the name varies, and sometimes the 
> dimensions are referred to by index instead of by letter. You can also 
> have a philosophical discussion about whether points and vectors should 
> be the same structures or incompatible structures.
> But a simple standardisation would mean the end of pointless editing of 
> code just to conform to whatever the host program has chosen.

Fwiw, I am very fond of the following header only library:

https://github.com/g-truc/glm

Works great and makes it rather straightforward to port to GLSL shaders. 
I basically use it everyday for stuff like:

https://youtu.be/KRkKZj9s3wk

[toc] | [prev] | [next] | [standalone]

#118238

On 1/19/24 19:17, Malcolm McLean wrote:
> One problem that could be very easily fixed is that there is no standard 
> representation of a point or a vector. Whilst generally it's just a POD 
> structure with x and y members, the name varies, and sometimes the 
> dimensions are referred to by index instead of by letter. You can also 
> have a philosophical discussion about whether points and vectors should 
> be the same structures or incompatible structures.
> But a simple standardisation would mean the end of pointless editing of 
> code just to conform to whatever the host program has chosen.

And what should be the data type of the coefficients of the vector? And 
what should? Why not also have matrices? What is the maximum dimension 
supported? Are homogeneous coordinates a built-in feature? No, leave the 
graphics stuff to a graphics team.

[toc] | [prev] | [next] | [standalone]

#118239

On 22/01/2024 00:22, immibis wrote:
> On 1/19/24 19:17, Malcolm McLean wrote:
>> One problem that could be very easily fixed is that there is no 
>> standard representation of a point or a vector. Whilst generally it's 
>> just a POD structure with x and y members, the name varies, and 
>> sometimes the dimensions are referred to by index instead of by 
>> letter. You can also have a philosophical discussion about whether 
>> points and vectors should be the same structures or incompatible 
>> structures.
>> But a simple standardisation would mean the end of pointless editing 
>> of code just to conform to whatever the host program has chosen.
> 
> And what should be the data type of the coefficients of the vector? And 
> what should? Why not also have matrices? What is the maximum dimension 
> supported? Are homogeneous coordinates a built-in feature? No, leave the 
> graphics stuff to a graphics team.
It should take a template, so any type can be used for the coefficients. 
Unless you have some weird and wonderful ideas, it will of course be 
scalar.
I'd recommend a 2D with x and y and a 3D with x, y and z. Humanity is 
not going to be elevated to a higher dimension any time soon. No 
homogenous co-ordinates. No angle / magnitude notation. No need for 
matrices because we already have a natural representation of the these, 
since C++ supports 2 dimensional fixed size array.
Needing to store points in 2D or 3D space is a common requirement, and 
code needs to communicate with other modules. One of which will be the 
graphics system, which may well have requirements beyond simple points 
in space, but will include such a requirement.
-- 
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

[toc] | [prev] | [next] | [standalone]

#118241

Op 22.jan.2024 om 12:16 schreef Malcolm McLean:
> On 22/01/2024 00:22, immibis wrote:
>> On 1/19/24 19:17, Malcolm McLean wrote:
>>> One problem that could be very easily fixed is that there is no 
>>> standard representation of a point or a vector. Whilst generally it's 
>>> just a POD structure with x and y members, the name varies, and 
>>> sometimes the dimensions are referred to by index instead of by 
>>> letter. You can also have a philosophical discussion about whether 
>>> points and vectors should be the same structures or incompatible 
>>> structures.
>>> But a simple standardisation would mean the end of pointless editing 
>>> of code just to conform to whatever the host program has chosen.
>>
>> And what should be the data type of the coefficients of the vector? 
>> And what should? Why not also have matrices? What is the maximum 
>> dimension supported? Are homogeneous coordinates a built-in feature? 
>> No, leave the graphics stuff to a graphics team.
> It should take a template, so any type can be used for the coefficients. 
> Unless you have some weird and wonderful ideas, it will of course be 
> scalar.
> I'd recommend a 2D with x and y and a 3D with x, y and z. Humanity is 
> not going to be elevated to a higher dimension any time soon. No 
> homogenous co-ordinates. No angle / magnitude notation. No need for 
> matrices because we already have a natural representation of the these, 
> since C++ supports 2 dimensional fixed size array.
> Needing to store points in 2D or 3D space is a common requirement, and 
> code needs to communicate with other modules. One of which will be the 
> graphics system, which may well have requirements beyond simple points 
> in space, but will include such a requirement.

According to Einstein, humanity lives already in a four dimensional 
space; time is the fourth dimension.
There are many problems in physics and other fields with even more than 
4 dimensions, so it would be short-sighted to limit the library to 3 
dimensions.
In addition one could ask how far the standard library must go. What 
operations must be supported? Calculate the length of a vector, allowing 
non-Euclidian spaces?

[toc] | [prev] | [next] | [standalone]

#118242

On 22/01/2024 11:34, Fred. Zwarts wrote:
> Op 22.jan.2024 om 12:16 schreef Malcolm McLean:
>> On 22/01/2024 00:22, immibis wrote:
>>> On 1/19/24 19:17, Malcolm McLean wrote:
>>>> One problem that could be very easily fixed is that there is no 
>>>> standard representation of a point or a vector. Whilst generally 
>>>> it's just a POD structure with x and y members, the name varies, and 
>>>> sometimes the dimensions are referred to by index instead of by 
>>>> letter. You can also have a philosophical discussion about whether 
>>>> points and vectors should be the same structures or incompatible 
>>>> structures.
>>>> But a simple standardisation would mean the end of pointless editing 
>>>> of code just to conform to whatever the host program has chosen.
>>>
>>> And what should be the data type of the coefficients of the vector? 
>>> And what should? Why not also have matrices? What is the maximum 
>>> dimension supported? Are homogeneous coordinates a built-in feature? 
>>> No, leave the graphics stuff to a graphics team.
>> It should take a template, so any type can be used for the 
>> coefficients. Unless you have some weird and wonderful ideas, it will 
>> of course be scalar.
>> I'd recommend a 2D with x and y and a 3D with x, y and z. Humanity is 
>> not going to be elevated to a higher dimension any time soon. No 
>> homogenous co-ordinates. No angle / magnitude notation. No need for 
>> matrices because we already have a natural representation of the 
>> these, since C++ supports 2 dimensional fixed size array.
>> Needing to store points in 2D or 3D space is a common requirement, and 
>> code needs to communicate with other modules. One of which will be the 
>> graphics system, which may well have requirements beyond simple points 
>> in space, but will include such a requirement.
> 
> According to Einstein, humanity lives already in a four dimensional 
> space; time is the fourth dimension.
> There are many problems in physics and other fields with even more than 
> 4 dimensions, so it would be short-sighted to limit the library to 3 
> dimensions.
> In addition one could ask how far the standard library must go. What 
> operations must be supported? Calculate the length of a vector, allowing 
> non-Euclidian spaces?
No-one is saying that you can't devise your own structures if you want 
to write programs to solve problems in general relativity. The idea is 
to have a common standard for the common requirement to represent pints 
and vectors in 2d and 3d spaces, so that routines writen in C++ can 
communicate with each other without the need for adapter code or rewriting.
However having decided on a representation for points, there is also a 
very strong case for a standard library for basic operations on those 
points, such as taking the length of a vector. However probably not 
non-Euclidian spaces. Again, some people will want to write software 
that operates in Hilbert space or other non-Euclidean space, but it's 
likely to be specialised, and so you can't expect much support from the 
standard library.
-- 
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

[toc] | [prev] | [next] | [standalone]

#118244

On 1/22/2024 3:16 AM, Malcolm McLean wrote:
> On 22/01/2024 00:22, immibis wrote:
>> On 1/19/24 19:17, Malcolm McLean wrote:
>>> One problem that could be very easily fixed is that there is no 
>>> standard representation of a point or a vector. Whilst generally it's 
>>> just a POD structure with x and y members, the name varies, and 
>>> sometimes the dimensions are referred to by index instead of by 
>>> letter. You can also have a philosophical discussion about whether 
>>> points and vectors should be the same structures or incompatible 
>>> structures.
>>> But a simple standardisation would mean the end of pointless editing 
>>> of code just to conform to whatever the host program has chosen.
>>
>> And what should be the data type of the coefficients of the vector? 
>> And what should? Why not also have matrices? What is the maximum 
>> dimension supported? Are homogeneous coordinates a built-in feature? 
>> No, leave the graphics stuff to a graphics team.
> It should take a template, so any type can be used for the coefficients. 
> Unless you have some weird and wonderful ideas, it will of course be 
> scalar.
> I'd recommend a 2D with x and y and a 3D with x, y and z. Humanity is 
> not going to be elevated to a higher dimension any time soon. No 
> homogenous co-ordinates. No angle / magnitude notation. No need for 
> matrices because we already have a natural representation of the these, 
> since C++ supports 2 dimensional fixed size array.
> Needing to store points in 2D or 3D space is a common requirement, and 
> code needs to communicate with other modules. One of which will be the 
> graphics system, which may well have requirements beyond simple points 
> in space, but will include such a requirement.

And 4-ary with (x, y, z, w)

Again I am quite fond of the GLM library. It's just nice to me.

[toc] | [prev] | [next] | [standalone]

#118268

On 22/01/24 12:16, Malcolm McLean wrote:
> On 22/01/2024 00:22, immibis wrote:
>> On 1/19/24 19:17, Malcolm McLean wrote:
>>> One problem that could be very easily fixed is that there 
>>> is no standard representation of a point or a vector. 
>>> Whilst generally it's just a POD structure with x and y 
>>> members, the name varies, and sometimes the dimensions 
>>> are referred to by index instead of by letter. You can 
>>> also have a philosophical discussion about whether points 
>>> and vectors should be the same structures or incompatible 
>>> structures.
>>> But a simple standardisation would mean the end of 
>>> pointless editing of code just to conform to whatever the 
>>> host program has chosen.
>>
>> And what should be the data type of the coefficients of 
>> the vector? And what should? Why not also have matrices? 
>> What is the maximum dimension supported? Are homogeneous 
>> coordinates a built-in feature? No, leave the graphics 
>> stuff to a graphics team.
> It should take a template, so any type can be used for the 
> coefficients. Unless you have some weird and wonderful 
> ideas, it will of course be scalar.
> I'd recommend a 2D with x and y and a 3D with x, y and z. 
> Humanity is not going to be elevated to a higher dimension 
> any time soon. No homogenous co-ordinates. No angle / 
> magnitude notation. No need for matrices because we already 
> have a natural representation of the these, since C++ 
> supports 2 dimensional fixed size array.
> Needing to store points in 2D or 3D space is a common 
> requirement, and code needs to communicate with other 
> modules. One of which will be the graphics system, which may 
> well have requirements beyond simple points in space, but 
> will include such a requirement.

Looking at the variety of image formats, I tend to think 
that the coordinate system and RAM representation is still 
the least of the problems, and that colour space 
representation (bits depths, order, endianness, transparency 
support) could be even worse.
Also, at some point, every library has to interact with the 
OS to load/unload images into the display driver, which is 
at best posix-copliant, but still depends a lot on the OS 
internals.

Graphics that wont' show up on screen is not very appealing 
or useful.
Here a lot of graphic SW had to be rewritten migrating from 
X to Wayland.

So RAM representation is really the least hard part. The 
worse is how to load/save a variety of formats to/from disk, 
and how to display the results on screen. How to move large 
block of pixels avoinding flickering, etc

Since external libraries handle all this, it's not that 
difficult to have also its own RAM representation of pixels, 
vectors and geometry.
I think that creating a standard for this won't solve the 
other main problems.


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web