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

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

Iterate over the adjacent elements in a matix container

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

Contents

  Iterate over the adjacent elements in a matix container Alexander <alvatov@gmail.com> - 2011-09-26 12:44 -0700
    Re: Iterate over the adjacent elements in a matix container Victor Bazarov <v.bazarov@comcast.invalid> - 2011-09-26 15:49 -0400
    Re: Iterate over the adjacent elements in a matix container puppi <fabricio.puppi@gmail.com> - 2011-09-26 15:30 -0700
    Re: Iterate over the adjacent elements in a matix container "Paul" <pchristor@yahoo.co.uk> - 2011-09-27 06:43 +0100
      Re: Iterate over the adjacent elements in a matix container Juha Nieminen <nospam@thanks.invalid> - 2011-09-27 07:12 +0000
        Re: Iterate over the adjacent elements in a matix container Richard Damon <news.x.richarddamon@xoxy.net> - 2011-09-27 11:10 -0400
          Re: Iterate over the adjacent elements in a matix container Juha Nieminen <nospam@thanks.invalid> - 2011-09-27 20:32 +0000
          Re: Iterate over the adjacent elements in a matix container Juha Nieminen <nospam@thanks.invalid> - 2011-09-30 06:24 +0000
            Re: Iterate over the adjacent elements in a matix container Nobody <nobody@nowhere.com> - 2011-09-30 20:55 +0100
            Re: Iterate over the adjacent elements in a matix container Richard Damon <news.x.richarddamon@xoxy.net> - 2011-09-30 17:07 -0400
    Re: Iterate over the adjacent elements in a matix container Krice <paulkp@mbnet.fi> - 2011-09-27 03:37 -0700
    Re: Iterate over the adjacent elements in a matix container Alexander <alvatov@gmail.com> - 2011-09-29 10:47 -0700
      Re: Iterate over the adjacent elements in a matix container "Paul" <pchristor@yahoo.co.uk> - 2011-09-30 01:28 +0100
      Re: Iterate over the adjacent elements in a matix container Juha Nieminen <nospam@thanks.invalid> - 2011-09-30 06:19 +0000
      Re: Iterate over the adjacent elements in a matix container "Paul" <pchristor@yahoo.co.uk> - 2011-10-02 05:16 +0100
        Re: Iterate over the adjacent elements in a matix container "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-10-03 05:31 +0100
          Re: Iterate over the adjacent elements in a matix container "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2011-10-03 05:47 +0100

#10523 — Iterate over the adjacent elements in a matix container

Hello everyone!

I need a way to perform an action in adjacent positions in a matrix (grid) container.

Example 1:
In a Minesweeper game, if a square is empty and there are no mines around it, all the empty squares around it should be opened, and all the empty squares around them, and ... well, you get the point.

Example 2:
In a painting program, when a 'fill' tool is used, when a pixel is clicked, all the adjacent squares, and their, adjacent squares, and... with the same color get colored in another way.

Could you tell me about a possibly simple, possibly efficient (emphasis on simplicity though) for implementing stuff like that?

If I haven't made myself clear enough, or you have any questions, please ask!

Thank you!

