Re: [Dev-C++] Re: newbie string parsing question

[<or...@vp...>]

Hi!

Could you pass me your XML editor? I currently have need of a good XML ed=
itor (only if=20
it's free of course). Using generic code-editors isn't the most comfortab=
le for me.

--
Greetings,
   Bal=E1zs

Per Westermark wrote:
> I have written compilers, XML editors and a number of other
> string-manipulating things, but 99% of the time when I use C-strings, I
> work with static buffers or make one-time assignments with strdup(). A =
lot
> of the manipulation doesn't even need any new buffers but may use direc=
t
> pointer substrings. The only realloc code I have are 3 or 4 small
> functions, about 5 lines each, that I wrote about 15 years ago to inser=
t
> and remove text in a dynamically allocated buffer. Hardly any bother to
> write. Hardly any bother to use.
>=20
> For doing reg-exp it doesn't matter if I use my code, or if I use a
> third-part library, such as the wxRegEx class from wxWidgets.
>=20
> The point is, I don't spend any time fighting any strxx() functions, si=
nce
> they are not enemies. They are one of several useful (good) tools to us=
e,
> not something to ignore because god has created std::string.
>=20
> There are a number of reasons to keep all options open. Some of them ar=
e:
> - C++ not available for a specific embedded environment.
> - The application may not include libstd++ because of code size (may co=
st
> huge amounts of money if application is updated through mobile phone)
> - Application must dynamically link with modules written using other
> compiler.
> - Application must interact with existing C libraries.
> - Preformance. std::string can not do anything that C/C++ can't do
> directly. Direct manipulation can do things that requires extra
> book-keeping (reference counting etc.) for a std::string solution.
>=20
> For most problems, there are a number of available solutions. Even if w=
e
> go to the extreme and compare C with C++, most problems can be solved i=
n a
> good way with or without objects or templates. The C implementation doe=
s
> not automatically need twice as much code or gets twice as many bugs.
>=20
> That is why - if people ask about a "C-type" problem - I don't say they
> have to use streams, strings etc. I mention that they are available, bu=
t
> at the same time discuss what to think about if the C functions are use=
d.
> In this case, that scanf() shouldn't be used without specifying maximum
> sizes for the strings, that it doesn't allocate the strings (except in =
a
> gnu extension) and that fgets()/strchr()/strtok() are the other common
> C-library solution to the problem. People becomes better programmers if
> they learn multiple solutions to the same problem.
>=20
> /Per W