Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #23207 > unrolled thread

The C Containers Library

Back to article view | Back to comp.lang.c

Contents

  The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-08 21:53 +0200
    Re: The C Containers Library aftnix <aftnix@gmail.com> - 2012-07-26 13:13 -0700
      Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-26 22:31 +0200
        Re: The C Containers Library lawrence.jones@siemens.com - 2012-07-28 17:46 -0400
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 02:05 +0200
            Re: The C Containers Library lawrence.jones@siemens.com - 2012-07-30 14:48 -0400
            Re: The C Containers Library Phil Bradby <nospam@nospam.com> - 2012-08-01 21:00 +0000
              Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-01 23:18 +0200
              Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-02 00:48 -0700
                Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-08-02 07:00 -0400
                  Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-02 13:27 +0200
                    Re: The C Containers Library Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2012-08-02 20:27 +0000
                  Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-02 05:13 -0700
                  Re: The C Containers Library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-02 14:26 -0700
                    Re: The C Containers Library Kenneth Brody <kenbrody@spamcop.net> - 2012-08-03 10:47 -0400
          Re: The C Containers Library Noob <root@localhost> - 2012-07-29 09:58 +0200
            Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-30 00:31 -0600
              Re: The C Containers Library Noob <root@localhost> - 2012-07-30 09:45 +0200
                Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-30 02:10 -0700
            Re: The C Containers Library lawrence.jones@siemens.com - 2012-07-30 14:54 -0400
      Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-07-26 16:52 -0400
        Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-26 22:56 +0200
          Re: The C Containers Library pacman@kosh.dhis.org (Alan Curry) - 2012-07-26 22:29 +0000
            Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-27 01:50 +0200
              Re: The C Containers Library pacman@kosh.dhis.org (Alan Curry) - 2012-07-27 22:28 +0000
            Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-29 06:31 -0700
              Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-30 00:26 -0600
                Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-30 02:21 -0700
                  Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-02 02:27 -0600
                    Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-08-02 16:43 +0100
                      Re: The C Containers Library Ansel <lateknightdev@gmail.com> - 2012-08-02 17:07 -0700
                        Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-08-03 22:21 +0100
                          Re: The C Containers Library Ansel <lateknightdev@gmail.com> - 2012-08-03 15:43 -0700
                            Re: The C Containers Library Anders Wegge Keller <wegge@wegge.dk> - 2012-08-04 06:32 +0200
                              Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-04 01:52 -0700
                                Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:36 -0600
                                  Re: The C Containers Library Anders Wegge Keller <wegge@wegge.dk> - 2012-08-05 08:36 +0200
                                    Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-05 01:28 -0600
                                      Re: The C Containers Library Anders Wegge Keller <wegge@wegge.dk> - 2012-08-05 11:31 +0200
                                        Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-05 03:48 -0600
              Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-04 03:41 -0700
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-27 01:55 +0200
    Re: The C Containers Library wkaras@yahoo.com - 2012-07-26 13:45 -0700
      Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-26 22:53 +0200
        Re: The C Containers Library wkaras@yahoo.com - 2012-07-26 18:46 -0700
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-27 10:59 +0200
            Re: The C Containers Library gwowen <gwowen@gmail.com> - 2012-07-27 03:39 -0700
            Re: The C Containers Library wkaras@yahoo.com - 2012-07-27 11:34 -0700
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-27 11:04 +0200
            Re: The C Containers Library W Karas <wkaras@yahoo.com> - 2012-07-27 13:10 -0700
    Re: The C Containers Library wkaras@yahoo.com - 2012-07-26 18:54 -0700
      Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-07-27 10:25 -0400
        Re: The C Containers Library wkaras@yahoo.com - 2012-07-27 11:28 -0700
          Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-07-27 15:17 -0400
            Re: The C Containers Library wkaras@yahoo.com - 2012-07-27 13:00 -0700
            Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 02:02 +0200
              Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-28 22:08 -0600
                Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 08:46 +0200
                  Re: The C Containers Library pacman@kosh.dhis.org (Alan Curry) - 2012-07-29 07:43 +0000
                    Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 09:59 +0200
                      Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-29 06:43 -0700
                      Re: The C Containers Library pacman@kosh.dhis.org (Alan Curry) - 2012-07-29 17:27 +0000
                        Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 20:56 +0200
                          Re: The C Containers Library pacman@kosh.dhis.org (Alan Curry) - 2012-07-30 00:07 +0000
                          Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-30 00:07 -0600
                        Re: The C Containers Library Keith Thompson <kst-u@mib.org> - 2012-07-29 11:58 -0700
                          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 22:06 +0200
                        Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 22:23 +0200
                          Re: The C Containers Library Melzzzzz <mel@zzzzz.invalid> - 2012-07-30 00:13 +0200
                            Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-30 00:13 -0600
                              Re: The C Containers Library Keith Thompson <kst-u@mib.org> - 2012-07-30 01:10 -0700
                                Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-30 02:57 -0600
                                  Re: The C Containers Library Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-07-30 15:47 +0000
                                  Re: The C Containers Library Keith Thompson <kst-u@mib.org> - 2012-07-30 13:01 -0700
                                Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-30 04:53 -0700
                                  Re: The C Containers Library Keith Thompson <kst-u@mib.org> - 2012-07-30 13:04 -0700
                                  Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-02 02:11 -0600
                                    Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-08-02 06:52 -0400
                                  Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-08-02 06:46 -0400
                          Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-07-30 00:41 +0100
                            Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-30 09:45 +0200
                    Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-29 23:05 -0600
                  Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-29 22:52 -0600
                    Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-30 04:56 -0700
                      Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-02 02:07 -0600
                    Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-30 17:49 +0200
          Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-07-28 09:17 +0100
            Re: The C Containers Library W Karas <wkaras@yahoo.com> - 2012-07-28 15:17 -0700
              Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-07-29 11:10 +0100
          Re: The C Containers Library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-28 06:51 -0700
            Re: The C Containers Library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-28 17:23 +0100
              Re: The C Containers Library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-30 13:40 -0700
                Re: The C Containers Library Melzzzzz <mel@zzzzz.invalid> - 2012-07-31 00:24 +0200
            Re: The C Containers Library Melzzzzz <mel@zzzzz.invalid> - 2012-07-31 00:05 +0200
            Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-07-31 00:53 +0100
              Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-31 09:24 +0200
              Re: The C Containers Library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-02 14:45 -0700
                Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-08-03 22:31 +0100
                  Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-04 00:01 +0200
                    Re: The C Containers Library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-03 23:45 +0100
                      Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:47 -0600
                    Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:41 -0600
                    Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-08-07 10:24 +0100
                      Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-07 15:30 +0200
                        Re: The C Containers Library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-07 15:35 +0100
                          Re: The C Containers Library Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 12:40 -0700
                            Re: The C Containers Library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-08 00:07 +0100
                              Re: The C Containers Library Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 17:31 -0700
                                Re: The C Containers Library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-08 03:14 +0100
                                  Re: The C Containers Library Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-08 05:22 -0700
                        Re: The C Containers Library Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 12:36 -0700
                      Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-08 02:26 -0700
                        Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-08 17:25 +0200
              Re: The C Containers Library 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-03 16:04 -0700
    Re: The C Containers Library SG <s.gesemann@gmail.com> - 2012-08-04 04:52 -0700
      Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-04 18:42 +0200
        Re: The C Containers Library Ike Naar <ike@faeroes.freeshell.org> - 2012-08-04 19:17 +0000
          Re: The C Containers Library Ike Naar <ike@faeroes.freeshell.org> - 2012-08-04 19:22 +0000
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-04 22:14 +0200
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-05 00:15 +0200
            Re: The C Containers Library Ike Naar <ike@faeroes.freeshell.org> - 2012-08-04 23:13 +0000
              Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:53 -0600

Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7  Next page →

