«

Kenneth Brody <> wrote:

> On 8/22/2012 3:45 PM, BartC wrote:
> [...]
> > It's no surprise that there might be better languages for implementing
> > compilers with than C. Especially with much faster hardware now that allows
> > more productive languages to be used.
> >
> > But I wouldn't have chosen C++..
>
> Whitespace?
>
> INTERCAL?
>
> Or perhaps the oft-maligned Brainf**k?

I know that was said in jest, but with a good optimizer and some careful GC,
brainf**k can outperfom even the best hand coded C.

On 23.08.2012 22:17, Anonymous wrote:

>> Or perhaps the oft-maligned Brainf**k?
>
> I know that was said in jest, but with a good optimizer and some careful GC,
> brainf**k can outperfom even the best hand coded C.

That is not the question. Actually, this *never* is the question. If you
compare performances of different languages, you *will* need to take a
look at the abstraction level they provide. Merely comparing performance
alone is absolutely meaningless.

For example, obviously assembly language is at least as fast as *any*
compiled language (because they all are broken down into assembly). This
is not a reason to use assembly, however. In fact, most people will
sacrifice code optimality for abstration and use C (although this will
usually not yield ideal code).

Comparing *only* performance of languages with vast differences in the
abstraction they provide for the programmer is completly meaningless.

Best regards,
Joe

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$>

Le 24/08/12 15:09, Johannes Bauer a écrit :
> For example, obviously assembly language is at least as fast as*any*
> compiled language (because they all are broken down into assembly). This
> is not a reason to use assembly, however. In fact, most people will
> sacrifice code optimality for abstration and use C (although this will
> usually not yield ideal code).
>
> Comparing*only* performance of languages with vast differences in the
> abstraction they provide for the programmer is completly meaningless.

Precisely because of that I want to have a container library in C.

Surprisingly, most of the regulars in this group have worked against
this proposal

On 24.08.2012 17:53, jacob navia wrote:

>> Comparing*only* performance of languages with vast differences in the
>> abstraction they provide for the programmer is completly meaningless.
>
> Precisely because of that I want to have a container library in C.
>
> Surprisingly, most of the regulars in this group have worked against
> this proposal

What do you mean by "have worked aginst" it? You are obviously free to
work on whatever you deem worthy of working on. Nobody is stopping you
and you've already invested a significant effort in the CCL.

The question I do have is: why? Why use C and implement most of the
standard STL containers instead of using C++? It seems like the wrong
tool for the job.

If I proposed a container library for assembly language, containing
thousands of macros making the language much easier and comfortable and
less error, you'd agree that that was not time well spend, wouldn't you?
That doesn't mean that such a thing would be useless, but it means that
there are tools better suited for the job and which are already
complete, well-understood and working/tested.

Best regards,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$>

Le 24/08/12 19:02, Johannes Bauer a écrit :
> The question I do have is: why? Why use C and implement most of the
> standard STL containers instead of using C++? It seems like the wrong
> tool for the job.

Because I do not want C++!

The C++ guys are so completely convinced that their stuff is the best
discovery since sliced bread that they can't even IMAGINE that someone
doesn't WANT to use their pile of complexity.

This is a C group but it is full of people that think that C is just
obsolete and come here just to preach the advantages of their C++.

Why is C the wrong tool for the job?

My library is running at almost the same speed, has an easy to use
syntax and even more easy to use semantics. You do not get horrible
error messages because of some misplaced template bracket.

It is C.

You (and most people from C++) are unable to understand the advantages
of using a simple language without all the extra stuff of C++.

Le 24/08/12 19:02, Johannes Bauer a écrit :
> If I proposed a container library for assembly language, containing
> thousands of macros making the language much easier and comfortable and
> less error, you'd agree that that was not time well spend, wouldn't you?

Why not?

What's wrong with doing that?

Why do you think that code reuse is bad?

Only C++ is right, the rest of the programming world is wrong. I see the
mentality behind your reasoning.

On 24.08.2012 20:53, jacob navia wrote:

>> The question I do have is: why? Why use C and implement most of the
>> standard STL containers instead of using C++? It seems like the wrong
>> tool for the job.
>
> Because I do not want C++!

And nobody forced you to. I merely asked and you respond with such a rant.

> The C++ guys are so completely convinced that their stuff is the best
> discovery since sliced bread that they can't even IMAGINE that someone
> doesn't WANT to use their pile of complexity.

You are generalizing, using "The C++ guys" as stawmen. Anyone who thinks
that any language is the best since sliced bread is a moron. And anyone
who insist on using one PARTICULAR language, no matter what, is one too.

> This is a C group but it is full of people that think that C is just
> obsolete and come here just to preach the advantages of their C++.

