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

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

calling argumentless function with argument

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

Contents

  calling argumentless function with argument jt@toerring.de (Jens Thoms Toerring) - 2019-01-04 16:04 +0000
    Re: calling argumentless function with argument David Brown <david.brown@hesbynett.no> - 2019-01-04 17:34 +0100
      Re: calling argumentless function with argument Bart <bc@freeuk.com> - 2019-01-04 17:30 +0000
        Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-04 09:50 -0800
          Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-05 05:58 -0800
            Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-05 07:56 -0800
              Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-05 10:56 -0800
                Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-05 14:55 -0800
                  Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 01:29 +0100
                    Re: calling argumentless function with argument Bart <bc@freeuk.com> - 2019-01-06 02:20 +0000
                      Re: calling argumentless function with argument Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-06 02:51 +0000
                        Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 12:12 +0100
                          Re: calling argumentless function with argument Bart <bc@freeuk.com> - 2019-01-06 11:53 +0000
                            Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 12:58 +0100
                        Re: calling argumentless function with argument Bart <bc@freeuk.com> - 2019-01-06 11:45 +0000
                          Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 12:58 +0100
                            Re: calling argumentless function with argument Bart <bc@freeuk.com> - 2019-01-06 12:24 +0000
                              Re: calling argumentless function with argument Keith Thompson <kst-u@mib.org> - 2019-01-06 04:34 -0800
                              Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 13:41 +0100
                          Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 04:10 -0800
                            Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 13:51 +0100
                              Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 13:56 +0100
                                Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 05:20 -0800
                                  Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 16:08 +0100
                                    Re: calling argumentless function with argument Keith Thompson <kst-u@mib.org> - 2019-01-06 15:59 -0800
                              Re: calling argumentless function with argument Bart <bc@freeuk.com> - 2019-01-06 13:42 +0000
                                Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 06:22 -0800
                                  Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 16:19 +0100
                                    Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 07:42 -0800
                                      Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 08:05 -0800
                                        Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 08:30 -0800
                                      Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 17:44 +0100
                                        Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 08:54 -0800
                                        Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-07 08:02 -0800
                                          Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-07 08:07 -0800
                                          Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-07 09:16 -0800
                                            Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-07 09:40 -0800
                                              Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-07 09:57 -0800
                                            Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-09 02:23 -0800
                                Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 16:17 +0100
                                  Re: calling argumentless function with argument Bart <bc@freeuk.com> - 2019-01-06 16:56 +0000
                                    Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 09:12 -0800
                                      Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 12:39 -0800
                                    Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 18:26 +0100
                                      Re: calling argumentless function with argument Bart <bc@freeuk.com> - 2019-01-06 18:52 +0000
                    Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-06 02:32 -0800
                    Re: calling argumentless function with argument Keith Thompson <kst-u@mib.org> - 2019-01-06 04:38 -0800
                      Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 13:42 +0100
                        Re: calling argumentless function with argument Robert Wessel <robertwessel2@yahoo.com> - 2019-01-06 10:27 -0600
                          Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-06 17:47 +0100
        Re: calling argumentless function with argument David Brown <david.brown@hesbynett.no> - 2019-01-04 19:30 +0100
        Re: calling argumentless function with argument Keith Thompson <kst-u@mib.org> - 2019-01-04 10:55 -0800
        Re: calling argumentless function with argument Robert Wessel <robertwessel2@yahoo.com> - 2019-01-05 00:16 -0600
      Re: calling argumentless function with argument queequeg@trust.no1 (Queequeg) - 2019-01-07 10:43 +0000
        Re: calling argumentless function with argument Robert Wessel <robertwessel2@yahoo.com> - 2019-01-07 16:25 -0600
    Re: calling argumentless function with argument Barry Schwarz <schwarzb@dqel.com> - 2019-01-04 09:54 -0800
    Re: calling argumentless function with argument Thiago Adams <thiago.adams@gmail.com> - 2019-01-04 10:26 -0800
      Re: calling argumentless function with argument Keith Thompson <kst-u@mib.org> - 2019-01-04 12:07 -0800
    Re: calling argumentless function with argument James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-04 15:03 -0500
      Re: calling argumentless function with argument Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-05 00:04 +0000
        Re: calling argumentless function with argument James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-05 22:36 -0500
    Re: calling argumentless function with argument jt@toerring.de (Jens Thoms Toerring) - 2019-01-05 13:17 +0000
      Re: calling argumentless function with argument fir <profesor.fir@gmail.com> - 2019-01-05 06:06 -0800
      Re: calling argumentless function with argument David Brown <david.brown@hesbynett.no> - 2019-01-05 15:42 +0100
        Re: calling argumentless function with argument Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-05 14:58 +0000
      Re: calling argumentless function with argument "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-05 16:11 +0100
      Re: calling argumentless function with argument Richard Damon <Richard@Damon-Family.org> - 2019-01-05 11:23 -0500
        Re: calling argumentless function with argument Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-05 16:53 +0000
          Re: calling argumentless function with argument Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-06 00:46 +0000

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

