www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - taking a character out of a string

reply Michael P. <baseball.mjp gmail.com> writes:
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.
Aug 18 2008
next sibling parent Wyverex <wyverex.cypher gmail.com> writes:
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; }
Aug 18 2008
prev sibling next sibling parent BCS <ao pathlink.com> writes:
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;
Aug 18 2008
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Aug 18 2008
parent reply Michael P. <baseball.mjp gmail.com> writes:
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; ???
Aug 18 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Aug 18 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
Aug 18 2008
parent bearophile <bearophileHUGS lycos.com> writes:
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
Aug 19 2008
prev sibling parent Michael P. <baseball.mjp gmail.com> writes:
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.
Aug 19 2008