That is not my opinion, actually. People in the group seem to like C
quite a lot. Why do you come to that conclusion?

> Why is C the wrong tool for the job?

For WHICH job? It always depends. For some things, C is *clearly* the
wrong tool. For other things it is the right tool. It always depends.

> My library is running at almost the same speed, has an easy to use
> syntax and even more easy to use semantics. You do not get horrible
> error messages because of some misplaced template bracket.

You're confusing the C++ language with the horrible error messages that
g++ spouts out when you do something wrong. Also, I agree that the C++
syntax is very complex and C is much easier to learn.

But that's not a valid argument. It's like saying a torque wrench is bad
because you can misuse it and it's more complicated than a standard
wrench. And every nut can be turned with a regular wrench anyways. Sure
it can. Nobody said it couldn't. Just for some uses, you wouldn't want to.

> It is C.
>
> You (and most people from C++) are unable to understand the advantages
> of using a simple language without all the extra stuff of C++.

You're wrong. I very clearly see the advantages and disadvantes of
C/C++. For some things, I use C. For others, I use C++. In contrast to
you, I make that decision based on the problem that I'm having, not
deciding up front.

Best regards,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$>

On 24.08.2012 21:08, jacob navia wrote:
> Le 24/08/12 19:02, Johannes Bauer a écrit :
>> If I proposed a container library for assembly language, containing
>> thousands of macros making the language much easier and comfortable and
>> less error, you'd agree that that was not time well spend, wouldn't you?
>
> Why not?

Because there are tools already that do this, better than I could. There
are programming languages which have been around for DECADES which will
do a better job than any macro assembler I could ever build would. They
are tested better and used by way more people, leading to more robust code.

> What's wrong with doing that?

It will recreate something that exists already, only worse. That sounds
like a waste of time.

> Why do you think that code reuse is bad?

Where did I say that? Code reuse is great. Recreating something that
exists already is a horrible idea. So, in fact, I am advocating code
reuse: use the language that ALREAY does everything that you want, only
better tested and standardized instead of inventing your own stuff and
reinventing the wheel.

> Only C++ is right, the rest of the programming world is wrong. I see the
> mentality behind your reasoning.

I see why you think everyone in the group is against you. You're
generalizing, putting words in the mouth's of others and exhibiting
quite paranoid behavior. A very annoying habit, which I guess is the
reason why the regulars avoid you.

Best regards,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$>

On Aug 24, 8:33*pm, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
> On 24.08.2012 20:53, jacob navia wrote:

> >> The question I do have is: why? Why use C and implement most of the
> >> standard STL containers instead of using C++? It seems like the wrong
> >> tool for the job.
>
> > Because I do not want C++!
>
> And nobody forced you to. I merely asked and you respond with such a rant..

he appreciates the useful-ness of standard containers but doesn't want
the rest of the baggage that comes with C++. Idiomatic C++ doesn't
look a lot like C.

<snip>

> > My library is running at almost the same speed, has an easy to use
> > syntax and even more easy to use semantics. You do not get horrible
> > error messages because of some misplaced template bracket.
>
> You're confusing the C++ language with the horrible error messages that
> g++ spouts out when you do something wrong.

which compiler doesn't do this? VisualStudio isn't much better.

<snip>

On 25.08.2012 11:33, Nick Keighley wrote:

>>> Because I do not want C++!
>>
>> And nobody forced you to. I merely asked and you respond with such a rant.
>
> he appreciates the useful-ness of standard containers but doesn't want
> the rest of the baggage that comes with C++. Idiomatic C++ doesn't
> look a lot like C.

You are correct. However, it all depends on the usage. Nobody forces you
to use virtual methods, operator overloading, function polymorphy and
design patterns. They make the language look *very* different to C,
which is probably what you were referring to with "idiomatic C++".

However, one can also use C++ and just take advantage of containers,
leaving the rest. I would argue that this yields understandable syntax
that even a non-C++-programmer can understand easily.

Another thing to argue is that containerfied C doesn't look a lot like
idiomatic C either. Good examples for this are openssl (their use of
"STACK", etc) or the Linux kernel (their special implementation of
lists). Both are not intuitively understood by the programmer and for
both you'll have to read up how EXACTLY they work before being able to
use them.

>>> My library is running at almost the same speed, has an easy to use
>>> syntax and even more easy to use semantics. You do not get horrible
>>> error messages because of some misplaced template bracket.
>>
>> You're confusing the C++ language with the horrible error messages that
>> g++ spouts out when you do something wrong.
>
> which compiler doesn't do this? VisualStudio isn't much better.

CLang does a lot better than g++, actually. But I actually though the
VisualStudio error messages were also better (then again, this was
probably something like 5 years back and my memory might be fading).

Best regards,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$>