#23929

Le 30/07/12 01:41, Rui Maciel a écrit :
> jacob navia wrote:
>
>> You gdon't glike ghaving gall gyour gvariables gprexfed gwith g?
>
> The pthreads API prefixes all its symbols with pthread_,[1] and that didn't
> stopped it from being made an interantional standard or becoming widely
> adopted.
>


So, did they invent "pthread_int" and "pthread_char" ???

What is funny in the glib is the desire to go to the most ridiculous
extremes.


>
> Rui Maciel
>
> [1] http://pubs.opengroup.org/onlinepubs/007908799/xsh/pthread.h.html
>

[toc] | [prev] | [next] | [standalone]

#23921

"Alan Curry" <pacman@kosh.dhis.org> wrote in message 
news:jv2pic$q6b$1@speranza.aioe.org...
> In article <jv2m8d$ir8$1@speranza.aioe.org>,
> jacob navia  <jacob@jspamsink.org> wrote:
>>Le 29/07/12 06:08, Ansel a écrit :
>>>
>>> I don't think you can go to the conference and *not* compare against STL
>>> even though you have a C-based product. Else you're going to get 
>>> responses
>>> like James gave you about it being kludgy -- you have to address that
>>> ("that" being that C gives one less clay to mold a container library 
>>> with)
>>> and try to alleviate those concerns so that no one even thinks to say 
>>> that.
>>> Your story needs to be not only convincing, but *compelling*.
>>>
> [...]
>>
>>No, I will not do that. The library is not a direct competition for the
>>STL, C++ is the best thing since sliced bread, and people that like
>>that machinery because they have been building it since years would fall
>>on me and my small project like hawks...
>
> Could you do a side-by-side with GLib? It has linked lists, trees,
> hashes... it's not exactly the same thing, but there is significant
> overlap. It's a C library, so it's closer to being your real
> competition.

