Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Text processing

Reply
Thread Tools

Text processing

 
 
Ben Pfaff
Guest
Posts: n/a
 
      09-26-2011
jacob navia <(E-Mail Removed)> writes:

> Following the series about commenting code, here is an installment about
> text processing.
>
> What do you think?


There is existing software that does a pretty good job with
string translations (e.g. GNU gettext). I don't know whether you
are actually writing new software that also handles this, or
whether you are just pointing out a way that it can be done to
people new to the topic. If it's the former, it seems somewhat
wasteful (what's inadequate about current attempts?); if it's the
latter, that makes some sense to me.
--
Ben Pfaff
http://benpfaff.org
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      09-26-2011
Le 26/09/11 20:11, Ben Pfaff a crit :
> jacob navia<(E-Mail Removed)> writes:
>
>> Following the series about commenting code, here is an installment about
>> text processing.
>>
>> What do you think?

>
> There is existing software that does a pretty good job with
> string translations (e.g. GNU gettext). I don't know whether you
> are actually writing new software that also handles this, or
> whether you are just pointing out a way that it can be done to
> people new to the topic. If it's the former, it seems somewhat
> wasteful (what's inadequate about current attempts?); if it's the
> latter, that makes some sense to me.


I have written in the context of my IDE a better software than that.
The objective here is to present simple code that does some
filtering, and discuss its problems and ways to improve it an hand
of actual code.

This improves the S/N ration of this group.




 
Reply With Quote
 
 
 
 
Harald van Dijk
Guest
Posts: n/a
 
      09-26-2011
On Sep 26, 2:18*pm, Ben Bacarisse <(E-Mail Removed)> wrote:
> And, second, the
> output does not compile because the initial
>
> * static char *StringTable[];
>
> is a tentative definition of an object with incomplete type (that's a
> constraint violation).


6.9.2p3 says the declared type of a tentative definition with internal
linkage must not be an incomplete type, but it isn't a constraint,
which matters because it means compilers are not required to issue any
diagnostics. And I wonder if that is really meant to apply to the
declared type, rather than the composite type for the final implicit
definition mentioned in p2. Compilers are already required to accept
"int array[]; int array[20] = {1};" -- without the static keyword --
and they would surely need to treat the static keyword specially to
reject it if present.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-26-2011
Kleuskes & Moos <(E-Mail Removed)> writes:
[...]
> Without actually delving into the code, i notice the attempt is pretty much
> useless since many, nay, most languages do limit themselves to the ascii-
> standard.

[...]

I think you accidentally a word there.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Harald van Dijk
Guest
Posts: n/a
 
      09-26-2011
On Sep 26, 9:36*pm, Harald van Dijk <(E-Mail Removed)> wrote:
> On Sep 26, 2:18*pm, Ben Bacarisse <(E-Mail Removed)> wrote:
>
> > And, second, the
> > output does not compile because the initial

>
> > * static char *StringTable[];

>
> > is a tentative definition of an object with incomplete type (that's a
> > constraint violation).

>
> 6.9.2p3 says the declared type of a tentative definition with internal
> linkage must not be an incomplete type, but it isn't a constraint,
> which matters because it means compilers are not required to issue any
> diagnostics. And I wonder if that is really meant to apply to the
> declared type, rather than the composite type for the final implicit
> definition mentioned in p2. Compilers are already required to accept
> "int array[]; int array[20] = {1};" -- without the static keyword --
> and they would surely need to treat the static keyword specially to
> reject it if present.


I feel I should add that the standard does clearly and unambiguously
disallow this, so regardless of the intent, programs should avoid this
construct.
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      09-26-2011
Le 26/09/11 22:33, Harald van Dijk a écrit :
> On Sep 26, 9:36 pm, Harald van Dijk<(E-Mail Removed)> wrote:
>> On Sep 26, 2:18 pm, Ben Bacarisse<(E-Mail Removed)> wrote:
>>
>>> And, second, the
>>> output does not compile because the initial

>>
>>> static char *StringTable[];

>>
>>> is a tentative definition of an object with incomplete type (that's a
>>> constraint violation).

>>
>> 6.9.2p3 says the declared type of a tentative definition with internal
>> linkage must not be an incomplete type, but it isn't a constraint,
>> which matters because it means compilers are not required to issue any
>> diagnostics. And I wonder if that is really meant to apply to the
>> declared type, rather than the composite type for the final implicit
>> definition mentioned in p2. Compilers are already required to accept
>> "int array[]; int array[20] = {1};" -- without the static keyword --
>> and they would surely need to treat the static keyword specially to
>> reject it if present.

>
> I feel I should add that the standard does clearly and unambiguously
> disallow this, so regardless of the intent, programs should avoid this
> construct.


You are right.

One way of getting rid of the problem is to avoid the static qualifier
but that would mean surely a link error when used in many files.

Since I write into stdout there isn't the possibility of rewinding to
add the size of the table after we know how many strings there are.

Mmm, there must be a solution but it doesn't come immediately. I think
I have to sleep, I had a hell of a day today at the job.

jacob

 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-26-2011
Harald van Dijk <(E-Mail Removed)> writes:

> On Sep 26, 2:18*pm, Ben Bacarisse <(E-Mail Removed)> wrote:
>> And, second, the
>> output does not compile because the initial
>>
>> * static char *StringTable[];
>>
>> is a tentative definition of an object with incomplete type (that's a
>> constraint violation).

>
> 6.9.2p3 says the declared type of a tentative definition with internal
> linkage must not be an incomplete type, but it isn't a constraint,
> which matters because it means compilers are not required to issue any
> diagnostics. And I wonder if that is really meant to apply to the
> declared type, rather than the composite type for the final implicit
> definition mentioned in p2. Compilers are already required to accept
> "int array[]; int array[20] = {1};" -- without the static keyword --
> and they would surely need to treat the static keyword specially to
> reject it if present.


Yes, it's very odd. I assume there is some advantage in knowing the
complete type of objects with internal linkage at the get go. I can't
think of one, though.

However, I don't think 6.9.2p3 makes much sense if the final composite
type is assumed to be the intended meaning because, I don't think the
final composite type *can* be incomplete? For example, a translation
union with nothing other than

int array[];

is fine and causes the type of array to be int [1] by at the end.

--
Ben.
 
Reply With Quote
 
Harald van Dijk
Guest
Posts: n/a
 
      09-26-2011
On Sep 26, 11:58*pm, Ben Bacarisse <(E-Mail Removed)> wrote:
> However, I don't think 6.9.2p3 makes much sense if the final composite
> type is assumed to be the intended meaning because, I don't think the
> final composite type *can* be incomplete? *For example, a translation
> union with nothing other than
>
> * int array[];
>
> is fine and causes the type of array to be int [1] by at the end.


I was thinking of incomplete structure and union types.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-27-2011
Harald van Dijk <(E-Mail Removed)> writes:

> On Sep 26, 11:58*pm, Ben Bacarisse <(E-Mail Removed)> wrote:
>> However, I don't think 6.9.2p3 makes much sense if the final composite
>> type is assumed to be the intended meaning because, I don't think the
>> final composite type *can* be incomplete? *For example, a translation
>> union with nothing other than
>>
>> * int array[];
>>
>> is fine and causes the type of array to be int [1] by at the end.

>
> I was thinking of incomplete structure and union types.


I'd considered that and ruled them out. Composite types must be
compatible, and an incomplete struct type is not compatible with a
complete one declared in the same translation unit (I think!).

--
Ben.
 
Reply With Quote
 
Harald van Dijk
Guest
Posts: n/a
 
      09-27-2011
On Sep 27, 2:41*am, Ben Bacarisse <(E-Mail Removed)> wrote:
> Harald van Dijk <(E-Mail Removed)> writes:
> > On Sep 26, 11:58*pm, Ben Bacarisse <(E-Mail Removed)> wrote:
> >> However, I don't think 6.9.2p3 makes much sense if the final composite
> >> type is assumed to be the intended meaning because, I don't think the
> >> final composite type *can* be incomplete? *For example, a translation
> >> union with nothing other than

>
> >> * int array[];

>
> >> is fine and causes the type of array to be int [1] by at the end.

>
> > I was thinking of incomplete structure and union types.

>
> I'd considered that and ruled them out. *Composite types must be
> compatible, and an incomplete struct type is not compatible with a
> complete one declared in the same translation unit (I think!).


An incomplete struct type is completed by a struct definition with the
same tag in the same scope, see 6.7.2.3p4 for the official wording and
p12 for an example.

struct X x; /* tentative definition with incomplete type */
struct X { int a; }; /* completed here */
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Controlling text in a Text Area or Text leo ASP General 1 12-05-2005 01:13 AM
Processing pathnames listed in a text file. Jason Heyes C++ 4 03-24-2005 11:47 AM
Post-Processing RAW vs Post-Processing TIFF Mike Henley Digital Photography 42 01-30-2005 08:26 AM
Question: processing HTML, re-write default processing action of many tags Hubert Hung-Hsien Chang Python 2 09-17-2004 03:10 PM
"Text Processing in Python" review on Slashdot Joe Francia Python 0 07-08-2003 04:30 AM



Advertisments