P.S. 1:
Sorry for posting to this group, this is not a c++ specific question, but I did not find a more suitable group, and I usually program in C++ (though recently I'm falling in love with Python for the quick-and-dirty jobs)

P.S. 2:
In case you think I'm a student asking help for his homework, I would be perfectly happy with general answers, like just the name of an algorithm. Anyway that's not the case. (I am a student, but in high-school, programming is a hobby for me). 

[toc] | [next] | [standalone]

#10525

On 9/26/2011 3:44 PM, Alexander wrote:
> I need a way to perform an action in adjacent positions in a matrix
> (grid) container. [..]
>
> P.S. 1: Sorry for posting to this group, this is not a c++ specific
> question, but I did not find a more suitable group, and I usually
> program in C++ (though recently I'm falling in love with Python for
> the quick-and-dirty jobs)

Try comp.programming.

>[..]

V
-- 
I do not respond to top-posted replies, please don't ask

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

#10526

On Sep 26, 4:44 pm, Alexander <alva...@gmail.com> wrote:
> Hello everyone!
>
> I need a way to perform an action in adjacent positions in a matrix (grid) container.
>
> Example 1:
> In a Minesweeper game, if a square is empty and there are no mines around it, all the empty squares around it should be opened, and all the empty squares around them, and ... well, you get the point.
>
> Example 2:
> In a painting program, when a 'fill' tool is used, when a pixel is clicked, all the adjacent squares, and their, adjacent squares, and... with the same color get colored in another way.
>
> Could you tell me about a possibly simple, possibly efficient (emphasis on simplicity though) for implementing stuff like that?
>
> If I haven't made myself clear enough, or you have any questions, please ask!
>
> Thank you!
>
> P.S. 1:
> Sorry for posting to this group, this is not a c++ specific question, but I did not find a more suitable group, and I usually program in C++ (though recently I'm falling in love with Python for the quick-and-dirty jobs)
>
> P.S. 2:
> In case you think I'm a student asking help for his homework, I would be perfectly happy with general answers, like just the name of an algorithm. Anyway that's not the case. (I am a student, but in high-school, programming is a hobby for me).

Try a stack. Or, if you really favor bits of simplicity over
efficiency, try recursion.

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

#10533

"Alexander" <alvatov@gmail.com> wrote in message 
news:13318117.2085.1317066256036.JavaMail.geo-discussion-forums@yqmw31...
> Hello everyone!
>
> I need a way to perform an action in adjacent positions in a matrix (grid) 
> container.
>
> Example 1:
> In a Minesweeper game, if a square is empty and there are no mines around 
> it, all the empty squares around it should be opened, and all the empty 
> squares around them, and ... well, you get the point.
>
> Example 2:
> In a painting program, when a 'fill' tool is used, when a pixel is 
> clicked, all the adjacent squares, and their, adjacent squares, and... 
> with the same color get colored in another way.
>
> Could you tell me about a possibly simple, possibly efficient (emphasis on 
> simplicity though) for implementing stuff like that?
>
> If I haven't made myself clear enough, or you have any questions, please 
> ask!
>
> Thank you!
>
> P.S. 1:
> Sorry for posting to this group, this is not a c++ specific question, but 
> I did not find a more suitable group, and I usually program in C++ (though 
> recently I'm falling in love with Python for the quick-and-dirty jobs)
>
> P.S. 2:
> In case you think I'm a student asking help for his homework, I would be 
> perfectly happy with general answers, like just the name of an algorithm. 
> Anyway that's not the case. (I am a student, but in high-school, 
> programming is a hobby for me).

You could create two temp bool arrays of the same size.
One array indicates the checked squares as a 1 value, set the equivalent 
index for the original square clicked on.
Start a loop which tests each of the four squares adjacent to *the 
square*( starting with the square the user clicked as *the square*).
Test each adjacent index for equality(see note) , update the other bool 
array to indicate which indices tested true.
Test one bool array against the other for an xor result.
If a true xor result is found then loop again[1] using the index that tested 
true(xor test) as *the square*, if not end.
[1]Update the array that stores the tested squares to include the previous 
*square* before relooping.

Note:
Every time you test an index for equality you first need to make sure that 
index is in bounds:

Suppose a 1d array of size 5 like so:
00001
If we start with index4 and test the 2 adjacents, index 5 would be out of 
bounds, so before you test the adjacent squares you first need to test if 
there is an adjacent square.
One thing you can do is make the array oversized so it doesn't matter if you 
go over bounds by one i.e: Create an array of size 7 and offset it by +1.
0000010

int my_array[7] = {0};
int* p_arr = my_array;
++p_arr;

p_arr[-1] =who_cares_whats_there;
p_arr[5] = who_cares_whats_there;

The bool arrays do not need to be oversized so *the square* will always have 
a one square buffer due to the oversized array. This can be applied to a 2d 
array too.


HTH
Paul. 


--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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

#10537

Paul <pchristor@yahoo.co.uk> wrote:
> You could create two temp bool arrays of the same size.
> One array indicates the checked squares as a 1 value, set the equivalent 
> index for the original square clicked on.
> Start a loop which tests each of the four squares adjacent to *the 
> square*( starting with the square the user clicked as *the square*).
> Test each adjacent index for equality(see note) , update the other bool 
> array to indicate which indices tested true.
> Test one bool array against the other for an xor result.
> If a true xor result is found then loop again[1] using the index that tested 
> true(xor test) as *the square*, if not end.
> [1]Update the array that stores the tested squares to include the previous 
> *square* before relooping.

  As usual, you have no idea what you are talking about.

  What he wants is a depth-first search, which is relatively simple recursive
algorithm:

  1) Make a function that takes the initial point to be marked as parameter.

  2) Mark that point.

  3) Call this function recursively with each point adjacent to that one
