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.

 

[Antoninus Twink]

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?

 

[lawrence.jones]

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?

 

[Stephen Sprunk]

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 "improvements" have been.

S

 

[jacob navia]

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]

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 "improvements" 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.

 

[Keith Thompson]

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.

 

[CBFalconer]

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"

 

[CBFalconer]

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 "improvements" 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.

 

[jacob navia]

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}"

 

[Keith Thompson]

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.

 

[Chris M. Thomasson]

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]

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 StringAssignFormat(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/document...tml#//apple_ref/doc/uid/20001504-CH201-F11101

Sebastian

 

[Ian Collins]

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

 

[Antoninus Twink]

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.

You really have issues Falconer.

It's the oldest trick in the book: "*I* am not a bully - no, *I* would
never be like those other people who beat up on Jacob". And at the very
same moment you're sliding the knife into his back with your ridiculous
"not a C compiler" nonsense.

CBF - 84 years old, and hopefully any day now Usenet will have the
blessed relief of the end of his presence on earth.

 

[Antoninus Twink]

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.

What, haven't you heard of Wine then Heathfield?

 

[lawrence.jones]

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

That's OK for printf arguments, but not for the sprintf result or scanf
arguments since it subverts the "no buffer overflows" the string type is
supposed to provide.

 

[Keith Thompson]

CBF - 84 years old, and hopefully any day now Usenet will have the
blessed relief of the end of his presence on earth.

I'm quoting this just in case anyone still thought Antoninus Twink was
anything more than a waste of bandwidth. Publicly wishing for
someone's death is despicable, and this is not the first time he's
done it.

 

[Antoninus Twink]

I'm quoting this just in case anyone still thought Antoninus Twink was
anything more than a waste of bandwidth. Publicly wishing for
someone's death is despicable, and this is not the first time he's
done it.

You're the pedant Keith - read the words and you'll find I didn't wish
for CBF's death, I just pointed out that Usenet will be a better place
when it happens.

You can't deny that CBF's old age has spilled over into senility, and
this is partly responsible for his grumpiness, his inability to
comprehend what he reads, his poor attention span, etc., all of which
make his "contributions" to this group nothing more than sources of
frustration for everyone - even those who take his side in the group's
"topicality" politics, Heathfield being a prime example.

 

[CBFalconer]

.... snip ...


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

There is a major problem here. There is no such thing as a "string
type" in C. There is only a data format for use in a char array.
This consists of characters, extended and terminated by a '\0'
char. That char marks the end of the active string.

No cast will so alter the char array, and there is no guarantee
that there is even room to append the '\0' termination marker.
Remember that, in accurate C, a cast is usually an error. The
prime exception is variadic parameters.