From: Le Chaud Lapin on
On Jul 4, 3:43 am, Dragan Milenkovic <dra...(a)> 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.

> 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-
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].

What other language allows all of this without the help of a companion

-Le Chaud Lapin-

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Walter Bright on
Mathias Gaunard wrote:
> On Jul 3, 1:29 am, Walter Bright <newshou...(a)> wrote:
>> Mathias Gaunard wrote:
>>> On Jun 30, 8:51 am, Daniel <danielapar...(a)> wrote:
>>>> It doesn't do functional well.
>>> It does it pretty well, even if C++0x lambdas are disappointing.
>> Functional programming requires data immutability and function purity.
> Nothing prevents you from restricting yourself to a subset of C++
> where all data is immutable and all functions pure.

That's true, except that there is absolutely no help from the C++
compiler at
all for this. It's like K&R style C, where there was no checking of the
types of
function arguments. Sure, you could get it right by carefully doing the
by hand, but adding in function prototypes was a HUGE win.

For example, let's say you have:

virtual int my_pure_function(struct S *s);

And your code that calls my_pure_function relies on it being pure, and
that s
points to a transitively immutable data structure.

How do you know the function actually is pure, without going through
every line
of code in it, and every line of code in every function it calls, all
the way to
the bottom?

Now another fellow on your team adds a global state dependency somewhere
deep in
that call hierarchy. How are you to know? Suppose someone else derives and
overrides my_pure_function with an impure one? How are you to stop that?

What if, between calls, someone modifies something s is transitively
pointing to?

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.)

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Joshua Maurice on
On Jul 4, 10:41 am, Andre Kaufmann <akfmn...(a)> wrote:
> On 04.07.2010 00:50, Dragan Milenkovic wrote:
> > However, what would be really nice is something to make
> > the pimlp idiom obsolete. :-D
> Yep, a module concept is IMHO badly needed in C++. Unfortunately it has
> been removed from the first C++0x proposals.

Can you point at any proposals or ideas? I'm not sure how "modules"
would remove the need for pimpl. pimpl is an idiom whose goal is to
remove headers from headers. This allows a correct incremental build
to skip larger proportions of the build because there are less file
dependencies. I don't see an intuitive way to have backwards
compatibility, 'not require pimpl', and achieve this 'closer to
minimal' incremental build.

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Ian Collins on
On 07/ 4/10 08:48 PM, Jerry Stuckle wrote:
> Andre Kaufmann wrote:
>> - Can I mix libraries written with different C++ compilers
> Can you do this in ANY language?

C. Otherwise there would only be one compiler per platform!

Ian Collins

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Jens Schmidt on
Andre Kaufmann wrote:

> We had a lot of trouble adding Unicode support to our C++ applications.
> To be binary compatible we used UTF8 for transportation and internally
> used UTF16 where possible. But it happened more than once that multiple
> conversions (text / xml / binary etc.) that we missed to convert the
> characters at one location appropriately. Such bugs where quite hard to
> find and we are not sure if we found them all already.
> 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
Jens Schmidt

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]