which is empty (ie. to be included in the search) and not marked already.

  The algorithm will naturally terminate when all the connected empty points
have been marked.

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

#10546

On 9/27/11 3:12 AM, Juha Nieminen wrote:
> Paul<pchristor@yahoo.co.uk>  wrote:
>> You could create two temp bool arrays of the same size.
>> One array indicates the checked squares as a 1 value, set the equivalent
>> index for the original square clicked on.
>> Start a loop which tests each of the four squares adjacent to *the
>> square*( starting with the square the user clicked as *the square*).
>> Test each adjacent index for equality(see note) , update the other bool
>> array to indicate which indices tested true.
>> Test one bool array against the other for an xor result.
>> If a true xor result is found then loop again[1] using the index that tested
>> true(xor test) as *the square*, if not end.
>> [1]Update the array that stores the tested squares to include the previous
>> *square* before relooping.
>
>    As usual, you have no idea what you are talking about.
>
>    What he wants is a depth-first search, which is relatively simple recursive
> algorithm:
>
>    1) Make a function that takes the initial point to be marked as parameter.
>
>    2) Mark that point.
>
>    3) Call this function recursively with each point adjacent to that one
> which is empty (ie. to be included in the search) and not marked already.
>
>    The algorithm will naturally terminate when all the connected empty points
> have been marked.

One problem with a depth-first search done this way is you will need a 
recursion depth equal to the maximum number of nodes that may need to be 
marked. A breadth first search, using a stack like structure to store 
the list of nodes to visit, may require less levels stored, and if using 
tail recursion optimization, doesn't actually need to use recursion.

Pauls method is basically this except stores the locations to check in a 
bit map, and scans the bit map to find the next location, which is 
really neither breadth first or depth first. His method always uses 2 
bits per cell in the universe, and a lot of program looping to scan. A 
breadth first search needs to store a coordinate (maybe a 16 bit value 
for up to a 256x256 pattern), and typically needs a lot less of them. It 
also doesn't need to search to find the next point, so has a significant 
time savings for a possible small space cost.

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

#10554

Richard Damon <news.x.richarddamon@xoxy.net> wrote:
> One problem with a depth-first search done this way is you will need a 
> recursion depth equal to the maximum number of nodes that may need to be 
> marked. A breadth first search, using a stack like structure to store 
> the list of nodes to visit, may require less levels stored, and if using 
> tail recursion optimization, doesn't actually need to use recursion.

  Well, the original poster emphasized simplicity, and the depth-first
search is definitely a very simple solution.

  A minor optimization can be done to the solution I suggested: The function
also marks all the adjacent points (before making the recursive calls).
This may in some cases somewhat reduce the recursion depth (and overall
amount of work) performed compared to the pure depth-first search, and
isn't significantly more complicated to implement.

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

#10606

Richard Damon <news.x.richarddamon@xoxy.net> wrote:
> One problem with a depth-first search done this way is you will need a 
> recursion depth equal to the maximum number of nodes that may need to be 
> marked. A breadth first search, using a stack like structure to store 
> the list of nodes to visit, may require less levels stored, and if using 
> tail recursion optimization, doesn't actually need to use recursion.

  Btw, I didn't notice this at first, but now I see that you seem to be
