From: joe on
Andre Kaufmann wrote:
>
> Agreed, C# and Java strings are not perfect, but better than C++
> standard strings regarding Unicode. I think C# has been influenced by
> Windows Unicode support.
>

What is wrong with fixed-width Unicode (UCS-2 or UCS-4)? If someone has
put those out in the dumpster, then I'm a garbage-picker! You make it
sound like fixed-width is evil. Do tell what you think/are thinking!



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Le Chaud Lapin on
On Jul 5, 2:06 pm, Jens Schmidt <Jens.Schmidt...(a)gmx.de> wrote:
> Andre Kaufmann wrote:
> > Besides the subtle bugs caused by functions dealing with character
> > pointers and number of characters directly.
>
> There are rumors of C++ being better because of static type checking. :-)
> Is there any project or whatever to use that for Unicode support?
> Like having different types for utf8_string, ucs32_string,
> unicode_character (a group of base character with accents), together with
> useful operations and conversions?
> Maybe even url_encoded_string, html_encoded_string, xml_encoded_string and
> sql_encoded_string to prevent problems like cross site scripting and SQL
> injection.

Not familiar with any such projects, but I had my "make a good string
class experience" about a year ago where I bit the bullet and read all
essential documents at:

http://site.icu-project.org/
http://www.unicode.org/

During this (somewhat painful) experience, I concluded that, in the
majority of C++ coding situations, it is best to have a single, non-
templated string type, and _yield_ from objects of that type various
other objects as needed.

The string class should be "fat", having a rich set of operations,
essentially those already determined by ICU/UNICODE. For example, it
should be possible to transliterate from a source string to a target
string with very little programmer effort.

On a controversial note, I also concluded that it is best to let the
string objects be entirely responsible for their collation behavior.
IOW, no compile-time fiddling with case/no-case stuff, varied
languages. Put everything that is required in the string objects
themselves, at run-time.

This eliminates the problem of unmitigated, forced propagation of type
distinction through out the type system, where, for example, a
templated container that would have normally accommodated only one
string type must now accommodate all the possible string types,
causing a combinatorial explosion in the type space.

The decision to use a fat string class has been surprisingly
liberating. :D

I exercised extreme ingenuity and originality in naming my string
class...

"String"

-Le Chaud Lapin-


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Dragan Milenkovic on
Walter Bright wrote:
[snip]
> Because of this, I suspect that trying to use purity and immutability
> purely by
> convention is doomed to failure.
>
> (And also, since the compiler cannot know about its purity and
> immutability, it
> also cannot take any advantage of that information to produce better
> code. The
> compiler cannot even cache pointer to const values.)

GCC provides attributes "pure" and "const" which indeed allow
taking advantage. However, it seems that it doesn't verify
the correctness of implementation. I don't know how easy such
a feature could be added (my guess is not too hard),
and whether it would be beneficial.

--
Dragan

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Dragan Milenkovic on
Andre Kaufmann wrote:
> Jerry Stuckle wrote:
>> Andre Kaufmann wrote:
>>> Mathias Gaunard wrote:
>>>> On Jul 1, 4:14 pm, n...(a)cam.ac.uk wrote:
>> [...]
>>
>>> - Emit code and compile on the fly - C++ scripting ?
>> Who cares?
>
> Is that a typical "default answer" ?
>
>> It's an entirely different model.
>
> Many languages offer that. E.g. C#.
> And the model is not different. Why can't I simply take a C++ code like
>
> double value = sin(x)/x;
>
> (the formula has been entered in an edit box)
>
> compile it in the background and let it execute instead of interpret it.
> Wouldn't that be faster than just interpreting the formula ?
> I can exactly do that in C#.

Doesn't boost::python offer such functionality? I didn't exactly compile
the code in the background, but I did write plugins and it was
very easy. It works the both ways.

How is security implemented in the mentioned C# feature? I'm guessing
it wouldn't let just any code compile and/or execute.

> Or take a complex regular expression. Why can't I simply compile it to
> code. In C# I can do that.
>
>>> - Can you take a function as an argument and parse it's structure?
>> Who cares? That's not the intent of C++.
>
> Why do so many try to do/simulate that with C++ meta template programming ?

The two are different. With meta programming you can get compile-time
diagnostics. Can you have this done in any other language?

>>> - Can I interchange / directly call code written in other languages
>>> without writing C wrappers ?

Again boost::python... a place that ain't no got no room for wrappers.

[snip]
>>> - Can I mix libraries written with different C++ compilers
>> Can you do this in ANY language?

Isn't this more ABI related? I don't think C++ itself imposes
such limitation. Unfortunately, I'm not familiar with ABI-related
future improvements.

[snip]
>>> - Can I mix C++ code libraries compiled for different platforms
>> Can you do this in ANY language?
>
> C# for example.

Hm... Do you ever _really_ _need_ to do this? The only case I can think
of is when there is only a library for one platform and no way and
no source to build it for another. But this requires a kind of
virtual machine or such environment, which is not the goal of C++.

