The lcc-win string library

[jacob navia]

Within the context of the lcc-win experimental compiler
a complete str_ing library is available that uses operator
overloading and overloaded functions to present a new type
of string library in C, that

o features counted strings, that eliminates buffer overflows
o It has a syntax very similar to the old functions
(Strcat vs strcat, etc)
o It could be faster for some operations like (precisely)
Strcat since there is no need to search for the terminating
zero.

The source code for the whole library can be found in the
normal distribution of lcc-win.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Antoninus Twink]

Re: The lcc-win string library

On 3 Nov 2008 at 16:09, jacob navia wrote:

The source code for the whole library can be found in the normal
distribution of lcc-win.

Interesting!

Is it released under the same license as the lcc-win compiler, or
something more permissive?

[Stephen Sprunk]

Re: The lcc-win string library

jacob navia wrote:

Within the context of the lcc-win experimental compiler
a complete str_ing library is available that uses operator
overloading and overloaded functions to present a new type
of string library in C, that

C does not have operator or function overloading. Quit spamming
comp.lang.c with advertisements for compiler features that are not C.

IMHO, you would be better served simply adding the few remaining
features that are required to make lcc-win32 a C++ compiler, rather than
trying to convince people that your extensions are or should be part of
C. There is a reason these features were _not_ backported from C++ to C
as many other "improvemen ts" have been.

S

[jacob navia]

Re: The lcc-win string library

Antoninus Twink wrote:

On 3 Nov 2008 at 16:09, jacob navia wrote:

>The source code for the whole library can be found in the normal
>distribution of lcc-win.

>
Interesting!
>
Is it released under the same license as the lcc-win compiler, or
something more permissive?
>

It is public domain, no strings attached to the string library :-)

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Re: The lcc-win string library

Stephen Sprunk wrote:

jacob navia wrote:

>Within the context of the lcc-win experimental compiler
>a complete str_ing library is available that uses operator
>overloading and overloaded functions to present a new type
>of string library in C, that

>
C does not have operator or function overloading. Quit spamming
comp.lang.c with advertisements for compiler features that are not C.
>
IMHO, you would be better served simply adding the few remaining
features that are required to make lcc-win32 a C++ compiler, rather than
trying to convince people that your extensions are or should be part of
C. There is a reason these features were _not_ backported from C++ to C
as many other "improvemen ts" have been.
>
S

There is a central difference.

C is not object oriented, and the complexity and bloat that are
associated with that make it a much simpler language.

I think C is a great language, that can evolve as all languages evolve
without becoming something else.



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Keith Thompson]

Re: The lcc-win string library

jacob navia <jacob@nospam.c omwrites:

Antoninus Twink wrote:

>On 3 Nov 2008 at 16:09, jacob navia wrote:

>>The source code for the whole library can be found in the normal
>>distributio n of lcc-win.

>Interesting!
>Is it released under the same license as the lcc-win compiler, or
>something more permissive?

>
It is public domain, no strings attached to the string library :-)

Can it be used with any compiler other than lcc-win? If not, then,
though I applaud your decision to place it in the public domain, it
seems to me that, for most purposes, it's *effectively* under the same
restrictions as lcc-win.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[lawrence.jones@siemens.com]

Re: The lcc-win string library

jacob navia <jacob@nospam.c omwrote:

>
o It could be faster for some operations like (precisely)
Strcat since there is no need to search for the terminating
zero.

I would expect Strlen to be quite a bit faster, too. :-)

Does it include I/O functions like sprintf, too?
--
Larry Jones

Whatever it is, it's driving me crazy! -- Calvin

[CBFalconer]

Re: The lcc-win string library

Keith Thompson wrote:

jacob navia <jacob@nospam.c omwrites:

>Antoninus Twink wrote:

>>jacob navia wrote:
>>>
>>>The source code for the whole library can be found in the normal
>>>distributi on of lcc-win.
>>>
>>Interesting !
>>Is it released under the same license as the lcc-win compiler, or
>>something more permissive?

>>
>It is public domain, no strings attached to the string library :-)