I don't see it as a competition-type thing at all. Showing cognizance of 
current technology is important (yes outside of one's pet language too). If 
a dead C programmer from the 1970's were resurected and he immediately 
created a container library for C based upon his existing knowledge, would 
you take it seriously as a potential tool? It is A-OK to reject 
alternatives, but it is not OK to not know what the alternatives (such as 
design choices) are.

For example, in this thread there were some posts about "intrusive" an 
"non-intrusive" containers. Well that is one design parameter and the 
perpetrator of the design must tell why he chose one over the other or chose 
to offer both. All the paths that the alternatives give must be examined and 
final choices documented with the reasoning behind the choices made given. 
(I'm not going to rewrite that sentence -- write a parser if it is 
"obtuse" -- lol!).

[toc] | [prev] | [next] | [standalone]

#23920

"jacob navia" <jacob@spamsink.net> wrote in message 
news:jv2m8d$ir8$1@speranza.aioe.org...
> Le 29/07/12 06:08, Ansel a écrit :
>> "jacob navia" <jacob@spamsink.net> wrote in message
>> news:jv1uhs$2oj$1@speranza.aioe.org...
>>> Le 27/07/12 21:17, James Kuyper a écrit :
>>
>>> No, since C and C++ are different languages with different approaches.
>>>
>>> In C++ the solution to everything is to complexify the language without
>>> bounds.
>>>
>>> In C, complex software can be done with simpler tools if you program
>>> carefully. That is why I like C. It allows you to build powerful
>>> software with relatively simple tools. It appeals aesthetically,
>>> I would say.
>>>
>>>> without all of the C++-specific features that STL relies upon,
>>>
>>> Exactly. Without all that huge machinery I arrive at very similar speeds
>>> and features.
>>
>> Please post a side-by-side syntax comparison (STL vs. your CCL) of a few
>> easy container declarations and their usages. A comparison chart of 
>> features
>> comparing the two would be great also. A "strengths and weakeness" list 
>> of
>> both would be more nice info. If you throw-in an overall comparison
>> paragraph or two, you'd have the start to a "white paper" (maybe)! You'd
>> need performance and overhead comparisons then too and an objective
>> comparison of implementation characterisitcs beyond "and I did it without
>> huge machinery".
>>
>> I don't think you can go to the conference and *not* compare against STL
>> even though you have a C-based product. Else you're going to get 
>> responses
>> like James gave you about it being kludgy -- you have to address that
>> ("that" being that C gives one less clay to mold a container library 
>> with)
>> and try to alleviate those concerns so that no one even thinks to say 
>> that.
>> Your story needs to be not only convincing, but *compelling*.
>>
>> Did you start with STL as a design and then subtract until you came up 
>> with
>> something similar that would work in C? If not, that may very well be a 
>> very
>> good exercise.
>>
>>
>
> No, I will not do that. The library is not a direct competition for the
> STL,

I don't see how you could *not* examine STL in great detail in pursuit of a 
container library these days. Aren't you afraid of missing out on things 
learned from the STL implementation? Containers *do* have common ground 
(design and architecture) apart from the languages they are written in, you 
know.

> C++ is the best thing since sliced bread, and people that like
> that machinery because they have been building it since years would fall
> on me and my small project like hawks...

But consider that you wouldn't have to research/analyze/build all the 
containers, just one or two. The rest of the design would pretty much 
follow. But that's just something I would do, and worth about .02 to you 
maybe. Which other container libraries did you examine in detail? Java or C# 
perhaps?

>
> C++ people tend to look upon simpler tools like C with disdain since by 
> their very existence they show that another (simpler) way is possible
> in software development; a way that leads maybe into less complexity
> than what C++ offers now.

Define the criteria of simplicity. CCL is simpler than STL.. how? Simpler to 
implement? Simpler to comprehend and use? How many ancillary techniques does 
it require to implement or use CCL? Will C programmers be able to use it 
immediately or is there a learning curve and some number of  "gotchas"? I 
don't actually want you to answer these questions here -- I want to read the 
white paper!

> But I am not pushing that, and I do not see
> C++ people abandoning C++ to come to C. I see C programmers having
> more fun with C since they do not have to implement a list AGAIN and 
> AGAIN.
>
> I see the library a a develomment of the C language, independent of C++.
>
> Not as a competitor.
>
> And I stay to this:
>
> >> In C, complex software can be done with simple tools if you program
> >> carefully. That is why I like C. It allows you to build powerful
> >> software with relatively simple tools. It appeals aesthetically,
> >> I would say.
>

I still think you should develop a professional-level white paper to show 
how serious you are. Else, how will anyone know that you didn't bury your 
head in the sand to whole realm of container technology, past and present? 
Is there a better model for presentation of such technical matter? Compare 
"white paper" with "brochure". If you are armed with only "brochure", I 
don't see this going anywhere. Do you have a good story to tell the 
committee? What is that saying in academic circles? Oh yeah, "publish or 
perish".

Just another .02 from me. I wish you luck, but I hope you are, or will be, 
well-prepared so you won't need luck. 

[toc] | [prev] | [next] | [standalone]

#23947

On Jul 30, 5:52 am, "Ansel" <tinker...@trytospammenowloser.com> wrote:

<snip>

> I still think you should develop a professional-level white paper to show
> how serious you are.

you seem to have a bit of idee fixe about white papers...


> Else, how will anyone know that you didn't bury your
> head in the sand to whole realm of container technology, past and present?
> Is there a better model for presentation of such technical matter? Compare
> "white paper" with "brochure". If you are armed with only "brochure", I
> don't see this going anywhere. Do you have a good story to tell the
> committee? What is that saying in academic circles? Oh yeah, "publish or
> perish".
>
> Just another .02 from me. I wish you luck, but I hope you are, or will be,
> well-prepared so you won't need luck.

[toc] | [prev] | [next] | [standalone]

#24116

Nick Keighley wrote:
> On Jul 30, 5:52 am, "Ansel" <tinker...@trytospammenowloser.com> wrote:
>
> <snip>
>
>> I still think you should develop a professional-level white paper to
>> show how serious you are.
>
> you seem to have a bit of idee fixe about white papers...

I was trying to bring out the difference between an objective study and a 
brochure. The latter plays to a product's "spiel" and downplays other 
ligitimate concerns about it in attempt to cover up the shortcomings. You 
asked about the Unicode spec -- well I find the book about it more of a 
brochure than an objective analysis of the design choices. Though I find a 
lot of white papers overly detailed, I do find them to be objective -- but 
I'm talking about the scholarly ones.

In the case of JN's container library, I hope he won't just "high-level, 
gloss-over" the design issues and background information (i.e., history of 
and issues in container development), for I believe that will be key in 
having a good story to tell.

