Okay, so what I'm trying to do is read in 2 phrases, then use 2 foreach loops to check for spaces and remove them. Example:

foreach( character; phraseOne )
{
   if ( character == ' ' )
   {
      take the character out of the string ( and resize it??? )
   }
}
foreach( character; phraseTwo )
{
   if ( character == ' ' )
   {
      take the character out of the string ( and resize it??? )
   }
}

Also, is there anyway I can use only 1 foreach loop to do those 2 things? I'm pretty sure when I repeat code like that there must be a better way.

And 1 thing about readln and readf: I realized that I can't use readf to read words with spaces. And when there is a space entered with readf, the other words stay in the input buffer.(input buffer is what it is, right?) Then when I use readln (maybe readf too, I didn't check that), it automatically enters what was left over. How do I flush the input buffer?
Thanks.
-Michael P.

Michael P. wrote:
> Okay, so what I'm trying to do is read in 2 phrases, then use 2 foreach loops to check for spaces and remove them.
> Example:
> 
> foreach( character; phraseOne )
> {
>    if ( character == ' ' )
>    {
>       take the character out of the string ( and resize it??? )
>    }
> }
> foreach( character; phraseTwo )
> {
>    if ( character == ' ' )
>    {
>       take the character out of the string ( and resize it??? )
>    }
> }
> 
> Also, is there anyway I can use only 1 foreach loop to do those 2 things? I'm pretty sure when I repeat code like that there must be a better way.
> 
> And 1 thing about readln and readf: I realized that I can't use readf to read words with spaces. And when there is a space entered with readf, the other words stay in the input buffer.(input buffer is what it is, right?) Then when I use readln (maybe readf too, I didn't check that), it automatically enters what was left over. How do I flush the input buffer?
> Thanks.
> -Michael P.


Try taking advantage of slicing.. havn't tested this but should be close..

char[] strip( char[] str, char c, uint index = 0 )
{
  for(int i = index; i < str.length; i++)
      if(str[i] == c)
         return str[0..i] ~ strip( str[i+1..$], c, i+1 );

  return str;
}

Reply to Michael P.,

> Okay, so what I'm trying to do is read in 2 phrases, then use 2
> foreach loops to check for spaces and remove them.
> 
> Example:
> 
> foreach( character; phraseOne )
> {
> if ( character == ' ' )
> {
> take the character out of the string ( and resize it??? )
> }
> }
> Also, is there anyway I can use only 1 foreach loop to do those 2
> things? I'm pretty sure when I repeat code like that there must be a
> better way.
> 
> And 1 thing about readln and readf: I realized that I can't use readf
> to read words with spaces. And when there is a space entered with
> readf, the other words stay in the input buffer.(input buffer is what
> it is, right?) Then when I use readln (maybe readf too, I didn't check
> that), it automatically enters what was left over. How do I flush the
> input buffer?
> 
> Thanks.
> 
> -Michael P.
> 

define your own function

char[] dumpSpace(char[]  phrase)
{
phrase =  phrase.dup;
int i = 0;
foreach( character; phrase)
{
 if ( character != ' ' )
   phrase[i++] = character;
}
return phrase[0..i];
}

phraseOne =  phraseOneTwo.dumpSpace;
phraseTwo =  phraseTwo.dumpSpace;

Michael P.:
> read in 2 phrases, then use 2 foreach loops to check for spaces and remove them.

No need to use foreach loops, learn to use string functions:

import std.stdio: putr = writefln;
import std.string: removechars;

void main() {
    string txt = "This is is a string".dup;
    putr(txt.removechars(" "));
}

Output:
Thisisisastring

Bye,
bearophile

bearophile Wrote:

> Michael P.:
> > read in 2 phrases, then use 2 foreach loops to check for spaces and remove them.
> 
> No need to use foreach loops, learn to use string functions:
> 
> import std.stdio: putr = writefln;
> import std.string: removechars;
> 
> void main() {
>     string txt = "This is is a string".dup;
>     putr(txt.removechars(" "));
> }
> 
> Output:
> Thisisisastring
> 
> Bye,
> bearophile


Any reason why you put:

import std.stdio: putr = writefln;
import std.string: removechars;

instead of just:

import std.stdio;
import std.string;

???

Michael P.:
> Any reason why you put:
> import std.stdio: putr = writefln;
> import std.string: removechars;
> 
> instead of just:
> import std.stdio;
> import std.string;

The putr/put is just a personal thing of mine, I prefer those names for the printing functions because they are shorter and simpler/faster to write, and equally clean. Those names in my D libs refer to real printing functions (instead of being just aliases) that have many improvements over the writefln/writef (Tango defines yet other printing functions, different from the Phobos ones).