>
Can it be used with any compiler other than lcc-win? If not, then,
though I applaud your decision to place it in the public domain, it
seems to me that, for most purposes, it's *effectively* under the
same restrictions as lcc-win.

I think you are over-criticizing here. If not compatible with
other systems, the PD source makes revision for compatibility quite
feasible. And Jacob has made the right overall classification with
"context of the lcc-win experimental compiler"

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[CBFalconer]

Re: The lcc-win string library

Stephen Sprunk wrote:

jacob navia wrote:
>

>Within the context of the lcc-win experimental compiler
>a complete str_ing library is available that uses operator
>overloading and overloaded functions to present a new type
>of string library in C, that

>
C does not have operator or function overloading. Quit spamming
comp.lang.c with advertisements for compiler features that are
not C.
>
IMHO, you would be better served simply adding the few remaining
features that are required to make lcc-win32 a C++ compiler,
rather than trying to convince people that your extensions are or
should be part of C. There is a reason these features were _not_
backported from C++ to C as many other "improvemen ts" have been.

Note the "context of the lcc-win experimental compiler" phrase,
which adequately describes it. It is admittedly not a C compiler,
but can probably be revised into one at some future time. I would
really settle for this adequate description, rather than beating on
Jacob unnecessarily.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[jacob navia]

Re: The lcc-win string library

lawrence.jones@ siemens.com wrote:

jacob navia <jacob@nospam.c omwrote:

>o It could be faster for some operations like (precisely)
> Strcat since there is no need to search for the terminating
> zero.

>
I would expect Strlen to be quite a bit faster, too. :-)
>
Does it include I/O functions like sprintf, too?

Well, not now. You have cast a String into a char *.

The overloaded cast operator will give back a pointer
to the actual contents of a String as a char *.

This is suboptimal, and I will hack the printf functions
later to accept some new marker for those strings, like
"%{S}"



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Keith Thompson]

Re: The lcc-win string library

CBFalconer <cbfalconer@yah oo.comwrites:

Keith Thompson wrote:

>jacob navia <jacob@nospam.c omwrites:

>>Antoninus Twink wrote:
>>>jacob navia wrote:
>>>>
>>>>The source code for the whole library can be found in the normal
>>>>distributio n of lcc-win.
>>>>
>>>Interestin g!
>>>Is it released under the same license as the lcc-win compiler, or
>>>something more permissive?
>>>
>>It is public domain, no strings attached to the string library :-)

>>
>Can it be used with any compiler other than lcc-win? If not, then,
>though I applaud your decision to place it in the public domain, it
>seems to me that, for most purposes, it's *effectively* under the
>same restrictions as lcc-win.

>
I think you are over-criticizing here. If not compatible with
other systems, the PD source makes revision for compatibility quite
feasible. And Jacob has made the right overall classification with
"context of the lcc-win experimental compiler"

Note the phrase "for most purposes". In any case, my comments were
meant more as an observation than a criticism; he was under no
obligation to place the code in the public domain in the first place,
and his decision to do so was generous.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Chris M. Thomasson]

Re: The lcc-win string library


"jacob navia" <jacob@nospam.c omwrote in message
news:genmpb$bo7 $2@aioe.org...

Stephen Sprunk wrote:

>jacob navia wrote:

>>Within the context of the lcc-win experimental compiler
>>a complete str_ing library is available that uses operator
>>overloading and overloaded functions to present a new type
>>of string library in C, that

>>
>C does not have operator or function overloading. Quit spamming
>comp.lang.c with advertisements for compiler features that are not C.
>>
>IMHO, you would be better served simply adding the few remaining features
>that are required to make lcc-win32 a C++ compiler, rather than trying to
>convince people that your extensions are or should be part of C. There
>is a reason these features were _not_ backported from C++ to C as many
>other "improvemen ts" have been.
>>
>S

>
There is a central difference.
>
C is not object oriented, and the complexity and bloat that are
associated with that make it a much simpler language.
>
I think C is a great language, that can evolve as all languages evolve
without becoming something else.

If one wants to create some OO API's in C, well, they most certainly can;
here is a simple example:

http://groups.google.com/group/comp.lang.c++/msg/6002fd4047cbbe1c

That is a very simple example of _minimalist_ implementation of abstract
interfaces in C. AFAICT, its pretty clean as well. I find this technique
works very well for plug-in frameworks... IMHO, C is extremely flexible
as-is.

[s0suk3@gmail.com]

Re: The lcc-win string library

On Nov 3, 6:07 pm, jacob navia <jacob@nospam.c omwrote:

lawrence.jones@ siemens.com wrote:

jacob navia <jacob@nospam.c omwrote:

o It could be faster for some operations like (precisely)
   Strcat since there is no need to search for the terminating
   zero.

>

I would expect Strlen to be quite a bit faster, too.  :-)

>

Does it include I/O functions like sprintf, too?

>
Well, not now. You have cast a String into a char *.
>
The overloaded cast operator will give back a pointer
to the actual contents of a String as a char *.
>
This is suboptimal, and I will hack the printf functions
later to accept some new marker for those strings, like
"%{S}"

I think that having an easy way to convert from the string type to a
null-terminated C-style string should be enough (and the cast fulfills
this purpose).

Maybe what Lawrence meant was if there were sprintf-like functions
that wrote to a StringA or a StringW, which eliminates the problem of
overflow (with, e.g., sprintf()) or truncation (with, e.g.,
snprintf()). For example, in a simple string library I once wrote,
there was a function like:

int StringAssignFor mat(String str, const char *format, ...);

The function automatically allocated the space needed for the result
and then called vsnprintf() to do the formatting. CoreFundation's
(Apple) CFString has a similar functions, such as:

http://developer.apple.com/documentation/CoreFoundation/Reference/CFMutableStringRef/Reference/reference.html#//apple_ref/doc/uid/20001504-CH201-F11101

Sebastian

[Ian Collins]

Re: The lcc-win string library

jacob navia wrote:

Stephen Sprunk wrote:

>>
>C does not have operator or function overloading. Quit spamming
>comp.lang.c with advertisements for compiler features that are not C.
>>
>IMHO, you would be better served simply adding the few remaining
>features that are required to make lcc-win32 a C++ compiler, rather
>than trying to convince people that your extensions are or should be
>part of C. There is a reason these features were _not_ backported
>from C++ to C as many other "improvemen ts" have been.
>>
>S

>
There is a central difference.
>
C is not object oriented, and the complexity and bloat that are
associated with that make it a much simpler language.
>

C++ doesn't have to be OO either.

A recent quote from James Kanze on c.l.c++:

"I believe it was Robert Martin that first pointed it out, but
the complexity is always there; it's inherit in the application.
In the case of C++, that complexity manifests itself in the
language; in the case of C, in the code we have to write to
solve the problem. Which means that in the case of C++, we have
to master it once, for all applications; in the case of C, we
have to master it for each application."

--
Ian Collins

[Richard Heathfield]

Re: The lcc-win string library

jacob navia said:

Within the context of the lcc-win experimental compiler
a complete str_ing library is available that uses operator
overloading and overloaded functions to present a new type
of string library in C, that
>
o features counted strings, that eliminates buffer overflows
o It has a syntax very similar to the old functions
(Strcat vs strcat, etc)
o It could be faster for some operations like (precisely)
Strcat since there is no need to search for the terminating
zero.
>
The source code for the whole library can be found in the
normal distribution of lcc-win.

The "normal distribution of lcc-win" would appear to be a Win32 executable
file. Presumably the intent is that only Win32 users should be able to
take part in this experiment - and even then, only if they are prepared to
trust an arbitrary program to execute on their system.

I qualify on the first count (because there's a Win32 machine kicking
around the place here somewhere, I'm sure), but not the second.

From the description you give, however, it seems that what you've done is
(a) implemented your own string library, which is fine, we've all done
that, and (b) rendered it non-portable by making it rely on implementation
extensions. In other words, people using your library to any great extent
are, by so doing, locking themselves in to your implementation.

Presumably this is not accidental.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999