>
>
>> Else, how will anyone know that you didn't bury your
>> head in the sand to whole realm of container technology, past and
>> present? Is there a better model for presentation of such technical
>> matter? Compare "white paper" with "brochure". If you are armed with
>> only "brochure", I don't see this going anywhere. Do you have a good
>> story to tell the committee? What is that saying in academic
>> circles? Oh yeah, "publish or perish".
>>
>> Just another .02 from me. I wish you luck, but I hope you are, or
>> will be, well-prepared so you won't need luck. 

[toc] | [prev] | [next] | [standalone]

#23963

Le 30/07/12 06:52, Ansel a écrit :
> Just another .02 from me. I wish you luck, but I hope you are, or will be,
> well-prepared so you won't need luck.

Thanks Ansel. I think most of the questions that you mention are in the
introduction of the documentation. I will expand that further to
explain the design criteria used in the building of the library

Thanks for your input

[toc] | [prev] | [next] | [standalone]

#23840

wkaras@yahoo.com wrote:

> The STL containers have been a big driver of adoption of C++ in place of
> C.  A powerful C container library (which this appears to be) would be
> very important to maintaining C as a viable alternative.  So it should not
> be that big of a challenge.

You are attributing an unwarranted importance to a set of generic containers 
while ignoring every other feature that is provided by C++.  Even if the STL 
wasn't added to the C++ standard, C++'s support for generic programming 
would make it possible that anyone with a basic data structures course (or 
even intro to programming) could easily develop their own generic data 
structures.  In fact, that's something that, in spite of the STL, some 
people still do.  In addition, some popular C++ toolkits still rely on their 
own generic containers instead of the STL.  So, I believe it is safe to say 
that STL's role in decisions regarding migrations from C to C++ is a bit 
overblown.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#23863