Should such need come, I would just use Java...

>
>>> - Can I write portable GUIs in C++ (e.g. with Qt but, isn't standard)
>> Can you do this in ANY language?
>
> Better than in C++.

Because after quite a few generations of failures they finally got
it right... Think AWT, MFC... or did they get it right? I don't know...

[snip]
>
>>> - Can I initialize class member objects / values directly where
>>> they are defined.
[snip]
>> Nope, that's what constructors are for.
>
> Do you need are more detailed explanation about the advantages ?
>
> Yes I want to call the constructor of the value where I define it ->
> RAII - not have to write it multiple times in different constructors.
> Though C++0x addresses this problem somewhat with delegating constructors.

I don't think it's "somewhat". IMHO, they really hit the nail with
that one.

private:
foo() : value1(10), value2(10), value3(10) {}
public:
foo(int a) : foo() {}

> Additionally static values do use this initialization scheme already:
>
> class a
> {
> static int value;
> };
>
> int a::value = 0;
>
> Huh ? No constructor involved ?

And why would there be a constructor involved with a static value?
I don't think that those two cases can be compared.

>> [...]
>> But virtually everything you want either shows no understanding of the
>
> Sound like you described yourself.
>
>> language itself, or has nothing to do with the language itself.
>> Sounds like you want Java instead.
>
> Nope.
>
> I either want the D-Language or C# with RAII.

Well, maybe we should lobby that C# gets a RAII? In the end,
it is only one feature compared to many missing ones of C++.
Anyway, to cut the silly talk... C++ has some shortcomings,
most of them coming as a legacy, but these presented here are
more ABI and library/environment (don't know how else to name it)
related.

--
Dragan

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Dragan Milenkovic on
Le Chaud Lapin wrote:
> On Jul 4, 3:43 am, Dragan Milenkovic <dra...(a)plusplus.rs> wrote:
>> Le Chaud Lapin wrote:
>> Hm... but are you saying that people should walk the hardest path
>> in order to earn a proper label? If one has the attitude of wanting
>> "to know what's really going on", one will be much more involved
>> whatever language chosen. And the path will be much easier and
>> gains greater if one is open minded and learns many languages.
>> Hard work vs proper work. "I want to know" == a good engineer.
>
> I am saying that, given two subjects, S1 and S2, if one has the choice
> to learn both, one might choose whichever, after learning, allows a
> scope of understanding that is a superset of the other.
>
> Knowing Java, well, facilitates understanding of many concepts in C++.
>
> Knowing C++, well, not only facilitates understanding of almost all
> concepts in Java, but one might begin to write a Java interpreter in C+
> +.
>
> As I have said before, it is not really possible to understand C++
> well and not have a good understanding of a large number of parasitic
> concepts that are the foundations of software engineering.

This is true and I agree. But if I'm not mistaken, this all started
by your statement that one should get there by simply learning C++.
I'm saying that one will not be able to do it this way, unless being
involved in a really, really, really great project with a good
design and experienced team-mates. And even then, IMHO, one is better
learning many languages; it will improve his C++ kung fu.

>
>> I will only agree that understanding C++ gives a unique and invaluable
>> perspective. Notice how I used "understanding" instead of "learning".
>> You may learn as much as you like, but how will you understand
>> any concepts other than the ones you use to solve your problems
>> if not by solving a few problems in Java (maybe doing some EE), Python,
>> Lisp, Haskel, etc?
>
> So, if we are saying that there the problem domains are separate from
> the languages employed, then I would say that it is rare that I find
> myself in the position where I am obstructed by C++ while attacking a
> problem. C++, more than any other language, "gets out of my way" so I
> can solve the problem. I cannot say the same for other languages.
>
> For example, in my current project, I have:
>
> 1. Code that manipulates memory-mapped I/O registers.
> 2. Device driver code with kernel-mode primitives.
> 3. Several, miniature parsers/interpreters of other languages.
> 4. Full blown multi-threadeding code with generalized synchronization.
> 5. Ability to launch other executables with tight control over run-
> time.
> 6. Fast signal processing.
> 7. Fast string processing.
> 8. Database and caching.
> 9. Recursion.
> 10. Dynamic swapping of member functions in live objects.
> 11. Compactness.
> 12. Generalized serialization [no versioning though].
> 13. 99.7% portability [to multiple platforms, not just the one
> prescribed, like Java].

Nice project and a great opportunity for people to improve!
But I would have to say that these are features; and could
be designed both good or bad. You can (although I guess that
you don't and no one should) implement all of those and still
not have ever used std::shared_ptr, meta programming, etc.
May I call it: what vs. how?

You write from the perspective of a person that has a
high understanding of C++. However, the argument was
(again - unless I'm mistaken) about a person that is
on the start of the journey. If I hadn't chosen
a multilingual path, I would be quite a few years behind
with the learning curve.

Or let's agree that we disagree. I have just stated my opinion
and my experience in hope it would help someone.

--
Dragan

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]