Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
August 18, 2008 taking a character out of a string | ||||
---|---|---|---|---|
| ||||
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. |
August 18, 2008 Re: taking a character out of a string | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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;
}
|
August 18, 2008 Re: taking a character out of a string | ||||
---|---|---|---|---|
| ||||
Posted in reply to Michael P. | 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;
|
August 18, 2008 Re: taking a character out of a string | ||||
---|---|---|---|---|
| ||||
Posted in reply to Michael P. | 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
|
August 19, 2008 Re: taking a character out of a string | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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;
???
|
August 19, 2008 Re: taking a character out of a string | ||||
---|---|---|---|---|
| ||||
Posted in reply to Michael P. | 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
|
August 19, 2008 Re: taking a character out of a string | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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. |
August 19, 2008 Re: taking a character out of a string | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | 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 |
August 19, 2008 Re: taking a character out of a string | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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.
|
Copyright © 1999-2021 by the D Language Foundation