suggesting that it's much preferable to avoid recursion, even if it means
using a more complicated (to implement) solution. Why?

  Note that by using a stack you are not really saving any memory. You
will still be storing O(n) amount of data (where n is the number of nodes
that have to be marked). In fact, depending a bit on the situation, the
breadth-first search may end up storing more data than the depth-first
search (although it's true that in some cases it may be the other way
around).

  Anyways, your concern seems to not be the amount of data needed to
perform the task, but the recursion. Why? What exactly is the problem?

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

#10613

On Fri, 30 Sep 2011 06:24:12 +0000, Juha Nieminen wrote:

>> One problem with a depth-first search done this way is you will need a 
>> recursion depth equal to the maximum number of nodes that may need to be 
>> marked. A breadth first search, using a stack like structure to store 
>> the list of nodes to visit, may require less levels stored, and if using 
>> tail recursion optimization, doesn't actually need to use recursion.
> 
>   Btw, I didn't notice this at first, but now I see that you seem to be
> suggesting that it's much preferable to avoid recursion, even if it means
> using a more complicated (to implement) solution. Why?

One advantage of an explicit stack is that you're more likely to be able
to allocate a large heap block than a large stack. On Unix, any memory
allocated for the stack (RLIMIT_STACK) cannot be used for anything else,
which tends to result in it being somewhat smaller than the largest
possible heap block.

Also, you can detect malloc() failure (NULL return) more easily than a
stack overflow (SIGSEGV, which can only be caught if you have allocated an
alternate signal stack).

Finally, the amount of memory for each recursion level is likely to be
less when using a manual stack. Each frame on the program stack will
typically contain saved program counter, stack pointer and frame pointer
registers, as well as space for any temporary storage. This is all in
addition to space which is inherently required by the algorithm.

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

#10615

On 9/30/11 2:24 AM, Juha Nieminen wrote:
> Richard Damon<news.x.richarddamon@xoxy.net>  wrote:
>> One problem with a depth-first search done this way is you will need a
>> recursion depth equal to the maximum number of nodes that may need to be
>> marked. A breadth first search, using a stack like structure to store
>> the list of nodes to visit, may require less levels stored, and if using
>> tail recursion optimization, doesn't actually need to use recursion.
>
>    Btw, I didn't notice this at first, but now I see that you seem to be
> suggesting that it's much preferable to avoid recursion, even if it means
> using a more complicated (to implement) solution. Why?
>
>    Note that by using a stack you are not really saving any memory. You
> will still be storing O(n) amount of data (where n is the number of nodes
> that have to be marked). In fact, depending a bit on the situation, the
> breadth-first search may end up storing more data than the depth-first
> search (although it's true that in some cases it may be the other way
> around).
>
>    Anyways, your concern seems to not be the amount of data needed to
> perform the task, but the recursion. Why? What exactly is the problem?


Note that there are a couple of issues here. One is that a level of 
recursion cost a lot more memory space than saving a few locations to 
iterate in a program controlled resource than a recursive call. Remember 
that a level of recursion is going to create new copies of every 
automatic variable used in the function, as opposed to just what is 
needed to keep track locations to be filled.

A second issue is that recursion grows the program stack space, and 
there is no way (portably) of checking for program stack overflow, while 
you can check for running out of memory in the heap or program defined 
memory structure. (Not every program runs on machines with gigabytes of 
RAM).

Also, in typical worse case type configurations, a depth first path is 
going to trace down to a significantly higher depth than a breadth first 
search, as after you run out to what would seem to be a maximum distance 
away, the depth first search will turn around and come back and 
eventually hit most of the open cells in a deep path, it may 
occasionally trap it self, but after it backs out a few steps, it will 
find the deeper path. For a 200x200 flood file, I would expect it to get 
at least 30,000 levels deep. On the other hand, a breadth first search 
will tend to generate an expanding ring only a couple of cells thick, 
needing maybe 1600 locations recorded at a given time for the same area. 
The key here is that breadth first limits itself to first looking near 
where it has done work, and finishes cells, so we don't need to revisit 
them. Depth first can't tell that a later path will get to a cell at a 
shorted depth. This is a common issue with traversing highly connected 
paths.