On Saturday, July 28, 2012 4:17:02 AM UTC-4, Rui Maciel wrote:
> W Karas wrote:
> 
> 
> 
> > The STL containers have been a big driver of adoption of C++ in place of
> 
> > C.  A powerful C container library (which this appears to be) would be
> 
> > very important to maintaining C as a viable alternative.  So it should not
> 
> > be that big of a challenge.
> 
> 
> 
> You are attributing an unwarranted importance to a set of generic containers 
> 
> while ignoring every other feature that is provided by C++.  Even if the STL 
> 
> wasn't added to the C++ standard, C++'s support for generic programming 
> 
> would make it possible that anyone with a basic data structures course (or 
> 
> even intro to programming) could easily develop their own generic data 
> 
> structures.  In fact, that's something that, in spite of the STL, some 
> 
> people still do.  In addition, some popular C++ toolkits still rely on their 
> 
> own generic containers instead of the STL.  So, I believe it is safe to say 
> 
> that STL's role in decisions regarding migrations from C to C++ is a bit 
> 
> overblown.
> 
> 
> 
> 
> 
> Rui Maciel

Hmm, seems your underlying principle here is that a library that can be written in portable Standard C should not be a Standard library.  I think this would make some sense if standard compliance were a simple yes/no thing, as this would be a barrier for the availability of C compilers on new architectures.  But a compiler provider can simply market their compiler as "C Standard-compliant, except for xyz".

Or perhaps you are saying that the error-prone lack of type-checking in a C type-independent container library makes such a beast too risky to use.  While there is validity to that point of view, the beast has already been let out of the cage by the presence of void pointers in the language.

Also note that your argument would imply that qsort() should not be a Standard library function.

[toc] | [prev] | [next] | [standalone]

#23883

W Karas wrote:

> Hmm, seems your underlying principle here is that a library that can be
> written in portable Standard C should not be a Standard library.  
<snip/>

No, it isn't.  What I pointed out was that other features weigh more on the 
decision to migrate to C++ than the STL, which might be completely 
irrelevant in this regard.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#23846

בתאריך יום שישי, 27 ביולי 2012 19:28:19 UTC+1, מאת W Karas:
> On Friday, July 27, 2012 10:25:57 AM UTC-4, James Kuyper wrote:
> 
> The STL containers have been a big driver of adoption of C++ in place of C.  A powerful C container library (which this appears to be) would be very important to maintaining C as a viable alternative.  So it should not be that big of a challenge.
>
When STL first came out I thought that maybe it was the end of C. The STL containers did provide runtime performance and encapsulation that you had to handtune C to match.
But actually the result was the reverse. I think it was because STL made the syntax for just declaring an array and stepping through it too cumbersome. That was the point at whcih people stopped switching from C to C++, and started moving from C++ to other languages. C++ had a huge user base behind it and is still a popular language. But ever since STL it's been in decline.
I'm current programming under Qt. However I've deliberately written all the non-GUI elements of the program in C. Even the C++ elements aren't really C++, because Qt preprocesses them to make the signals and slots mechanism work. C++ doesn't provide the flexiblity to do this natively.

[toc] | [prev] | [next] | [standalone]

#23852

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> בתאריך יום שישי, 27 ביולי 2012 19:28:19 UTC+1, מאת W Karas:
>> On Friday, July 27, 2012 10:25:57 AM UTC-4, James Kuyper wrote:
>> 
>> The STL containers have been a big driver of adoption of C++ in place
>> of C.  A powerful C container library (which this appears to be)
>> would be very important to maintaining C as a viable alternative.  So
>> it should not be that big of a challenge.
>>
> When STL first came out I thought that maybe it was the end of C. The
> STL containers did provide runtime performance and encapsulation that
> you had to handtune C to match.

> But actually the result was the reverse. I think it was because STL
> made the syntax for just declaring an array and stepping through it
> too cumbersome.

What's so cumbersome?  For example:

   vector<int> ia = {1, 2, 3, 4, 5, 6, 7, 8};
   for (int i = 0; i < ia.size(); i++)
      cout << ia[i] << "\n";