The specification of the names you want to import from the modules is a good practice that allows you to:
- keep your namespace more clean, avoiding some name clashes, because import foo imports all the names in foo and some more (see below).
- show the person that reads the code (and isn't using an IDE) where each imported name used in the module comes from.

Note that the design of the D module system has some holes/rough edges still, for example the following program doesn't give a compilation error:

import std.stdio;
void main() {
    writefln(10);
    std.stdio.writefln(10);
    std.stdio.writef(10, \n);
}

It means the import imports the names inside the std.stdio module and the name std.stdio itself too (this has some practical consequences, for example you generally can't put inside a module named 'foo' a function named 'foo', because it may cause problems).
Hopefully similar silly problems in the D module system will be eventually seen as actual bugs, and fixed.

A better semantic is to change the module system to make this:
import somemodule;
mean just import the 'somemodule' module name in the current namespace.
So then somemodule.somefun() is legal but somefun() is not.
If you want (discouraged practice) to import all names from a module a specific syntax may be invented, like:
import somemodule.*;
Or something similar. After that somefun() can be used but somemodule.somefun() doesn't exists because the 'somemodule' name itself isn't imported in the current namespace.
There are various other problems in the module system (try using various modules for a little of time and you will probably be able to find various other silly situations  where it breaks apart) that can be solved sitting at a table and inventing (or just copying it from a language that has invented it before) a simple logically coherent system instead of the half-unfinished pile of things half-fixed and half copied from the Python module system, etc currently present in D 1.x.
I just hope that the current module system isn't fixed in stone, and such problems will be sorted out in D 2.x or even 3.x :-)

Bye,
bearophile

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:g8dcs6$lro$1@digitalmars.com...

> The specification of the names you want to import from the modules is a
> good practice that allows you to:
> - keep your namespace more clean, avoiding some name clashes, because
> import foo imports all the names in foo and some more (see below).

...except due to bugs 313 and 314, you end up polluting the namespace even more when using selective imports, since they are always made implicitly public.  Fun.

> A better semantic is to change the module system to make this:
> import somemodule;
> mean just import the 'somemodule' module name in the current namespace.
> So then somemodule.somefun() is legal but somefun() is not.

So, you want "static import" to be the default.

Jarrett Billingsley:
> ...except due to bugs 313 and 314, you end up polluting the namespace even more when using selective imports, since they are always made implicitly public.  Fun.

I see, I don't know what to answer you -.-
Many of the bugs/problems I have found in the D module system are already in bugzilla.
Assuming such bugs will be fixed I believe those D practices of mine become good ;-)


> So, you want "static import" to be the default.

In years of programming I have seen that keeping things tidy helps me avoid bugs. And Python module systems works like that.

Bye,
bearophile

bearophile Wrote:

> Michael P.:
> > Any reason why you put:
> > import std.stdio: putr = writefln;
> > import std.string: removechars;
> > 
> > instead of just:
> > import std.stdio;
> > import std.string;
> 
> The putr/put is just a personal thing of mine, I prefer those names for the printing functions because they are shorter and simpler/faster to write, and equally clean. Those names in my D libs refer to real printing functions (instead of being just aliases) that have many improvements over the writefln/writef (Tango defines yet other printing functions, different from the Phobos ones).
> 
> 
> The specification of the names you want to import from the modules is a good practice that allows you to:
> - keep your namespace more clean, avoiding some name clashes, because import foo imports all the names in foo and some more (see below).
> - show the person that reads the code (and isn't using an IDE) where each imported name used in the module comes from.
> 
> Note that the design of the D module system has some holes/rough edges still, for example the following program doesn't give a compilation error:
> 
> import std.stdio;
> void main() {
>     writefln(10);
>     std.stdio.writefln(10);
>     std.stdio.writef(10, \n);
> }
> 
> It means the import imports the names inside the std.stdio module and the name std.stdio itself too (this has some practical consequences, for example you generally can't put inside a module named 'foo' a function named 'foo', because it may cause problems).
> Hopefully similar silly problems in the D module system will be eventually seen as actual bugs, and fixed.
> 
> A better semantic is to change the module system to make this:
> import somemodule;
> mean just import the 'somemodule' module name in the current namespace.
> So then somemodule.somefun() is legal but somefun() is not.
> If you want (discouraged practice) to import all names from a module a specific syntax may be invented, like:
> import somemodule.*;
> Or something similar. After that somefun() can be used but somemodule.somefun() doesn't exists because the 'somemodule' name itself isn't imported in the current namespace.
> There are various other problems in the module system (try using various modules for a little of time and you will probably be able to find various other silly situations  where it breaks apart) that can be solved sitting at a table and inventing (or just copying it from a language that has invented it before) a simple logically coherent system instead of the half-unfinished pile of things half-fixed and half copied from the Python module system, etc currently present in D 1.x.
> I just hope that the current module system isn't fixed in stone, and such problems will be sorted out in D 2.x or even 3.x :-)
> 
> Bye,
> bearophile


Okay, I get it. Thanks. And I got the space removing thing working too. -Michael P.