#139465

fir <profesor.fir@gmail.com> writes:

> it was like that
>
> float f = 2.53;
> int i = 3;
>
> char txt[] = "ala has "+i+" cats and "+f+" dogs";
>
> print(txt);
>
>
> would produce text of the content "ala has 3 cats and 2.53 dogs" then print in on screen
>
> the code is fired by operators and fires the underlying ftos and itoa
> action then then assemblies the resulted 5 chips of text into one
> resizable array (located most probably on heap or on stack if that
> code was local to function)
>
> this is considered extension of c (small part of it as i consider rethinking whole algebra of operators not only +) (this algebra i call 'algebra' or 'string algebra')
>
>
> some problem it dont seems quite c style but i would like to reconsider it anyway


If we are considering extensions, instead of using + for concatenation,
I would propose to use the binary operator !.  It's already the
concatenation operator in some other programming languages (since at
least 46 years).  It would be a pure extension to C, so it wouldn't
break any existing program.

 char txt[] = "ala has "!i!" cats and "!f!" dogs";

Now, there's the problem of converting integers and floating point
numbers to strings.  It is a very bad idea to make it implicit.  If only
because there are a lot of possible representations (different bases,
different formating of floating point numbers, etc).

 int i=42;
 float f=3.141592;
 char txt[] = "ala has "!int_to_string(i,width=7,base=10)!" cats and "
             !float_to_string(f,width=7,fraction=2,exponent=0)!" dogs";
 -> txt=="ala has      42 cats and    3.14 dogs"

Of course, that doesn't prevent you to write a library of simplified
default formaters:

 char txt[] = "ala has "!i2s(i)!" cats and "!f2s(f)!" dogs";

But there's nothing to be gained by making them implicit.

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

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

#139466

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> fir <profesor.fir@gmail.com> writes:
>> some problem it dont seems quite c style but i would like to reconsider it anyway

Another bigger problem is that of memory management.  Such a run-time
concatenation operator would imply dynamic allocation of memory, which
is not something that is provided by the C programming language in the
first place! (we have to use a library function malloc, implemented
using OS syscalls).

And if you introduce such implicit memory allocations, you increase the
risk of memory leaks, if you don't add a garbage collector.  (Notice how
all the languages that have such operations have also a garbage
collector!).

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

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

#139467

W dniu niedziela, 6 stycznia 2019 13:56:26 UTC+1 użytkownik Pascal J. Bourguignon napisał:
> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
> 
> > fir <profesor.fir@gmail.com> writes:
> >> some problem it dont seems quite c style but i would like to reconsider it anyway
> 
> Another bigger problem is that of memory management.  Such a run-time
> concatenation operator would imply dynamic allocation of memory, which
> is not something that is provided by the C programming language in the
> first place! (we have to use a library function malloc, implemented
> using OS syscalls).
> 
> And if you introduce such implicit memory allocations, you increase the
> risk of memory leaks, if you don't add a garbage collector.  (Notice how
> all the languages that have such operations have also a garbage
> collector!).
> 
no, this is not a problem i wrote a lot why back then (not bother to repeat)

