Thursday, April 12, 2018

Digest for comp.lang.c++@googlegroups.com - 9 updates in 2 topics

David Brown <david.brown@hesbynett.no>: Apr 12 11:55PM +0200

On 12/04/18 22:17, Ben Bacarisse wrote:
> separator in numbers. (Note the "little" -- I don't want to make a
> Federal case out of this.)
 
> Having significant spaces in identifiers would be bonkers.
 
There we agree.
 
But I'd also say that allowing non-significant spaces in identifiers is
bonkers too. (I think I saw somewhere that Fortran allows them, but it
is not a language I know.) I would greatly dislike having both
"numberoflines", "number of lines" and "nu mbero flin e s" all meaning
the same thing. It is bad enough that some languages allow you to be
inconsistent in capitalisation - but at least you can use
case-insensitive searches.
 
> that's not how it was phrased) and published algorithms with thin spaces
> in complex identifiers are very readable. But typography has moved on
> #iPad, #monospacedfontsarecool, #noonecaresaboutspacesatallanymore.
 
I am happy with _ for spaces in identifiers - I can't see any need or
advantage in using spaces instead of underlines.
 
(My typography has not moved on - like you, I put two spaces after the
end of sentences.)
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 12 02:55PM -0700

On 4/12/2018 1:35 PM, Rick C. Hodgin wrote:
>> use it.
 
> CAlive has a thread model already. If it can be incorporated or
> extended to be compatible with C11 Threads, then it could be included.
 
Lets see here:
 
[...]
 
> // Assign later:
> t = some_function();
> t.start;
 
This is way too high level for me, however, I am trying to get oriented
here:
 
thread.start starts a thread, okay.
 
> And to terminate:
 
> self.out; // Used in the thread itself
> t.out; // Explicitly end the indicated thread
 
You have self.out and t.out, but what is t.out? You say it explicitly
ends the thread? Please clarify. Does t.out obtain the value provided by
self.out in the thread? So, t.out is like a join, that _waits_ for the
thread to call self.out? The relationship acts like a join?
__________________________
void some_function(thread& self)
{
// processing...
 
self.out = "Fin!";
}
 
int main()
{
thread t = some_function;
 
// Create Thread t
t.start;
 
// Join Thread t
const char* c = t.out;
 
// Outputs "Fin!"
puts(c);
 
return 0;
}
__________________________
 
 
Btw, have you ever really looked at C11 threads? If not read here:
 
http://en.cppreference.com/w/c/thread
 
And, you have to support the atomic's and membars:
 
http://en.cppreference.com/w/c/atomic
 
Also, do you have simple mutex and condvar implementations?
 
Threads in C11 are low level. I want to be able to use all of
stdatomic.h and threads.h. CAlive has to be able to support these. So
far, the threading interface you showed here is way to abstract and
limiting.
 
[...]
David Brown <david.brown@hesbynett.no>: Apr 12 11:56PM +0200

On 12/04/18 23:27, Öö Tiib wrote:
>> > _
 
> C++:
 
> unsigned long long int kadabra;
 
That is not an identifier with spaces - it is separate keywords which
are therefore separated with spaces. (And there is one identifier at
the end, with no space.)
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 12 03:18PM -0700

On 4/11/2018 1:48 PM, Scott Lurndal wrote:
> will work (at least on unix and linux systems).
 
> #define thrd_ pthread_
 
> ...
 
It does not work for multiple reasons. It cannot work. Here is a little
example:
_________________________
#include <stdio.h>
 
void pthread_foo()
{
printf("pthread_foo\n");
}
 
void thrd_foo()
{
printf("thrd_foo\n");
}
 
#define thrd_ pthread_
 
int main(void)
{
thrd_foo();
 
return 0;
}
_________________________
 
 
Also, the interfaces are different from a mapping of pthread_* functions
to thrd_* functions. For instance:
_________________________
int pthread_create(
pthread_t *thread,
const pthread_attr_t *attr,
void *(*start_routine)(void*),
void *arg
);
 
int thrd_create(
thrd_t *thr,
thrd_start_t func,
void *arg
);
_________________________
 