The C version is *more* cumbersome in my option.  If you code the size
of the array separately you can avoid the sizeof ia / sizeof *is idiom,
but that make the code more fragile.

I deliberately used a Cish loop and access method rather the C++'s
neater "for each" construct:

  for (int e: ia)
      cout << e << "\n";

to make the comparison clearer.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#23997

בתאריך יום שבת, 28 ביולי 2012 17:23:47 UTC+1, מאת Ben Bacarisse:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > But actually the result was the reverse. I think it was because STL
> > made the syntax for just declaring an array and stepping through it
> > too cumbersome.
> 
>  
> What's so cumbersome?  For example:
> 
> 
>    vector<int> ia = {1, 2, 3, 4, 5, 6, 7, 8};
> 
>    for (int i = 0; i < ia.size(); i++)
> 
>       cout << ia[i] << "\n";
> 
> 
> 
> The C version is *more* cumbersome in my option.
>
Toy examples never show up C++'s problems. Language designers aren't totally
stupid, and everything in C++ has some sort of point. However what you often 
find is that it only works if all the surrounding code is C primitives.

In fact the code will end up like this


template <class numeric, class output>
void printintegers(output &out)
{
   vector<numeric> ia;
   for(int i = 1; i < 9; i++)
      ia.pushback( numeric(i) );
   for(int i =0; i< ia.size(); i++)
     out << ia[i]; 
}

Preconditions: output must be a writable class which overloads the << operator
 with numericals castable to a string using the (String) operator. numeric must
 be a type which accepts an integer as a constructor.

You need code to dance around the type system and to carefully document 
everything, because it's just possible to get every numeric to work with
every writabble stream, but only just.

[toc] | [prev] | [next] | [standalone]

#24004

On Mon, 30 Jul 2012 13:40:04 -0700 (PDT)
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

> בתאריך יום שבת, 28 ביולי 2012 17:23:47 UTC+1, מאת Ben Bacarisse:
> > Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >
> > > But actually the result was the reverse. I think it was because
> > > STL made the syntax for just declaring an array and stepping
> > > through it too cumbersome.
> > 
> >  
> > What's so cumbersome?  For example:
> > 
> > 
> >    vector<int> ia = {1, 2, 3, 4, 5, 6, 7, 8};
> > 
> >    for (int i = 0; i < ia.size(); i++)
> > 
> >       cout << ia[i] << "\n";
> > 
> > 
> > 
> > The C version is *more* cumbersome in my option.
> >
> Toy examples never show up C++'s problems. Language designers aren't
> totally stupid, and everything in C++ has some sort of point. However
> what you often find is that it only works if all the surrounding code
> is C primitives.
> 
> In fact the code will end up like this
> 
> 
> template <class numeric, class output>
> void printintegers(output &out)
> {
>    vector<numeric> ia;
>    for(int i = 1; i < 9; i++)
>       ia.pushback( numeric(i) );
>    for(int i =0; i< ia.size(); i++)
>      out << ia[i]; 
> }
> 

Following is compilable, working code:

#include <iostream>
#include <vector>
#include <algorithm>

template <class numeric>
void printintegers(std::ostream &out)
{
   std::vector<numeric> ia = {1,2,3,4,5,6,7,8};
   for(auto i : ia)
     out << i <<" "; 
  out<<'\n';
   std::for_each(ia.begin(),ia.end(),[&out](numeric& n){out<<n<<" ";});
  out<<'\n';
}

struct Int{
 int i;
 Int(int i):i(i){}
 friend std::ostream& operator<<(std::ostream& os, Int& i)
 {
  os << i.i;
  return os;
 }
};

int main()
{
  printintegers<Int>(std::cout);
}


> Preconditions: output must be a writable class which overloads the <<
> operator with numericals castable to a string using the (String)
> operator. numeric must be a type which accepts an integer as a
> constructor.

Done.

> 
> You need code to dance around the type system and to carefully
> document everything, because it's just possible to get every numeric
> to work with every writabble stream, but only just.

Why? We have ostream class for that?


-- 
drwx------ 2 bmaxa bmaxa 4096 Jul 31 00:05 .

[toc] | [prev] | [next] | [standalone]

#24001

On Sat, 28 Jul 2012 06:51:24 -0700 (PDT)
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:> 

> When STL first came out I thought that maybe it was the end of C. The
> STL containers did provide runtime performance and encapsulation that
> you had to handtune C to match. But actually the result was the
> reverse. I think it was because STL made the syntax for just
> declaring an array and stepping through it too cumbersome. That was
> the point at whcih people stopped switching from C to C++, and
> started moving from C++ to other languages.