as to those previous post, the exact syntax for that 'concatenations' is secondary 

it could be

txt = "ala has ",i ,"cats";

converted to string of chars if txt is char[] or converted to array of ints if txt is int array etc

or it could be

txt = "ala has " i "cats";

such decisions are hard to take, and maybe better to take them after everything else is done... first problem is to invent whole algebra

at working stage + for concatenations is
more readable

some work ideas woled be

txt - "aaa"
for removing (cutting) first "aaa" that is found in txt

 txt("aaa")

as find operation ('at')

  txt("aaa")="zz"

would for examble could be used to replace first found "aaa" by "zz"

   txt("aaa")+="zz"

could be used to found first left "aaa"
and add "zz" after it 

(those are some work ideas only hovever..
definig such algebra is some kind of abstract exercise./.but may be worth doing if someone has niot better things to do
and imo such algebra could be much better
and easy to use then 'regular expressions' which are trash imo

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

#139470

fir <profesor.fir@gmail.com> writes:

> such decisions are hard to take, and maybe better to take them after everything else is done... first problem is to invent whole algebra

Agreed.

> at working stage + for concatenations is more readable

This is not true.  Granted, it's relative to the user, but realize that
programmers that consider that + is concatenation have a distorted view.
+ is addition for everybody. The concatenation operator is always
denoted with some something else (· or ! or empty, etc).

But foremost, in the case of C:

1- string + integer and integer + string already has a meaning so you
   cannot use + to mean concatenation in those cases.

2- string-literal string-literal already means concatenation.  So it
   would be much better to use empty for concatenation, than +.
   (But ! would be even better, and as binary operator it's free).

> some work ideas woled be
>
> txt - "aaa"
> for removing (cutting) first "aaa" that is found in txt

Nope.  Again, using arithmetic operators to work on string is a bad
idea. Do you remove it as prefix? as suffix? in the middle of the
string? Do you remove multiple occurences?

Also, you should not consider just strings.  Strings are vectors of
bytes.  There are other vectors of integers in C.  And what about other
vectors? (eg vectors of structures, vectors of pointers, etc)

> definig such algebra is some kind of abstract exercise./.but may be worth doing if someone has niot better things to do
> and imo such algebra could be much better
> and easy to use then 'regular expressions' which are trash imo

This is just a string processing library.

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

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

#139487

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:
[...]
> This is not true.  Granted, it's relative to the user, but realize that
> programmers that consider that + is concatenation have a distorted view.
> + is addition for everybody. The concatenation operator is always
> denoted with some something else (· or ! or empty, etc).

That's not correct.  C++ and Python, for example, both use "+"
for string concatenation (C++ for its std::string type, not for
C-style strings), and I'm sure there are plenty of other languages
that do the same.  It's not mathematical addition, but it is a
kind of addition, in that you're "adding" a string to the end of
another string.  In any case, programmers who use those languages
are, for the most part, perfectly capable of understanding that
"+" in that context doesn't mean addition.

The assignment of operator symbols to operations, both in mathematics
and in programming, is mostly arbitrary.

I suggest that what you mean is that you personally dislike using
"+" for concatenation.

> But foremost, in the case of C:
>
> 1- string + integer and integer + string already has a meaning so you
>    cannot use + to mean concatenation in those cases.

That's only an issue if you want to support concatenation of strings and
integers without explicit conversion.

> 2- string-literal string-literal already means concatenation.  So it
>    would be much better to use empty for concatenation, than +.
>    (But ! would be even better, and as binary operator it's free).

The existing syntax for string literal concatenation is unambiguous,
since two adjacent string literals don't have a different meaning.
Allowing arbitrary expressions could produce some ambiguities, and
could cause problems for typos.  *If* C were to add a concatenation
operator, it should probably be a punctuation symbol.  I would have
no problem using "!"  for this.  (Perl 6 uses "~", FWIW.)

But working out the semantics would be very difficult.

C++'s std::string is defined using the features of the language
(classes, operator overloading, implicitly invoked constructors and
destructors, etc.).  If there were a way to do something similar
using C's language features, or by adding some *small* well-defined
set of features that would be of general use, I wouldn't object.
I'm just skeptical that it's practical.  (Of course you could do it by
turning C into C++, but C++ already exists.)

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#139468

On 06/01/2019 12:51, Pascal J. Bourguignon wrote:
> fir <profesor.fir@gmail.com> writes:
> 
>> it was like that
>>
>> float f = 2.53;
>> int i = 3;
>>
>> char txt[] = "ala has "+i+" cats and "+f+" dogs";
>>
>> print(txt);
>>
>>
>> would produce text of the content "ala has 3 cats and 2.53 dogs" then print in on screen
>>
>> the code is fired by operators and fires the underlying ftos and itoa
>> action then then assemblies the resulted 5 chips of text into one
>> resizable array (located most probably on heap or on stack if that
>> code was local to function)
>>
>> this is considered extension of c (small part of it as i consider rethinking whole algebra of operators not only +) (this algebra i call 'algebra' or 'string algebra')
>>
>>
>> some problem it dont seems quite c style but i would like to reconsider it anyway
> 
> 
> If we are considering extensions, instead of using + for concatenation,
> I would propose to use the binary operator !.  It's already the
> concatenation operator in some other programming languages (since at
> least 46 years).

Which ones? On this page:

  http://rosettacode.org/wiki/String_concatenation

the most common operator, when it is done by an infix operator, seems to 
be "+", followed by "&". (I couldn't search for "!" because that occurs 
in "hello world!" in every example.)

   It would be a pure extension to C, so it wouldn't
> break any existing program.
> 
>   char txt[] = "ala has "!i!" cats and "!f!" dogs";
> 
> Now, there's the problem of converting integers and floating point
> numbers to strings.  It is a very bad idea to make it implicit.  If only
> because there are a lot of possible representations (different bases,
> different formating of floating point numbers, etc).
> 
>   int i=42;
>   float f=3.141592;
>   char txt[] = "ala has "!int_to_string(i,width=7,base=10)!" cats and "
>               !float_to_string(f,width=7,fraction=2,exponent=0)!" dogs";
>   -> txt=="ala has      42 cats and    3.14 dogs"
> 
> Of course, that doesn't prevent you to write a library of simplified
> default formaters:
> 
>   char txt[] = "ala has "!i2s(i)!" cats and "!f2s(f)!" dogs";
> 
> But there's nothing to be gained by making them implicit.

For this purpose, you really need specialist print formatting, rather 
than concatenating lots of string terms that gets very messy. This is 
another thing that every language differently.

For this example however, C's sprintf is clearer:

   sprintf(txt, "ala has %7d cats and %.2f dogs", i, f);


-- 
bart

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

#139469

W dniu niedziela, 6 stycznia 2019 14:42:58 UTC+1 użytkownik Bart napisał:
> 
> For this purpose, you really need specialist print formatting, rather 
> than concatenating lots of string terms that gets very messy. This is 
> another thing that every language differently.
> 
> For this example however, C's sprintf is clearer:
> 
>    sprintf(txt, "ala has %7d cats and %.2f dogs", i, f);
> 
> 

what i wa$ sayin is more on general string algebra (less on printf case, i mentioned printf compari$on as some side a$pect)

problem is hovever if that would be very easy to use it will be extremaly inefficient in some cases like

char txt[] = load("notex.txt");

while(txt("ala") = "Alice");

replaces all "ala" by "Alice" but makes N big memcopies where if someone would write it normally it would be none of them

problem is if that would be in language people would have different treshold of using it (posssibly much liker to use thos unnecessary memcopies) and that 
would result in crowd of suboptimal 
codes - that could be a doom to the world : O
(notable that split patter dont brings that doom)

hovever at least theoretically i would like to reconsider that potential algebra
(not being sure if im doin right)

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

#139472

fir <profesor.fir@gmail.com> writes:

> hovever at least theoretically i would like to reconsider that potential algebra
> (not being sure if im doin right)

Just define it as functions.

Consider that you may want to provide two API:

- a purely functional API (how do you manage memory in that case?)
- a mutating API.

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

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

#139473

W dniu niedziela, 6 stycznia 2019 16:19:14 UTC+1 użytkownik Pascal J. Bourguignon napisał:
> fir <profesor.fir@gmail.com> writes:
> 
> > hovever at least theoretically i would like to reconsider that potential algebra
> > (not being sure if im doin right)
> 
> Just define it as functions.
> 
> Consider that you may want to provide two API:
> 
> - a purely functional API (how do you manage memory in that case?)
> - a mutating API.
> 
what do you mean by purely functional api?

as to operatos i told you its dont 
matter for me rgigh now what those operators will be, you may imagine + with a dot above instead of normal + etc)

writing it in operatorial form is just better for prototyping imo ...

more question would be to define it all..hovever i will probably not answer it this time.. some topics needs time

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

#139474

W dniu niedziela, 6 stycznia 2019 16:43:09 UTC+1 użytkownik fir napisał:
> W dniu niedziela, 6 stycznia 2019 16:19:14 UTC+1 użytkownik Pascal J. Bourguignon napisał:
> > fir <profesor.fir@gmail.com> writes:
> > 
> > > hovever at least theoretically i would like to reconsider that potential algebra
> > > (not being sure if im doin right)
> > 
> > Just define it as functions.
> > 
> > Consider that you may want to provide two API:
> > 
> > - a purely functional API (how do you manage memory in that case?)
> > - a mutating API.
> > 
> what do you mean by purely functional api?
> 
> as to operatos i told you its dont 
> matter for me rgigh now what those operators will be, you may imagine + with a dot above instead of normal + etc)
> 
> writing it in operatorial form is just better for prototyping imo ...
> 
> more question would be to define it all..hovever i will probably not answer it this time.. some topics needs time

as how to make resizable sytings in c ?

i may do it like about that

typedef struct
 {
   char* beg,* end;
 }
   rchunk;

rchunk ResizeChunk(rchunk x, int size)
{
    x.beg = (char*) realloc(x.beg, size );

    if((size>0) && (x.beg==NULL)) ERROR_EXIT("ResizeChunk failed");

    x.end = x.beg + size - 1;
    return x;
}

void test39890830()
{
  rchunk dipa;

  dipa = ResizeChunk(dipa, 100);

  dipa = ResizeChunk(dipa, 3000);

}

here dipa and things like that is what you pass and what represents your string , ResizeChunk is what you call to resize

but as i said i want to consider it if 
it would be builtin in languege where you would wrote

char[] dipa = "hallo";
char[] dipa2 = " world";

char[] dipa3 = dipa + dipa2;

//by char[] i denote full-array, it is those two pointers not like arrays in c which are half-arrays, only the begining

(the last would execute

 rchunk dipa3;

  int length = dipa.end-dipa.beg + 1 + dipa2.end-dipa2.beg+1;

  dipa3 = ResizeChunk(dipa3, 3000);
 //+ two memcopies

 int copied = CopyChunks(dipa3, dipa);
 rchunk x = {dipa3.beg+copied, dipa3.end}
 CopyChunks(x, dipa);


where

int CopyChunks(chunk dest, chunk src)
{
  int dest_len = ChunkLength(dest);
  int src_len = ChunkLength(src);

  if(src_len>  dest_len ) ERROR_EXIT(" src_len>  dest_len  in CopyChunks");

  for(int i=0; i< src_len; i++)
  {
     dest.beg[i] = src.beg[i];
  }

  return src_len;

}

sorta mechanic like that (in heap case, separate for stack) but covered in a form of 'string algebra' on operators

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

#139476

W dniu niedziela, 6 stycznia 2019 17:06:09 UTC+1 użytkownik fir napisał:
> 
> char[] dipa = "hallo";
> char[] dipa2 = " world";
> 
> char[] dipa3 = dipa + dipa2;
> 

possibly for basic type there could be predefined char[] as chars int[] as ints
float[] as floats

 chars dipa = "hallo";
 chars dipa2 = " world";
 
 chars dipa3 = dipa + dipa2;
 
more good for the eye

if i wrote on such things i often must abstract out of syntax details instead i could more easily 'get crazy' with that ;c (jking, it would just be burden in head, fortunately syntax can be often abstracted away)

i was also writing on char[][] construct which is then "fullarray of "char[]" fullarrays" (which is 2-pointer (beg, end) to array of N 2-pointers)

(beg, end) -> 

(beg, end) 
(beg, end) 
(beg, end) 
(beg, end) 
(beg, end) 
(beg, end) 
(beg, end) 

and that is sorta useful container (resizable array of resizable strings)

chars[] words = {"ala", "has", "cat"};

it is resizable it is you may insert 
programmeaticaly word after "has" and cat"

"ala", "has", "4", "cat"

then add s at the and of "cat"

"ala", "has", "4", "cats"

c function interface for it hovever 
would look like

words = insert_before(words, "cat", "4");
chars cat_word = find_string(words, "cat")
cat_word = replace_string(cat_word, "cats");

and though its still very useful operators can probably look better



i got in fact code for that already written and i use it in my code, there is a dose of debigging with al that pointers and reallolocks fiored but ehen debuged it work ok


> 
>   int length = dipa.end-dipa.beg + 1 + dipa2.end-dipa2.beg+1;
> 
>   dipa3 = ResizeChunk(dipa3, 3000);

  dipa3 = ResizeChunk(dipa3, length);

(was mistyped)

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

#139477

fir <profesor.fir@gmail.com> writes:

> W dniu niedziela, 6 stycznia 2019 16:19:14 UTC+1 użytkownik Pascal J. Bourguignon napisał:
>> fir <profesor.fir@gmail.com> writes:
>> 
>> > hovever at least theoretically i would like to reconsider that potential algebra
>> > (not being sure if im doin right)
>> 
>> Just define it as functions.
>> 
>> Consider that you may want to provide two API:
>> 
>> - a purely functional API (how do you manage memory in that case?)
>> - a mutating API.
>> 
> what do you mean by purely functional api?


With mutation:

    char foo[]="foo";
    remove_subsequence(foo,"oo");
    assert(0==strcmp(foo,"f"));


Without mutation (functional API):

    assert(0==strcmp(remove_subsequence("foo","oo"),"f"));

    char foo[]="foo";
    assert(0==strcmp(remove_subsequence(foo,"oo"),"f"));
    assert(0==strcmp(foo,"foo"));
    

> as to operatos i told you its dont 
> matter for me rgigh now what those operators will be, you may imagine
> + with a dot above instead of normal + etc)

This is why you should not talk about them and instead just specify
functions.

It if it worth providing syntax for those functions, this can be done
later.

Syntax would change the language, functions would not.


> writing it in operatorial form is just better for prototyping imo ...

Nope, since you will need to write a new compiler, or at least, a
pre-processor with a full parser.  It's much easier to just write it in
C by defining normal C functions.

> more question would be to define it all..hovever i will probably not
> answer it this time.. some topics needs time

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

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

#139480

W dniu niedziela, 6 stycznia 2019 17:44:33 UTC+1 użytkownik Pascal J. Bourguignon napisał:
> > writing it in operatorial form is just better for prototyping imo ...
> 
> Nope, since you will need to write a new compiler, or at least, a
> pre-processor with a full parser.  It's much easier to just write it in
> C by defining normal C functions.
> 

i got no problem with writing compiler for it.. you need both good theory and copiler.. already write some initial compiler (now its very limited in what it can compile but produces exe that can be ron )

compiler is a different story, theory is like worse

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

#139495

W dniu niedziela, 6 stycznia 2019 17:44:33 UTC+1 użytkownik Pascal J. Bourguignon napisał:
> fir <profesor.fir@gmail.com> writes:
> >> 
> > what do you mean by purely functional api?
> 
> 
> With mutation:
> 
>     char foo[]="foo";
>     remove_subsequence(foo,"oo");
>     assert(0==strcmp(foo,"f"));
> 
> 
> Without mutation (functional API):
> 
>     assert(0==strcmp(remove_subsequence("foo","oo"),"f"));
> 
>     char foo[]="foo";
>     assert(0==strcmp(remove_subsequence(foo,"oo"),"f"));
>     assert(0==strcmp(foo,"foo"));
>     
> 
specific cases not always define general term and i still dont know

dou you mean 

str c = "aaa" + "bbb";

as being non mutable?

str c = "aaa" + "bbb";
c ="dddddddd"

as being non mutable too?

one is creation in runtime
second is relacement
third would be cuts and inserts (but this is for sure mutable)

dont knowing what you mean is hard 
to answer

that api without (i call this algebra of strings as api, also named it specifiacally pandora) ability to creation of strings in runtime would be very limited i guess, this with no 
ability to make replacements seems also to much limited

i could try to generate soem library that disalow memcopies hovever separatelay from other idea to gerate some which uses memcopies so that would be two ways, maybe foist would be "nonmutalbe" but that probbaly wpuld be too limited..so i gues what i say here (pandora) would be rather mutable

uf you mean non mutable as those who only produces new strings based on old but not chnges the contents of old (but anyway destroys them when not needed) it seems probably not good idea as creations and destructions are probably as have as mutability

(hoever those are sorta guesses, i would need to check)

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

#139496

W dniu poniedziałek, 7 stycznia 2019 17:02:33 UTC+1 użytkownik fir napisał:
>probably not good idea as creations and destructions are probably as have* as mutability
> 
meant, 'probably as heavy as mutability'

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

#139497

> pandora

still the question is, what is needed

as i said rhigt now i consider 3 kinds
of operations
- insert
- cut
- operator at which is sorta find operator (at I temporarely write as: txt("ala") )

both inserts and cuts can be realised by "=" (combined with at, it also may add at begin and end of that string)

worth nothing that string elements or substrings can be 'indexed' by indexes or 
by content/values

txt = "ala ma kota";

txt(0,2)="Alice";
txt("ala")="Alice";

that could maybe temporarely stand as some draft maybe those above could be turned into txt[0,2] txt["ala"] to resemble array syntax

the question is what else.. do thoise think i thinked it may be bigger api colapses to that 'at' and '=' only?

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

#139498

W dniu poniedziałek, 7 stycznia 2019 18:17:02 UTC+1 użytkownik fir napisał:
> > pandora
> 
> still the question is, what is needed
> 
> as i said rhigt now i consider 3 kinds
> of operations
> - insert
> - cut
> - operator at which is sorta find operator (at I temporarely write as: txt("ala") )
> 
> both inserts and cuts can be realised by "=" (combined with at, it also may add at begin and end of that string)
> 
> worth nothing that string elements or substrings can be 'indexed' by indexes or 
> by content/values
> 
> txt = "ala ma kota";
> 
> txt(0,2)="Alice";
> txt("ala")="Alice";
> 
> that could maybe temporarely stand as some draft maybe those above could be turned into txt[0,2] txt["ala"] to resemble array syntax
> 
> the question is what else.. do thoise think i thinked it may be bigger api colapses to that 'at' and '=' only?

one usecase i thinked out is a sorta of ini file which is some txt config file
(know mostly from win16 afaik)

name=firr
race=high elf
class=fighter

in a txt file when readed that could look like

txt = "\nname=firr\nrace=high elf\nclass=fighter\n";

now there would be handy to have some easy pandora to update that kind of entries

like
1) add one if value is empty, like
race=
2) add some if key not exist
3) replace value if value is set and you want change it, like
race=high elf
want to turn into 'gray elf'

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

