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

Groups > comp.unix.programmer > #1119 > unrolled thread

find library in C

Back to article view | Back to comp.unix.programmer

Contents

  find library in C ZarkXe <zarkxe@gmail.com> - 2011-08-11 22:35 +0200
    Re: find library in C "Heinrich Wolf" <invalid@invalid.invalid> - 2011-08-11 23:16 +0200
      Re: find library in C Rui Maciel <rui.maciel@gmail.com> - 2011-08-12 15:50 +0100
        Re: find library in C Rui Maciel <rui.maciel@gmail.com> - 2011-08-12 16:20 +0100
    Re: find library in C Rui Maciel <rui.maciel@gmail.com> - 2011-08-12 15:29 +0100
      Re: find library in C "Heinrich Wolf" <invalid@invalid.invalid> - 2011-08-12 17:03 +0200
        Re: find library in C "Heinrich Wolf" <invalid@invalid.invalid> - 2011-08-12 17:09 +0200
        Re: find library in C Rui Maciel <rui.maciel@gmail.com> - 2011-08-12 16:31 +0100
      Re: find library in C Nicolas George <nicolas$george@salle-s.org> - 2011-08-12 16:24 +0000
        Re: find library in C Rui Maciel <rui.maciel@gmail.com> - 2011-08-12 18:58 +0100
          Re: find library in C Nicolas George <nicolas$george@salle-s.org> - 2011-08-12 19:16 +0000
            Re: find library in C Rui Maciel <rui.maciel@gmail.com> - 2011-08-13 13:42 +0100
              Re: find library in C Nicolas George <nicolas$george@salle-s.org> - 2011-08-13 15:06 +0000
          Re: find library in C Ian Collins <ian-news@hotmail.com> - 2011-08-13 11:40 +1200
            Re: find library in C Rui Maciel <rui.maciel@gmail.com> - 2011-08-13 11:08 +0100
        Re: find library in C William Ahern <william@wilbur.25thandClement.com> - 2011-08-12 12:58 -0700
          Re: find library in C Nicolas George <nicolas$george@salle-s.org> - 2011-08-12 20:31 +0000
            Re: find library in C William Ahern <william@wilbur.25thandClement.com> - 2011-08-12 14:47 -0700
            Re: find library in C Rui Maciel <rui.maciel@gmail.com> - 2011-08-13 14:30 +0100
              Re: find library in C William Ahern <william@wilbur.25thandClement.com> - 2011-08-13 18:54 -0700
      Re: find library in C Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-12 18:55 +0100
        Re: find library in C Rui Maciel <rui.maciel@gmail.com> - 2011-08-12 19:37 +0100
          Re: find library in C Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-12 20:21 +0100
            Re: find library in C Rui Maciel <rui.maciel@gmail.com> - 2011-08-13 10:23 +0100
              Re: find library in C Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-13 14:53 +0100
    Re: find library in C "Heinrich Wolf" <invalid@invalid.invalid> - 2011-08-15 13:58 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1130

Rui Maciel <rui.maciel@gmail.com> writes:
> ZarkXe wrote:
>> Hello all,
>> 
>> I find a library or function in C for create/read/write/modify files
>> configuration (*.conf or *.ini)/
>
> This sort of library isn't very common because it's functionality is trivial 
> to implement, and it tends to be tied to what the developer intends to 
> achieve.  In C, at least when compared to C++, I believe the need to develop 
> your own custom library is even more pressing, as the language doesn't 
> provide a set of standard data structures nor supports generic
> programming.

On UNIX(*) (as opposed to WinDOS), the traditional way to get a
parser is not 'write one in C++' but 'Yacc'.

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

#1132

Rainer Weikusat wrote:

> On UNIX(*) (as opposed to WinDOS), the traditional way to get a
> parser is not 'write one in C++' but 'Yacc'.

The term "traditional way" isn't a synonym for "appropriate solution".  In 
some cases, writing your own parser is simpler than relying on a parser 
generator such as yacc, not to mention that it lets you develop approriate 
solutions to the problems which you need to tackle.  

As a side note, GNU bison also generates C++ parsers[1], which contradicts 
your statement.


Rui Maciel

[1] http://www.gnu.org/software/bison/manual/bison.html#C_002b_002b-Parsers

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

#1134

Rui Maciel <rui.maciel@gmail.com> writes:
> Rainer Weikusat wrote:
>
>> On UNIX(*) (as opposed to WinDOS), the traditional way to get a
>> parser is not 'write one in C++' but 'Yacc'.
>
> The term "traditional way" isn't a synonym for "appropriate
> solution".

Considering that you asserted that[*]

	In C, at least when compared to C++, I believe the need to
	develop your own custom library is even more pressing, as the
	language doesn't provide a set of standard data structures nor
	supports generic programming.

stating "No, you aren't required to implement your own parser when
using C because of what you consider to be shortcomings of this
language, but can use existing tools to have one generated" seems a
sensible reply to that. This is also nicely demonstrated by the fact
that you now, instead of claiming "there ain't no tools" switched to
"well, at least, there ain't no tools I believe C programmers should
use", a considerably weaker statement than the original one.

[...]

> As a side note, GNU bison also generates C++ parsers[1], which contradicts 
> your statement.

'Bison can generate C++ parses' cannot possibly contradict 'Yacc can
be used to generate C parsers and it is actually pretty common to use
it for that' because these two statements are completely independent
of each other.

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