Well try Java containers than ;) that is awful IMO...
STL is not that cumbersome. Do you mind to provide some
example?

 C++ had a huge user base
> behind it and is still a popular language. But ever since STL it's
> been in decline. I'm current programming under Qt. However I've
> deliberately written all the non-GUI elements of the program in C.

Heh. Here comes logical question, why not Gtk since it is C?
Qt is great for C++, but I prefer Gtk somehow if I could
choose for new project, even Im C++ programmer mainly.

> Even the C++ elements aren't really C++, because Qt preprocesses them
> to make the signals and slots mechanism work. C++ doesn't provide the
> flexiblity to do this natively.

Of course does it provide. gtkmm (C++ wrapper around Gtk) uses libsigc++
http://libsigc.sourceforge.net/
When I wrote some application for Qt , first thing I did was to
replace Qt's signal slot with my own lib and that was around 2000.

-- 
drwxr-xr-x 2 bmaxa bmaxa 4096 Jul 30 18:46 .

[toc] | [prev] | [next] | [standalone]

#24007

Malcolm McLean wrote:

> When STL first came out I thought that maybe it was the end of C. The STL
> containers did provide runtime performance and encapsulation that you had
> to handtune C to match. But actually the result was the reverse. I think
> it was because STL made the syntax for just declaring an array and
> stepping through it too cumbersome. 

Could you provide an example where you demonstrate how declaring an array 
and iterating through it is "too cumbersome"?


> That was the point at whcih people
> stopped switching from C to C++, and started moving from C++ to other
> languages. 

Is it a personal opinion or is there any basis for that assertion?


> C++ had a huge user base behind it and is still a popular
> language. But ever since STL it's been in decline. 

The only time I ever heard of any real world complain regarding the STL was 
from people involved in game programming, whose complaints were somewhere 
between worries that some STL implementations might have efficiency issues 
and ignorance on the programmer's behalf.[1]  Other than this, I believe you 
will be hard-pressed to find a C++ programmer who doesn't employ the STl in 
his code.


> I'm current programming
> under Qt. However I've deliberately written all the non-GUI elements of
> the program in C. Even the C++ elements aren't really C++, because Qt
> preprocesses them to make the signals and slots mechanism work. C++
> doesn't provide the flexiblity to do this natively.

Qt's signals and slots mechanismo is a particular implementation of the 
observer pattern, and one which is notoriously inefficient and with a 
particular ability of sweeping serious problems under the proverbial rug. 

The only reason Qt relies on preprocessing tricks is basically for syntactic 
sugar purposes,[2] not any lack of flexibility C++ might have.  Meanwhile, 
there are plenty of stand-alone implementations of the observer pattern 
floating around that manage to do a better job, such as libsigc++.[3]  So, I 
believe it is safe to say that C++ does provide more than enough flexibility 
to handle signals and slots natively.  After all, if it didn't then Qt 
wouldn't support them.


Rui Maciel

[1] http://software.intel.com/en-us/articles/extending-stl-for-games/
[2] http://doc.qt.nokia.com/4.7-snapshot/moc.html
[3] http://libsigc.sourceforge.net/

[toc] | [prev] | [next] | [standalone]

#24015

Le 31/07/12 01:53, Rui Maciel a écrit :
>
> Qt's signals and slots mechanismo is a particular implementation of the
> observer pattern, and one which is notoriously inefficient and with a
> particular ability of sweeping serious problems under the proverbial rug.
>

The CCL proposes also an observer interface. I have relied on the design
of the observer interface from Apple's API.

> The only reason Qt relies on preprocessing tricks is basically for syntactic
> sugar purposes,[2] not any lack of flexibility C++ might have.

Actually, the STL doesn't offer observer interfaces. I think that is not 
  a good idea.

[toc] | [prev] | [next] | [standalone]

#24153

בתאריך יום שלישי, 31 ביולי 2012 00:53:41 UTC+1, מאת Rui Maciel:
> Malcolm McLean wrote:
> 
> > That [STL] was the point at whcih people
> > stopped switching from C to C++, and started moving from C++ to other 
> > languages. 
> 
> Is it a personal opinion or is there any basis for that assertion?
> 
C++ is in decline. There are various metrics you can use to measure a language's popularity. They show that C++ has been in decline since about 2003. Microsoft did ship an STL implmentation with Visual Studio 6.0 in 1998, but it was poor quality and wasn't used much. 2003 more or less marks the start of the widespread use of STL when the .NET Visual Studios came out. So the widespread adotion of STL marks the beginning of the decline. Post hoc, ergo propter hoc.