See?
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 12 03:26PM -0700

On 4/12/2018 3:18 PM, Chris M. Thomasson wrote:
> );
> _________________________
 
> See?
 
Fwiw, here is a limited abstraction of C11 threads I created over POSIX
threads:
 
https://pastebin.com/raw/bJUbDmKy
 
https://groups.google.com/d/topic/comp.lang.c/WPH7ed5uS4Y/discussion
 
It does support stdatomic.h, but it does support a lot of threads.h
 
:^)
bartc <bc@freeuk.com>: Apr 12 10:52PM +0100

On 12/04/2018 21:16, Paavo Helde wrote:
>>    int h=0, w=0;
>>    getdims(h,w);
 
> Arguments in the wrong order.
 
Yeah, I didn't test the C fragments before posting.
 
> &0 would not be a null pointer, but a pointer to some zero constant
> somewhere (hopefully not in the global table of constants ;-).
 
Really? In my language, I guess in C too, & must be applied to an
lvalue. A constant number isn't an lvalue, otherwise you could do 0=1.
 
The reason for the reference would normally be to be able to modify or
replace the caller's data. What would be the purpose of changing that 0?
Its new value can't be accessed.
 
Null
> }
 
> int h=0, w=0;
> std::tie(w, h) = getdims();
 
This sort of thing I used for incidental return values in addition to
the main return value. Or where you want to modify multiple data in the
caller. You don't always want the bother of creating a special return
type and it's not always appropriate.
 
This is an actual example from C:
 
char* loadjpeg(char* filename, int* width, *height);
 
The main return value is a pointer to image data, or NULL on error. But
when it works, dimensions are returned via those two values.
 
This is where references would be a tidier way of doing things.
 
(In C also, a parameter like int* could equally be used to pass arrays
[because the language is messed up like that], so using int& would tell
you this is a reference to a single int object, and you can only treat
it as an int within the function.)
 
--
bartc
 
David Brown <david.brown@hesbynett.no>: Apr 13 12:05AM +0200

On 12/04/18 22:13, bartc wrote:
 
>> I am guessing you meant something like "{width = 10; height = 20;}" ?
 
> Yes; I wondered what happened to all my height=20's. I'm sure they were
> there before I posted! (And how did you know it was 20?)
 
We have battled for so long that I can read your mind :-)
 
 
> OK. In this case it seems a remarkably simple feature to implement
> (perhaps 20 or 30 extra lines in a compiler). Something C could do with
> perhaps.
 
I hope you are sitting down, because I agree with you! I think
references could be a convenient feature in C programming, and would be
easy to implement - they are basically just syntactic sugar for constant
pointers with a non-null restriction.
 
There is one issue, however, that might put people off. When you call
"getdims(h, w);" in C, you know that "h" and "w" will not be changed.
That is gone if you have reference parameters. The C++ world seems to
have accepted this without trouble, but the C world might be more
conservative.
David Brown <david.brown@hesbynett.no>: Apr 13 12:16AM +0200

On 12/04/18 22:16, Paavo Helde wrote:
>>    getdims(&h,&w);
 
> Arguments in the wrong order. This actually suggests encapsulating these
> numbers into a Dims struct where such mixups would be less probable.
 
I really wish C and C++ would get support for named parameters - that
would stop this sort of mistake being possible.
 
> }
 
> int h=0, w=0;
> std::tie(w, h) = getdims();
 
Or:
 
auto [w, h] = getdims();
 
But that still has the problem of being able to mix up the height and
width. I dislike returning pairs unless the elements are interchangeable.
 
auto getdims() {
return (struct { int width; int height; }) { 10, 20 };
}
 
auto dims = getdims();
auto area = dims.height * dims.width;
Ian Collins <ian-news@hotmail.com>: Apr 13 10:21AM +1200

On 04/13/2018 10:05 AM, David Brown wrote:
> references could be a convenient feature in C programming, and would be
> easy to implement - they are basically just syntactic sugar for constant
> pointers with a non-null restriction.
 
It would also help put an end to the eternal can't tell the size of an
array function parameter debate :)
 
--
Ian.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)