#139499

W dniu poniedziałek, 7 stycznia 2019 18:40:29 UTC+1 użytkownik fir napisał:
> W dniu poniedziałek, 7 stycznia 2019 18:17:02 UTC+1 użytkownik fir napisał:
> > > pandora
> > 
> > still the question is, what is needed
> > 
> > as i said rhigt now i consider 3 kinds
> > of operations
> > - insert
> > - cut
> > - operator at which is sorta find operator (at I temporarely write as: txt("ala") )
> > 
> > both inserts and cuts can be realised by "=" (combined with at, it also may add at begin and end of that string)
> > 
> > worth nothing that string elements or substrings can be 'indexed' by indexes or 
> > by content/values
> > 
> > txt = "ala ma kota";
> > 
> > txt(0,2)="Alice";
> > txt("ala")="Alice";
> > 
> > that could maybe temporarely stand as some draft maybe those above could be turned into txt[0,2] txt["ala"] to resemble array syntax
> > 
> > the question is what else.. do thoise think i thinked it may be bigger api colapses to that 'at' and '=' only?
> 
> one usecase i thinked out is a sorta of ini file which is some txt config file
> (know mostly from win16 afaik)
> 
> name=firr
> race=high elf
> class=fighter
> 
> in a txt file when readed that could look like
> 
> txt = "\nname=firr\nrace=high elf\nclass=fighter\n";
> 
> now there would be handy to have some easy pandora to update that kind of entries
> 
> like
> 1) add one if value is empty, like
> race=
> 2) add some if key not exist
> 3) replace value if value is set and you want change it, like
> race=high elf
> want to turn into 'gray elf'