There is nothing inherently wrong with recursion, but it isn't always 
the right tool, and often is a somewhat heavy handed one. An important 
thing when using recursion is to make sure that it does terminate, and 
in a reasonable number of levels. Removing recursion and replacing it 
with iteration is a common optimization. (For an extreme case compare 
recursive and iterative version of factorial or Fibonacci calculations).

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

#10541

On 26 syys, 22:44, Alexander <alva...@gmail.com> wrote:
> Example 2:
> In a painting program, when a 'fill' tool is used, when a pixel is
> clicked, all the adjacent squares, and their, adjacent squares, and..
> with the same color get colored in another way.

If you do some homework with google you'll find out that the routine
is called flood fill. The easiest way to implement it is scan over
the entire area with a seed number set to the point of origin:
surrounding to-be-filled spaces get new seed number and those points
are then processed in the next scan etc. until no more free spaces.
Then you have a seed map which is the shape of the area.

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

#10586

Krice, thank you very much! The name of the algorithm I need helps very much i finding info.

Paul, sorry, but I'll need about a week to fully understand your idea.

Thanks everyone!

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

#10598

"Alexander" <alvatov@gmail.com> wrote in message 
news:3755378.2025.1317318432217.JavaMail.geo-discussion-forums@yqbr29...
> Krice, thank you very much! The name of the algorithm I need helps very 
> much i finding info.
>
> Paul, sorry, but I'll need about a week to fully understand your idea.
>
Haven't you done it yet? :)
It's quite a tircky little task. I have been thinking of a few ways but 
can't find anything perfect.
Recursion seems like the obvious fit but I was trying to think of some 
matrix trickery to make something simple.
GL :)


--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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

#10605

Alexander <alvatov@gmail.com> wrote:
> Paul, sorry, but I'll need about a week to fully understand your idea.

  Just curious, but I'm wondering if/why you consider the depth-first
search solution unfit.

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

#10632

"Alexander" <alvatov@gmail.com> wrote in message 
news:3755378.2025.1317318432217.JavaMail.geo-discussion-forums@yqbr29...
> Krice, thank you very much! The name of the algorithm I need helps very 
> much i finding info.
>
> Paul, sorry, but I'll need about a week to fully understand your idea.

I have been thinking about this algorithm and decided to write a little 
example for you. It's just a quick draft but it shows what I tried to 
explain to you. The helper function getAdjacents is the complex part and 
this is what I have been trying to find some trick to solve. I was babbling 
on a bit about using oversized arrays to solve this but I haven't though 
much more about that.

I would like to say on the point about my idea looping too much that I 
accept that there probably is some algorithm that can do less operations, 
but most of my looping only has one simple xor condition and only satifies 
this condition when it needs to.

Others have suggested other ways to do this. I can understand how an 
alorithm working from the point or origin outwards could be more efficient 
but I'm not sure how that would be implemented. I will think more on this. 
Perhaps someone could post a short example of these other methods so we can 
understand what they are talking about.

HTH
Paul.

/*****code*****/
#include <iostream>
#include<vector>

/*gets a vector of indexes adjacent to a given index*/
std::vector<int> getAdjacents(int index, int rows=7, int cols=8){
 std::vector<int> ret;
 if( (index/cols==(index-1)/cols)&& index!=0 ) ret.push_back(index-1);
 if((index+1)%cols) ret.push_back(index+1);
 if(index-cols>=0) ret.push_back(index-cols);
 if( (index+cols)<(rows*cols)) ret.push_back(index+cols);
 return ret;
}

