Hi!
I have a STL string, which I need to convert to low case.
In VC 6 I used:
string sInputBuffer = _strlwr((char*)sBuffer.c_str());
However, now in MSVC.NET 2005 I am getting a warning, that _strlwr is
depricated. Instead, it's proposed to use _strlwr_s : http://msdn2.microsoft.com/en-us/library/y889wzfw.aspx
How should I use this new function with STL, if I don't want to
allocate memory on heap.
Thanks.
Vadim 37 22366
Vadim wrote: Hi!
I have a STL string, which I need to convert to low case. In VC 6 I used: string sInputBuffer = _strlwr((char*)sBuffer.c_str());
Try this maybe (std C++ - don't know about MVC):
std::transform( sBuffer.begin(), sBuffer.end(), sBuffer.begin(),
::tolower );
Cheers,
Andre
Vadim wrote: Hi!
I have a STL string, which I need to convert to low case. In VC 6 I used: string sInputBuffer = _strlwr((char*)sBuffer.c_str());
However, now in MSVC.NET 2005 I am getting a warning, that _strlwr is depricated. Instead, it's proposed to use _strlwr_s : http://msdn2.microsoft.com/en-us/library/y889wzfw.aspx
How should I use this new function with STL, if I don't want to allocate memory on heap.
Are you sure you need to convert to lower case? If all you want is
case insensitive comparison you might have a look at char_traits.
In article <11*********************@g14g2000cwa.googlegroups. com>,
Vadim <va*******@gmail.com> wrote: string sInputBuffer = _strlwr((char*)sBuffer.c_str());
Ouch. I suggest you look up the definition of _strlwr.
Also, note that c_str() returns a non-modifiable c-style string.
--
Mark Ping em****@soda.CSUA.Berkeley.EDU
Try this:
struct lowercase_func {
void operator()(std::string::value_type& v) { v = tolower(v); }
};
std::string make_lowercase(std::string s) {
for_each(s.begin(), s.end(), lowercase_func());
return s;
}
In message <11**********************@g49g2000cwa.googlegroups .com>, at******@gmail.com writes Try this:
struct lowercase_func { void operator()(std::string::value_type& v) { v = tolower(v); } }; std::string make_lowercase(std::string s) { for_each(s.begin(), s.end(), lowercase_func()); return s; }
But for_each is intended to be a non-modifying operation. OK, it will
work, but std::transform(s.begin(), s.end(), s.begin(), tolower) would
more clearly express your intention.
--
Richard Herring ro**********@gmail.com wrote: Are you sure you need to convert to lower case? If all you want is case insensitive comparison you might have a look at char_traits.
and exactly which function of char_traits would you use to do that?
Thanks for your help.
In fact, I do need to make some case insensitive finds, but since some
parts of my original string I will have to convert later to unified
case, I decieded to convert the original string to low case. It seems
that there is no any perfoamnce problem. 250 Kb file in my string is
converted to low case almost without seeing delay in "Step over"
debugging.
I do have perfomance problem with reading from file and I guess you can
help me:
I have a text file, which I read entirely to my string variable.
Originally I made some checks while reading, so my code looks like
that:
ifstream is;
is.open (INPUT_FILE);
string sInputBuffer;
while (is.good())
{
sInputBuffer+= is.get();
}
Now, I just only read the contents of the file to string buffer.
Reading char after char is definitely the bad thing. What would be the
most efficient way of reading the whole file?
Thanks a lot!
Vadim
> > struct lowercase_func { void operator()(std::string::value_type& v) { v = tolower(v); } }; std::string make_lowercase(std::string s) { for_each(s.begin(), s.end(), lowercase_func()); return s; } But for_each is intended to be a non-modifying operation. OK, it will work, but std::transform(s.begin(), s.end(), s.begin(), tolower) would more clearly express your intention.
You're right, std::transform should probably be used instead. However
(you may already know this) the direct usage of tolower is not
portable. See the discussion at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11108
Aaron
Richard Herring wrote: In message <11**********************@g49g2000cwa.googlegroups .com>, at******@gmail.com writesTry this:
struct lowercase_func { void operator()(std::string::value_type& v) { v = tolower(v); } }; std::string make_lowercase(std::string s) { for_each(s.begin(), s.end(), lowercase_func()); return s; } But for_each is intended to be a non-modifying operation. OK, it will work, but std::transform(s.begin(), s.end(), s.begin(), tolower) would more clearly express your intention.
Except transform does not modify the original, for_each does (so I
don's see how you can make that first statement actually). You can use
transform to modify like above but it is actually slower that using
for_each because you are copying AND assigning whereas for_each will
modify directly without either of those operations...although in this
particular case you do that anyway so it may be faster to use transform
and loose the extra call.
In every book I have ever seen for_each is listed as a modifying
algorithm along with transform, merge, fill, generate, etc... It is
perfectly legitimate to use it as such and quite common to do so.
In message <11**********************@g47g2000cwa.googlegroups .com>, ro**********@gmail.com writes Richard Herring wrote: In message <11**********************@g49g2000cwa.googlegroups .com>, at******@gmail.com writes >Try this: > >struct lowercase_func { > void operator()(std::string::value_type& v) { v = tolower(v); } >}; >std::string make_lowercase(std::string s) { > for_each(s.begin(), s.end(), lowercase_func()); > return s; >} > But for_each is intended to be a non-modifying operation. OK, it will work, but std::transform(s.begin(), s.end(), s.begin(), tolower) would more clearly express your intention.
Except transform does not modify the original, for_each does (so I don's see how you can make that first statement actually).
I make it because for_each appears in section 25.1.1 of the Standard at
25.1.1, the first sub-section of 25.1, "Non-modifying sequence
operations". The first two parameters of for_each are only required to
be input iterators and its "Effects" clause does not say that anything
pointed to by the iterators is modified.
You can use transform to modify like above but it is actually slower that using for_each because you are copying AND assigning whereas for_each will modify directly without either of those operations...although in this particular case you do that anyway so it may be faster to use transform and loose the extra call.
In every book I have ever seen for_each is listed as a modifying algorithm along with transform, merge, fill, generate, etc...
That might surprise the authors of the Standard.
It is perfectly legitimate to use it as such
It's an obvious extension of the semantics required by the Standard,
provided that you pass parameters which happen to satisfy the
requirements of a mutable iterator. I'll leave it to the language
lawyers to argue whether that translates to "perfectly legitimate".
and quite common to do so.
--
Richard Herring
Richard Herring wrote: In message <11**********************@g47g2000cwa.googlegroups .com>, ro**********@gmail.com writes In every book I have ever seen for_each is listed as a modifying algorithm along with transform, merge, fill, generate, etc...
That might surprise the authors of the Standard.
Only if they have completely independent, dual personalities.
By "authors of the Standard" I assume you mean people who were on the
committee...if you are talking about the people that did the
typesetting I don't know, nor do I care, what surprises them or doesn't.
In message <11**********************@o13g2000cwo.googlegroups .com>, ro**********@gmail.com writes Richard Herring wrote: In message <11**********************@g47g2000cwa.googlegroups .com>, ro**********@gmail.com writes >In every book I have ever seen for_each is listed as a modifying >algorithm along with transform, merge, fill, generate, etc...
Let's see...
How about Bjarne Stroustrup, "The C++ Programming language", Third
Edition, where for_each is described in section 18.5, "Nonmodifying
Sequence Algorithms" ? Granted, he goes on to explain how it can be used
as a modifying algorithm, but it's quite definitely in the nonmodifying
section of the relevant chapter.
Or Matthew H Austern, "Generic Programming and the STL", where for_each
is in chapter 11, "Nonmutating Algorithms"? That might surprise the authors of the Standard.
Only if they have completely independent, dual personalities.
By "authors of the Standard" I assume you mean people who were on the committee...
I mean those who assigned for_each to the category of non-modifying
sequence operations in the Standard. And who make no reference in the
same standard to using it with anything other than forward iterators,
and no mention of it modifying the sequence.
if you are talking about the people that did the typesetting I don't know, nor do I care, what surprises them or doesn't.
I don't believe typographical error is involved here.
--
Richard Herring ro**********@gmail.com wrote: Only if they have completely independent, dual personalities.
By "authors of the Standard" I assume you mean people who were on the committee...if you are talking about the people that did the typesetting I don't know, nor do I care, what surprises them or doesn't.
If you really want a modifying for_each then write one.
template
<
typename InOutIter,
typename Op
Op for_each2( InOutIter start, const InOutIter & end, Op op )
{
for( ; start != end ; ++start )
{
op( *start );
}
return op;
}
Not exactly difficult now was that.
On 17 Jan 2006 05:17:49 -0800, "Vadim" <va*******@gmail.com> wrote: Now, I just only read the contents of the file to string buffer. Reading char after char is definitely the bad thing. What would be the most efficient way of reading the whole file?
Look at getline(). It reads a whole line at a time.
rossum
--
The ultimate truth is that there is no ultimate truth
Earl Purple wrote: ro**********@gmail.com wrote: Only if they have completely independent, dual personalities.
By "authors of the Standard" I assume you mean people who were on the committee...if you are talking about the people that did the typesetting I don't know, nor do I care, what surprises them or doesn't. If you really want a modifying for_each then write one.
You don't need to.
Not exactly difficult now was that.
I really fail to understand what call there was for that. ro**********@gmail.com wrote: You don't need to.
Not with most implementations but according to the standard, someone
might implement for_each to not work in writable mode, in which case
there would be a need to.
I really fail to understand what call there was for that.
By the way you still haven't answered my post above on how you would
implement case-insensitive lookup using char_traits.
In article <B2**************@baesystems.com>,
Richard Herring <ju**@[127.0.0.1]> wrote: In message <11**********************@o13g2000cwo.googlegroups .com>, ro**********@gmail.com writes Richard Herring wrote: In message <11**********************@g47g2000cwa.googlegroups .com>, ro**********@gmail.com writes
>In every book I have ever seen for_each is listed as a modifying >algorithm along with transform, merge, fill, generate, etc...
Let's see...
How about Bjarne Stroustrup, "The C++ Programming language", Third Edition, where for_each is described in section 18.5, "Nonmodifying Sequence Algorithms" ? Granted, he goes on to explain how it can be used as a modifying algorithm, but it's quite definitely in the nonmodifying section of the relevant chapter.
Let's do that...
The for_each() algorithm is classified as nonmodifying because it
doesn't explicitly modify a sequence. However, if applied to a
non-const sequence for_each()'s operation (its third argument) may
change the elements of the sequence."
He even gives an example. Hummm...
You see, a "modifying" algorithm is called such because it explicitly
changes some sequence, not because it allows a sequence to be changed.
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.
In message <po******************************@news.east.earthl ink.net>,
Daniel T. <po********@earthlink.net> writes In article <B2**************@baesystems.com>, Richard Herring <ju**@[127.0.0.1]> wrote:
In message <11**********************@o13g2000cwo.googlegroups .com>, ro**********@gmail.com writes > >Richard Herring wrote: >> In message <11**********************@g47g2000cwa.googlegroups .com>, >> ro**********@gmail.com writes > >> >In every book I have ever seen for_each is listed as a modifying >> >algorithm along with transform, merge, fill, generate, etc...
Let's see...
How about Bjarne Stroustrup, "The C++ Programming language", Third Edition, where for_each is described in section 18.5, "Nonmodifying Sequence Algorithms" ? Granted, he goes on to explain how it can be used as a modifying algorithm, but it's quite definitely in the nonmodifying section of the relevant chapter.
Let's do that...
The for_each() algorithm is classified as nonmodifying because it doesn't explicitly modify a sequence. However, if applied to a non-const sequence for_each()'s operation (its third argument) may change the elements of the sequence."
He even gives an example. Hummm...
You see, a "modifying" algorithm is called such because it explicitly changes some sequence, not because it allows a sequence to be changed.
Right. So according to that definition too, for_each is not a modifying
algorithm.
--
Richard Herring
Richard Herring wrote: In message <po******************************@news.east.earthl ink.net>, Daniel T. <po********@earthlink.net> writesIn article <B2**************@baesystems.com>, Richard Herring <ju**@[127.0.0.1]> wrote:
In message <11**********************@o13g2000cwo.googlegroups .com>, ro**********@gmail.com writes > >Richard Herring wrote: >> In message <11**********************@g47g2000cwa.googlegroups .com>, >> ro**********@gmail.com writes > >> >In every book I have ever seen for_each is listed as a modifying >> >algorithm along with transform, merge, fill, generate, etc...
Let's see...
How about Bjarne Stroustrup, "The C++ Programming language", Third Edition, where for_each is described in section 18.5, "Nonmodifying Sequence Algorithms" ? Granted, he goes on to explain how it can be used as a modifying algorithm, but it's quite definitely in the nonmodifying section of the relevant chapter.
Let's do that...
The for_each() algorithm is classified as nonmodifying because it doesn't explicitly modify a sequence. However, if applied to a non-const sequence for_each()'s operation (its third argument) may change the elements of the sequence."
He even gives an example. Hummm...
You see, a "modifying" algorithm is called such because it explicitly changes some sequence, not because it allows a sequence to be changed.
Right. So according to that definition too, for_each is not a modifying algorithm.
According to some arbitrary definition for_each may be classified as a
non-modifying algorithm (but for practical purposes it is and one of
its primary uses is to modify every element in a sequence. Running to
the standard, which picks such an arbitrary definition because
standards have to, to back the assertion that it shouldn't be used for
such purposes is silly. The standard does not require that the
operator has no side effects and so long as you are passing a mutable
iterator and can bypass item assignment it is very likely to be in you
best interests to do so.
Earl Purple wrote: ro**********@gmail.com wrote: You don't need to. Not with most implementations but according to the standard, someone might implement for_each to not work in writable mode, in which case there would be a need to.
Would require a casting of a template type to a const version of that
type. VERY unlikely and would turn up very quickly. This is a
non-issue. I really fail to understand what call there was for that.
By the way you still haven't answered my post above on how you would implement case-insensitive lookup using char_traits.
I didn't read such a post and if you are really interested go read
Thinking in C++ v2 or any other book that talks about
char_traits....hell, do a google search. I'm not doing your homework
for you. ro**********@gmail.com wrote: I didn't read such a post and if you are really interested go read Thinking in C++ v2 or any other book that talks about char_traits....hell, do a google search. I'm not doing your homework for you.
It's not my homework, it's yours. You said it could be done with
char_traits so I am asking you to prove it.
Earl Purple wrote: ro**********@gmail.com wrote:
I didn't read such a post and if you are really interested go read Thinking in C++ v2 or any other book that talks about char_traits....hell, do a google search. I'm not doing your homework for you.
It's not my homework, it's yours. You said it could be done with char_traits so I am asking you to prove it.
I gave you a direct source. The very same source I first learned the
technique from in fact. You can get this source for free on the
Internet.
I don't have, need, or want to prove anything to you. If you are
actually interested in learning you have all the information you need
to go do so. If, as it seems, you just want to hassle someone about
advice they gave to someone else (and just an idea that could be looked
into at that) then you are wasting my time, and I don't like that.
This is as far as I go.
In message <11**********************@g44g2000cwa.googlegroups .com>, ro**********@gmail.com writes Richard Herring wrote: In message <po******************************@news.east.earthl ink.net>, Daniel T. <po********@earthlink.net> writes >In article <B2**************@baesystems.com>, > Richard Herring <ju**@[127.0.0.1]> wrote: > >> In message <11**********************@o13g2000cwo.googlegroups .com>, >> ro**********@gmail.com writes >> > >> >Richard Herring wrote: >> >> In message <11**********************@g47g2000cwa.googlegroups .com>, >> >> ro**********@gmail.com writes >> > >> >> >In every book I have ever seen for_each is listed as a modifying >> >> >algorithm along with transform, merge, fill, generate, etc... >> >> Let's see... >> >> How about Bjarne Stroustrup, "The C++ Programming language", Third >> Edition, where for_each is described in section 18.5, "Nonmodifying >> Sequence Algorithms" ? Granted, he goes on to explain how it can be used >> as a modifying algorithm, but it's quite definitely in the nonmodifying >> section of the relevant chapter. > >Let's do that... > > The for_each() algorithm is classified as nonmodifying because it > doesn't explicitly modify a sequence. However, if applied to a > non-const sequence for_each()'s operation (its third argument) may > change the elements of the sequence." > >He even gives an example. Hummm... > >You see, a "modifying" algorithm is called such because it explicitly >changes some sequence, not because it allows a sequence to be changed. Right. So according to that definition too, for_each is not a modifying algorithm.
According to some arbitrary definition for_each may be classified as a non-modifying algorithm (but for practical purposes it is and one of its primary uses is to modify every element in a sequence. Running to the standard, which picks such an arbitrary definition because standards have to,
This particular standard is full of footnotes and other clarifying text
where such a decision could be justified if it truly was arbitrary, but
on this issue it's silent.
to back the assertion that it shouldn't be used for such purposes is silly.
(No sillier than claiming that "every book" backs the opposite view.)
If I had made any such assertion, it would indeed be silly. All I said
was that since for_each is classified as non-modifying, using an
explicitly modifying algorithm, std::transform, would more clearly
express the original poster's intent.
The standard does not require that the operator has no side effects and so long as you are passing a mutable iterator and can bypass item assignment it is very likely to be in you best interests to do so.
Possibly. Since in the original example assignment still occurs when
using for_each, the hypothetical performance improvement of bypassing it
doesn't arise here.
--
Richard Herring
Richard Herring wrote: In message <11**********************@g44g2000cwa.googlegroups .com>, ro**********@gmail.com writes The standard does not require that the operator has no side effects and so long as you are passing a mutable iterator and can bypass item assignment it is very likely to be in you best interests to do so. Possibly. Since in the original example assignment still occurs when using for_each, the hypothetical performance improvement of bypassing it doesn't arise here.
I stated such in my original reply...maybe you should read it again. ro**********@gmail.com wrote: I don't have, need, or want to prove anything to you. If you are actually interested in learning you have all the information you need to go do so. If, as it seems, you just want to hassle someone about advice they gave to someone else (and just an idea that could be looked into at that) then you are wasting my time, and I don't like that.
This is as far as I go.
It's because you don't know. And I do know because I have implemented a
specialised version of char_traits. And I know that char_traits has a
compare() function but that is equivalent to memcmp() and has no
knowledge of lower and upper-case at all.
If there were such a function it would be in locale but even there it
doesn't actually exist.
Earl Purple wrote: ro**********@gmail.com wrote: I don't have, need, or want to prove anything to you. If you are actually interested in learning you have all the information you need to go do so. If, as it seems, you just want to hassle someone about advice they gave to someone else (and just an idea that could be looked into at that) then you are wasting my time, and I don't like that.
This is as far as I go.
It's because you don't know. And I do know because I have implemented a specialised version of char_traits.
Then you already know how to do it and you are just being a jerk for no
reason that is apparent to me.
Goodbye now...have fun with that attitude. ro**********@gmail.com wrote: Then you already know how to do it and you are just being a jerk for no reason that is apparent to me.
Goodbye now...have fun with that attitude.
Well I don't know how to do it with char_traits, I think it is
impossible. It is possible to do wtih locale but not directly, i.e. you
have to use a tolower or toupper member of locale, because I am not
aware of any general string conversion or case-insensitive comparison
method in locale.
I do think there should be a case-sensitive comparison in C++ and I
think locale would be the correct library in which to implement it.
Earl Purple wrote: ro**********@gmail.com wrote: Then you already know how to do it and you are just being a jerk for no reason that is apparent to me.
Goodbye now...have fun with that attitude.
Well I don't know how to do it with char_traits, I think it is impossible.
Well, like I said, you now know of and have ready access to the very
source I got the technique from. I believe it is also explained in
Josuttis but I may be mistaken. You can read it, learn it, and make up
your own mind whether to use it. ro**********@gmail.com wrote: Earl Purple wrote: It's not my homework, it's yours. You said it could be done with char_traits so I am asking you to prove it.
I gave you a direct source.
I can't see that. What am I missing?
You brought up a very interesting topic (using char_traits for case
insensitive string comparisons). It would have been nice if you would
have elaborated more on the topic (for all our benefit).
Failing to see your source, here's what I came up with on Herb Sutter's
page: http://www.gotw.ca/gotw/029.htm
<synopsis>
The article by Herb Sutter outlines how to generate your own string
class that does everything stl::string does, but compares strings
independend of their case. He does so by creating a new ci_char_traits
class and defining a new string type:
typedef basic_string<char, ci_char_traits> ci_string;
</synopsis>
The use of char_traits for this is very intruiging. Especially given
the fact that char_traits usuaally have been in the "black magic" camp
of the STL for me so far.
Cheers,
Andre in*****@gmail.com wrote: ro**********@gmail.com wrote: Earl Purple wrote: It's not my homework, it's yours. You said it could be done with char_traits so I am asking you to prove it.
I gave you a direct source.
I can't see that. What am I missing?
The rest of my post.
Thinking in C++ v2. in*****@gmail.com wrote: <synopsis> The article by Herb Sutter outlines how to generate your own string class that does everything stl::string does, but compares strings independend of their case. He does so by creating a new ci_char_traits class and defining a new string type: typedef basic_string<char, ci_char_traits> ci_string; </synopsis>
If you did that you'd have to implement the compare function but doing
that will still require a toupper or tolower call.
Is it really worth rewriting the whole of char_traits just to do that?
You may as well just write a comparison functor (so you can use it as a
predicate in std::map).
Sorry Roberts, but you act like a troll.
It's clear you "wondered" it is easy to implement it with char_traits
Or you may be nice and explain to Earl and to us how to implement it :)
This is the purpose of newsgroups
Diego Martins wrote: Sorry Roberts, but you act like a troll.
It's clear you "wondered" it is easy to implement it with char_traits
Or you may be nice and explain to Earl and to us how to implement it :)
This is the purpose of newsgroups
You can do case insensitive comparisons with strings if you use/create
the strings with the correct char_traits. Stroustrup talks about this
in his book "The C++ Programming Language" 3rd edition. I don't
remember the exact pages, but I'm pretty sure it's in the "Strings"
chapter.
You basically create a "ci_string" class like so:
typedef basic_string<char, ct> ci_string;
....where "ct" is your own char_traits class. The char_traits class has
a "eq" function that returns true if two chars are "equivalent". (It
also has many other functions as well.)
I don't really like this approach because you're defining a new kind of
"case insensitive string" that are essentially incompatible with all
"normal" strings, and are thus useless for lots of operations that you
would normally like to do with them (like many iostream operations).
Aaron
Diego Martins wrote: Sorry Roberts, but you act like a troll.
It's clear you "wondered" it is easy to implement it with char_traits
I don't understand that statement. Or you may be nice and explain to Earl and to us how to implement it :)
I did better. I gave a source. Why give a half ass explaination when
an expert source is readily available? God, for free even...
You people that are bitching about this are just lazy. Go download and
read "Thinking in C++ V2" if you are truely interested. I really don't
think you are and so you probably won't and will continue complaining...
Aaron Graham wrote: I don't really like this approach because you're defining a new kind of "case insensitive string" that are essentially incompatible with all "normal" strings, and are thus useless for lots of operations that you would normally like to do with them (like many iostream operations).
Yeah, all your streams and such have to use those traits in order to
read directly and you can't assign to or copy directly into 'normal'
strings. It can be a useful technique though in some cases. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: karthi |
last post by:
hi,
I need user defined function that converts string to float in c.
since the library function atof and strtod occupies large space in
my processor memory I can't use it in my code.
regards,...
|
by: Edvin |
last post by:
Why is binary array written to a file different
than when converting the binary array to string
and then writing it to file! For example:
// --- Allocate byte array
byte arrByte = new byte;...
|
by: Russell Warren |
last post by:
I've got a case where I want to convert binary blocks of data (various
ctypes objects) to base64 strings.
The conversion calls in the base64 module expect strings as input, so
right now I'm...
|
by: Brian Parker |
last post by:
I am beginning to work with VB2005.NET and I'm getting some problems
with string formatting converting an application from VB6.
VB6 code:-
sTradeDate = Format(pArray(4,i Record), "mmddyy")
...
|
by: phpCodeHead |
last post by:
Code which should allow my constructor to accept arguments:
<?php
class Person {
function __construct($name)
{
$this->name = $name;
}
function getName()
|
by: Mosfet |
last post by:
Hi,
what is the most efficient way of doing a case insensitive comparison ?
I am trying to write a universal String class and I am stuck with the
case insensitive part :
TCHAR is a char in...
|
by: gaga |
last post by:
my function should accept a pointer to a string as its argument. and
it should convert each charater to an uppercase letter. I know what i
need to do, its just my syntax is all out of whack.
...
|
by: J Peyret |
last post by:
Well, as usual I am confused by unicode encoding errors.
I have a string with problematic characters in it which I'd like to
put into a postgresql table.
That results in a postgresql error so I...
|
by: Jamenson |
last post by:
Hi everyone!
I want to convert strings like "LEONARDO DI CAPRIO" to "Leonardo di
Caprio". The function StrConv converts to "Leonardo Di Caprio" and we
think it is innapropriated.
Any help...
|
by: kronus |
last post by:
I'm receiving an xml file that has a child called modified and it represents a date value in the form of a string -- Nov 14, 2008 -- and in my app, I have items associated with each object and I'm...
|
by: DolphinDB |
last post by:
Tired of spending countless mintues downsampling your data? Look no further!
In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: jfyes |
last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
|
by: PapaRatzi |
last post by:
Hello,
I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Defcon1945 |
last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
|
by: Shællîpôpï 09 |
last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
|
by: af34tf |
last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
| |