maybe something like that

if(!txt("race="))
  txt(end) = "\nrace=gray elf";
else
  txt("race=", "\n") = "race=gray elf\n";
  
where txt("race=", "\n") its like combined at it choses by two edge substrings inclusively

some details dont fit here but thats maybe some direction

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

#139552

W dniu poniedziałek, 7 stycznia 2019 18:17:02 UTC+1 użytkownik fir napisał:
> > pandora
> 
> still the question is, what is needed
> 
> as i said rhigt now i consider 3 kinds
> of operations
> - insert
> - cut
> - operator at which is sorta find operator (at I temporarely write as: txt("ala") )
> 
> both inserts and cuts can be realised by "=" (combined with at, it also may add at begin and end of that string)
> 
> worth nothing that string elements or substrings can be 'indexed' by indexes or 
> by content/values
> 
> txt = "ala ma kota";
> 
> txt(0,2)="Alice";
> txt("ala")="Alice";
> 
> that could maybe temporarely stand as some draft maybe those above could be turned into txt[0,2] txt["ala"] to resemble array syntax
> 
> the question is what else.. do thoise think i thinked it may be bigger api colapses to that 'at' and '=' only?

i could yet add i glimpsed what java strig has and what i noticed it could be yet potentially added here, was

- rightside at
- in general some 'middle' at
- leftside and rightside compare
- trim (?)

hjava also ahas regexo but regexp is trash i dont like

btw im a bit weary of this topic, but possibly i will back to it (some noptes were taken)

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

#139471

Bart <bc@freeuk.com> writes:

> Which ones? On this page:

For example the first programming language I learned, LSE (Langage
Symbolique d'Enseignement).

>  http://rosettacode.org/wiki/String_concatenation
>
> the most common operator, when it is done by an infix operator, seems
> to be "+", followed by "&". (I couldn't search for "!" because that
> occurs in "hello world!" in every example.)
>
>> It would be a pure extension to C, so it wouldn't
>> break any existing program.

& is already a binary operator.  "foo" & "bar" already means something
in C, (even if in modern C it produces warnings for the implicit cast).

> For this example however, C's sprintf is clearer:
>
>   sprintf(txt, "ala has %7d cats and %.2f dogs", i, f);

Indeed, I prefer format templates better than concatenation to produce
formatted output.

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

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

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

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

csiph-web