[toc] | [prev] | [next] | [standalone]

#24176

Malcolm McLean wrote:

> C++ is in decline. There are various metrics you can use to measure a
> language's popularity. They show that C++ has been in decline since about
> 2003. 

I've noticed that you avoided providing any example where you try to show 
that declaring an array and iterating through it is "too cumbersome".

Regarding your claim, can you point at least one of those metrics where 
you've based your assertion?


<snip/>
> 2003 more or less
> marks the start of the widespread use of STL when the .NET Visual Studios
> came out. So the widespread adotion of STL marks the beginning of the
> decline. Post hoc, ergo propter hoc.

Again, where do you base your assertion that C++ is in decline since 2003?  
Do you actually base your assertion on any tangible evidence or did you made 
that up?


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#24179

Le 03/08/12 23:31, Rui Maciel a écrit :
>
> Again, where do you base your assertion that C++ is in decline since 2003?
> Do you actually base your assertion on any tangible evidence or did you made
> that up?
>

I would not say that c++ is in "the decline" but there are some
developments that are noteworthy.

1) After several YEARS of work, the creator of the language declares
that he is unable to add a new feature to the language.

This means that C++ has become such a complex software construct that
it is impossible for its creator (Mr Bjarne Stroustrup) to fully
understand the consequences of a language enhancement. This shows
us the level of complexity reached by C++.

2) Undeterred by this fact, the new standard piles up yet another thick 
software layer into the already brittle edifice. Lambdas, and other
esoteric constructs add more complexity as if increasing the
number of language constructs and their unforeseen interactions
was a good thing!

3) It is more or less impossible to parse C++ without the help
of a machine. For instance the specifications of the operator
overloading part goes into pages and pages of complex specifications
(if I remember correctly there were more than 5 full pages) and at the
end you had to do a topological sort of the classes defined at the
point of call to be able to see which overloaded operator would spring
into action at a given point.

Obviously the consequence is that instead of trying to understand by
reading, you have to follow the debugger and bring the program to the
point of the overloaded call to be sure it goes to where you think it
is going.

And you can be sure that somebody else, unaware of all this adds an
overloaded call, introducing a bug in a completely unrelated part of the 
program.

Can you do that test for all overloaded calls you write?
Do you have the time?
Can you repeat that test each time somebody introduces a new overloaded
version of that function within your scope?

No. Then you just write it and suppose it is OK. And in most cases it
is. But then... well then you call the maintenance people that are used
to that kind of nightmares. At last, they are paid for doing that isn't
it?


4) All C++ programmers (besides Bjarne) use a portion of the huge
language since it is not possible to fit every detail of that into a
human brain.

This means that only the overlapping portions of the language can be
understood by all of them, and a proliferation of "C++ subsets" starts
that makes communication between programmers more difficult.

In all my life as a programmer I have tried to keep things SIMPLE.
That is why I like (and use) the C language. C is a language that
can be understood in full by a person.

Yes, I know. You will tell me that the complexity is in the language
instead of in every program that uses the language and that a complex
language simplifies programs. Yes, I do KNOW that.

But there is a point of diminishing returns where you add complexity to
the language trying to be all things to everyone and you end up with
being a complexity monster for everyone.

I know that you like C++ Rui, and I hope you do not feel personally
attacked since I am talking about a computer (machine) language.

We tend to get attached to languages because of other philosophical
reasons. For instance the fact that I like small and simple computer
languages comes from my beliefs that "small is beautiful" from my youth,
and many other things that are more or less completely irrelevant here.

Let's try to put all that baggage aside and discuss in a rational
manner.

jacob

[toc] | [prev] | [next] | [standalone]

#24181

jacob navia <jacob@spamsink.net> writes:
<snip>
> This means that C++ has become such a complex software construct that
> it is impossible for its creator (Mr Bjarne Stroustrup) to fully
> understand the consequences of a language enhancement.

In informal contexts like this I'd say it's perfectly acceptable to say
"Bjarne Stroustrup", but if you're going to give him a title, give him
the right one.  He has a PhD from Cambridge, and holds the College of
Engineering Chair in Computer Science at Texas A&M University.  Using
"Mr" could be misconstrued.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7  Next page →

Back to top | Article view | comp.lang.c

csiph-web