/*parameter 'clicked' represents the index of the tile that was clicked*/
void clickme(std::vector<int>& v, int clicked=15, int newval=4){
 std::vector<bool> b1(v.size(),0);
 std::vector<bool> b2(v.size(),0);
 std::vector<int> adjacents;
 int initval= v[clicked];
 v[clicked]=newval;
 b2[clicked]=1;
 /*b2 represents all tiles whos value has been changed*/
 /*b1 represents all tiles whos adjacents have been checked*/

 /*loop to find a tile whos value has been changed but its adjacents have 
not not been checked*/
 for(int i=0; i<b1.size(); ++i){
  if(b1[i]^b2[i]){
   /*ok found one, check its adjacents*/
   adjacents = getAdjacents(i);
   /*inner loop will loop 2-4 times only*/
   for(int j=0; j<adjacents.size(); ++j){
    if(v[adjacents[j]]== initval){
     v[adjacents[j]]=newval;
     b2[adjacents[j]]=1;
    }
   }
   /*mark this tile as having had its adjacents checked*/
   b1[i]=1;
   /*reset loop and find another tile whos value has been changed*/
   i=0;
   adjacents.clear();
  }
 }
}


int main(){
 /*Example vector to repsresent a 7x8 matrix*/
 std::vector<int> v(56,2);
 v[5]=3;
 v[13]=3;
 v[21]=3;
 v[22]=3;
 v[23]=3;
 std::cout<<"Before clickme:";
 for(int i=0; i<v.size(); ++i){
  if(i%8==0) std::cout<<std::endl;
  std::cout<< v[i];
 }
 clickme(v);
 std::cout<<"\n\nAfter clickme:";
 for(int i=0; i<v.size(); ++i){
  if(i%8==0) std::cout<<std::endl;
  std::cout<< v[i];
 }
}

/*It's a bit rough and definately not unbreakable but its just an example*/


--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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

#10640

"Paul" <pchristor@yahoo.co.uk> wrote in message 
news:j68oip$r0u$1@adenine.netfront.net...
>
> "Alexander" <alvatov@gmail.com> wrote in message 
> news:3755378.2025.1317318432217.JavaMail.geo-discussion-forums@yqbr29...
>> Krice, thank you very much! The name of the algorithm I need helps very 
>> much i finding info.
>>
>> Paul, sorry, but I'll need about a week to fully understand your idea.
>
> I have been thinking about this algorithm and decided to write a little 
> example for you.

<snip>

And here's an example using recursion, its very similar. Again the 
complexity seems to be in the getAdjacents function. It appears to be 
simpler but there is more data stored on the stack as someone else has 
already explained. I am still to understand this "breath first" method 
Richard was talking about or the "seed method" Krice mentioned.  I will 
think more about this to try and find a better way.

/*Code. again very rough but just an example.*/
#include <iostream>
#include<vector>

std::vector<int> getAdjacents(int index, int rows=7, int cols=8){
 std::vector<int> ret;
 if( (index/cols==(index-1)/cols)&& index!=0 ) ret.push_back(index-1);
 if((index+1)%cols) ret.push_back(index+1);
 if(index-cols>=0) ret.push_back(index-cols);
 if( (index+cols)<(rows*cols)) ret.push_back(index+cols);
 return ret;
}

void recurse(std::vector<int>& v, int i, int initval, int newval){
 std::vector<int> adjacents=getAdjacents(i);
 for(int i=0; i<adjacents.size(); ++i){
  if(v[adjacents[i]]==initval){
   v[adjacents[i]]= newval;
   recurse(v, adjacents[i], initval, newval);
  }
 }
}

void clickme(std::vector<int>& v, int clicked=55, int newval=4){
 int initval= v[clicked];
 v[clicked]=newval;
 recurse(v, clicked, initval, newval);
}


int main(){
 std::vector<int> v(56,2);
 v[5]=3;
 v[13]=3;
 v[21]=3;
 v[22]=3;
 v[23]=3;
 std::cout<<"Before clickme:";
 for(int i=0; i<v.size(); ++i){
  if(i%8==0) std::cout<<std::endl;
  std::cout<< v[i];
 }
 clickme(v);
 std::cout<<"\n\nAfter clickme:";
 for(int i=0; i<v.size(); ++i){
  if(i%8==0) std::cout<<std::endl;
  std::cout<< v[i];
 }
}



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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

#10641

Also note that your two examples differ in their definiton of 'adjacent'. A 
paint fill will consider diagonals adjacent whereas minesweeper does not. :)



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [standalone]

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

csiph-web