#1140

Rainer Weikusat wrote:

> Rui Maciel <rui.maciel@gmail.com> writes:
>> Rainer Weikusat wrote:
>>
>>> On UNIX(*) (as opposed to WinDOS), the traditional way to get a
>>> parser is not 'write one in C++' but 'Yacc'.
>>
>> The term "traditional way" isn't a synonym for "appropriate
>> solution".
> 
> Considering that you asserted that[*]
> 
> In C, at least when compared to C++, I believe the need to
> develop your own custom library is even more pressing, as the
> language doesn't provide a set of standard data structures nor
> supports generic programming.
> 
> stating "No, you aren't required to implement your own parser when
> using C because of what you consider to be shortcomings of this
> language, but can use existing tools to have one generated" seems a
> sensible reply to that. This is also nicely demonstrated by the fact
> that you now, instead of claiming "there ain't no tools" switched to
> "well, at least, there ain't no tools I believe C programmers should
> use", a considerably weaker statement than the original one.

Your comment doesn't make sense, because you either failed to understand 
what I wrote or you don't understand what yacc is and what it does.  For 
example, yacc is a parser generator.  This means that it's purpose is to 
help programmers develop their own parsers.  So, by using yacc, the 
developer doesn't need to explicitly worry about parser tables and state 
machines when implementing a parser for his languages; he just specifies the 
production for his languages, automatically generate the source code and 
goes on with his life.  Yet, although he avoids the need to implement every 
small detail in a parser, when someone uses yacc to write their own custom 
parser they are still developing their own custom parser.  This is in 
contrast with relying on a third party library which implements a generic, 
one size fits all parser.  

This means that your comment is a blatant contradiction. You start off by 
claiming that "No, you aren't required to implement your own parser when 
using C" but then proceed to explain how you can always implement your own 
parser when using C".  Notice the contradiction?

Following this, you wrongly implied that somehow I believe C has shorcomings 
and that it somehow affects the ability to successfully employ the language 
in some areas.  This is false and absurd.  I'v referred a couple of details 
which could simplify the development of a generic parser, whose absense can 
render them, at least to some people, unnacceptable as a general, one size 
fits all solution.  After all, it is always a PitA to wrestle with a bunch 
of custom, undocumented data structures which may be packed with small 
obscure yet important aspects that no one really knows what to expect from 
them, let alone sets of function pointers and magic casts between unknown 
data types.  Therefore, this tends to make the idea of developing a custom 
parser for a custom language a whole lot more attractive and manageable. 



> [...]
> 
>> As a side note, GNU bison also generates C++ parsers[1], which
>> contradicts your statement.
> 
> 'Bison can generate C++ parses' cannot possibly contradict 'Yacc can
> be used to generate C parsers and it is actually pretty common to use
> it for that' because these two statements are completely independent
> of each other.

That's good to hear.  Yet, that wasn't what you claimed, and therefore not 
what I referred to.  This is exactly what you claimed:

<quote>
On UNIX(*) (as opposed to WinDOS), the traditional way to get a
parser is not 'write one in C++' but 'Yacc'.
</quote>

It is absurd to oppose "write one in C++" and "yacc" because yacc is an 
automatic parser generator (that is, it converts a set of YACC instructions 
into source code files) that also generates parsers in C++.  To put it even 
more clearly, you can "write one in C++" by using yacc.  And this, as you 
can understand, makes it obvious that trying to contrast "yacc" with "write 
one in C++" is absurd and a contradiction.  There is no "either/or" in this 
case.


Rui Maciel

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

#1144

Rui Maciel <rui.maciel@gmail.com> writes:
> Rainer Weikusat wrote:
>
>> Rui Maciel <rui.maciel@gmail.com> writes:
>>> Rainer Weikusat wrote:
>>>
>>>> On UNIX(*) (as opposed to WinDOS), the traditional way to get a
>>>> parser is not 'write one in C++' but 'Yacc'.
>>>
>>> The term "traditional way" isn't a synonym for "appropriate
>>> solution".
>> 
>> Considering that you asserted that[*]
>> 
>> In C, at least when compared to C++, I believe the need to
>> develop your own custom library is even more pressing, as the
>> language doesn't provide a set of standard data structures nor
>> supports generic programming.
>> 
>> stating "No, you aren't required to implement your own parser when
>> using C because of what you consider to be shortcomings of this
>> language, but can use existing tools to have one generated" seems a
>> sensible reply to that. This is also nicely demonstrated by the fact
>> that you now, instead of claiming "there ain't no tools" switched to
>> "well, at least, there ain't no tools I believe C programmers should
>> use", a considerably weaker statement than the original one.
>
> Your comment doesn't make sense, because you either failed to understand 
> what I wrote or you don't understand what yacc is and what it does.

Your comment doesn't make sense because you can only make these type
of statements about me confidently when you believe to be in posession
of telepathic powers. And you're not. Abgesehen davon steht mir im
Moment nicht der Sinn nach spitzfindigen semantischen Verdrehungen.

"Guten Tag".

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

#1149

In 2004 I downloaded

http://sourceforge.net/projects/inifile/

http://prdownloads.sourceforge.net/inifile/inifile.zip?use_mirror=heanet

and used it on Linux

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.unix.programmer

csiph-web