Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #63176 > unrolled thread
| Started by | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| First post | 2015-06-10 22:32 -0700 |
| Last post | 2015-06-10 23:07 -0700 |
| Articles | 20 on this page of 182 — 25 participants |
Back to article view | Back to comp.lang.c
Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-10 22:32 -0700
Re: Reason for segmentation violation Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2015-06-11 07:52 +0200
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-11 07:19 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-11 15:46 +0100
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-11 11:23 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-11 12:08 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-11 15:44 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-11 12:55 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-11 16:29 -0400
Re: Reason for segmentation violation gordonb.h0fbo@burditt.org (Gordon Burditt) - 2015-06-17 23:51 -0500
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-17 23:10 -0700
Re: Reason for segmentation violation gordonb.0vo9r@burditt.org (Gordon Burditt) - 2015-06-18 03:30 -0500
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 02:40 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-11 21:00 +0100
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-11 19:58 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-11 23:42 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-12 08:33 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-12 02:36 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-12 11:07 +0100
Re: Reason for segmentation violation gwowen <gwowen@gmail.com> - 2015-06-12 04:55 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-12 13:17 +0100
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-12 13:32 +0100
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-12 13:20 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-13 23:55 -0700
Restrictions on inline functions (Was: Reason for segmentation violation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-14 10:30 +0100
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-12 11:10 -0400
Re: Reason for segmentation violation David Thompson <dave.thompson2@verizon.net> - 2015-06-21 12:46 -0400
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-12 08:35 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-12 12:21 -0400
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-12 10:48 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-12 19:12 +0100
Re: Reason for segmentation violation David Kleinecke <dkleinecke@gmail.com> - 2015-06-12 08:49 -0700
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-12 09:13 -0700
Re: Reason for segmentation violation David Kleinecke <dkleinecke@gmail.com> - 2015-06-13 08:55 -0700
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-12 08:56 -0700
Re: Reason for segmentation violation glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-12 09:41 +0000
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-12 08:29 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 00:03 -0700
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-14 00:58 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 02:14 -0700
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-14 04:26 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 06:29 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-14 15:06 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 07:25 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-14 16:59 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 11:51 -0700
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-14 16:43 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 14:16 -0700
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-14 20:35 -0400
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-15 01:19 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 03:57 -0700
Re: Reason for segmentation violation Bartc <bc@freeuk.com> - 2015-06-15 12:26 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 04:47 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-15 15:02 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 07:08 -0700
Re: Reason for segmentation violation Bartc <bc@freeuk.com> - 2015-06-15 18:56 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 20:09 -0700
Re: Reason for segmentation violation Bartc <bc@freeuk.com> - 2015-06-16 09:31 +0100
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 10:09 +0100
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-16 02:36 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 11:01 +0100
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 12:37 +0100
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-16 08:40 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-16 10:32 -0700
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-17 07:54 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 05:28 -0700
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-18 00:34 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 09:13 +0200
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-19 21:17 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-20 23:28 +0200
Re: Reason for segmentation violation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-15 05:26 -0700
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-15 06:20 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 14:25 +0100
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-15 07:52 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 18:29 +0100
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-15 11:15 -0700
Re: Reason for segmentation violation raltbos@xs4all.nl (Richard Bos) - 2015-06-18 20:41 +0000
Re: Reason for segmentation violation Bartc <bc@freeuk.com> - 2015-06-15 18:48 +0100
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-15 11:04 -0700
Re: Reason for segmentation violation raltbos@xs4all.nl (Richard Bos) - 2015-06-18 20:44 +0000
Re: Reason for segmentation violation David Brown <david.brown@hesbynett.no> - 2015-06-19 10:39 +0200
Re: Reason for segmentation violation gwowen <gwowen@gmail.com> - 2015-06-16 00:58 -0700
Re: Reason for segmentation violation raltbos@xs4all.nl (Richard Bos) - 2015-06-18 20:40 +0000
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-18 17:06 -0400
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 14:56 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 23:04 +0100
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-18 18:18 -0400
Re: Reason for segmentation violation David Brown <david.brown@hesbynett.no> - 2015-06-19 10:26 +0200
Re: Reason for segmentation violation David Kleinecke <dkleinecke@gmail.com> - 2015-06-19 08:57 -0700
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-15 08:54 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 06:24 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-15 14:32 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 05:43 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-14 23:28 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 16:31 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-15 01:27 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 05:34 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-15 15:00 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 20:37 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 09:58 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-16 10:37 -0700
Re: Reason for segmentation violation luser droog <luser.droog@gmail.com> - 2015-06-15 17:51 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 21:02 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-16 00:51 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 22:30 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-17 00:35 -0400
Re: Reason for segmentation violation Rosario19 <Ros@invalid.invalid> - 2015-06-19 18:51 +0200
Re: Reason for segmentation violation luser droog <luser.droog@gmail.com> - 2015-06-15 22:40 -0700
Re: Reason for segmentation violation luser droog <luser.droog@gmail.com> - 2015-06-15 23:23 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-16 11:07 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-16 23:54 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 10:51 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 03:46 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 04:17 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 14:02 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 06:15 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 15:34 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 07:58 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 16:04 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 08:16 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 14:57 +0200
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-18 15:35 +0100
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-18 15:44 +0100
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 08:18 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-18 16:42 +0100
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 08:19 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 16:35 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 08:49 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-17 11:56 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 09:46 +0200
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 09:14 -0700
Re: Reason for segmentation violation gordonb.446bm@burditt.org (Gordon Burditt) - 2015-06-18 01:56 -0500
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 09:54 +0200
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 09:08 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-22 16:53 +0200
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 16:32 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-22 18:21 +0200
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-22 16:33 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-22 18:20 +0200
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-22 13:05 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-22 19:47 +0200
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 13:52 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 06:05 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 15:39 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 08:02 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 16:12 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 10:46 +0200
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-17 16:12 +0100
Re: Reason for segmentation violation Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:28 -0700
Re: Reason for segmentation violation Ian Collins <ian-news@hotmail.com> - 2015-06-18 07:32 +1200
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 22:02 +0200
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 13:16 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 22:32 +0200
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-23 06:52 +0200
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-17 16:16 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 22:44 +0200
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-17 17:39 -0400
Re: Reason for segmentation violation Robert Wessel <robertwessel2@yahoo.com> - 2015-06-18 01:57 -0500
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 09:29 +0200
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-17 13:57 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 23:10 +0200
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-17 14:22 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 23:41 +0200
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-18 00:40 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 09:18 +0200
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 08:52 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 09:27 -0700
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 11:00 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 07:48 -0700
Re: Reason for segmentation violation Bartc <bc@freeuk.com> - 2015-06-14 16:53 +0100
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-14 10:59 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 11:45 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-14 20:01 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 12:40 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-14 21:00 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 13:13 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 13:17 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-14 16:36 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 13:43 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-14 14:50 -0400
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-12 03:21 -0700
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-10 23:07 -0700
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-22 19:47 +0200 |
| Message-ID | <mm9hnf$b6j$1@speranza.aioe.org> |
| In reply to | #63835 |
On 22.06.2015 19:05, James Kuyper wrote:
> On 06/22/2015 10:53 AM, Morten W. Petersen wrote:
> ...
>> I'm experiencing some issues with this typedef thing and arrays.
>>
>> There's a type definition:
>>
>> typedef unsigned int unicode_char;
>>
>> And the code:
>>
>> unicode_char compare_to3[] = {0x2d,0x2d,0x00};
>> printf("compare_to3: %s\n", compare_to3[1]);
>>
>> This causes a segmentation violation. What I'm thinking is that
>> the array gets initialized to one element (integer).
>>
>> What's wrong here?
>
> That depends upon what you're trying to do.
> You're passing an unsigned int to printf(), when the corresponding
> format specifier expects a char*; that just doesn't work.
>
> Do you want to see the numeric value of compare_to3[1] (which is 0x2d,
> or 45)? Then use a format string of "%u".
>
> Do want to print the character represented by 45 according to whichever
> character encoding is used by your standard library? In that case, use
>
> printf("compare_to3: %c\n", compare_to3[1]);
I wanted to see what was going on, but using an %s instead of an
%lx set you and others off on the wrong issue.
> Do you wamt to display the character represented by the Unicode code
> point 0x2d2d00? C did not specify such functionality until C2011. If you
> can find a fully conforming implementation of C2011, then you should
> first convert the values stored in compare_to3[] into the correspond
> Unicode code point value, and store it in a char32_t variable. Beware
> unsigned wraparound - force the calculations to be done in a type known
> to be big enough to avoid that problem, such as unsigned long or
> char32_t itself.
> Then call c32rtomb() to convert that to a multi-byte string. Note that
> null-terminating a multi-byte string may first require undoing some
> shift states; the appropriate sequence can be generating by using
> c32rtomb() to convert a null character. The resulting string can then be
> displayed using the "%s" format specifier you wrote above.
Hm, OK. Well, I was thinking of having converting functions available,
so that regardless of what type form the integrator wants the Unicode
in, they'll get it.
I guess I'll have to look at different ways of dealing with Unicode,
so that different libraries and compilers can be supported.
Which brings up the question, what kind of build system is recommended?
The project is here:
https://github.com/morphex/smash_xml
The project currently has a Makefile, and when compiling the project
the make command is used. Is there any cross-platform way of figuring
out dependencies and integrations, for example to see if some Unicode-
enabled library is available and link to that?
Is it enough to specify the function prototype and then link towards
the library?
> I started writing example code, but c32rtomb() is a somewhat complicated
> function, and I don't have a compiler where I can test whether my code
> even compiles, much less works correctly. This is something I've never
> done before, and I make enough mistakes as it is when writing the first
> draft of code doing something I've done hundreds of times before. I
> figured I'd let myself in for less embarrassment if I didn't attempt it.
> Good luck!
Thanks. :)
Well I'd appreciate suggestions on how to do things, how char32 and
multi-byte strings work is something that has to be figured out.
Although I'll definently look for converter functions within the
libraries and compilers first.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-17 13:52 +0100 |
| Message-ID | <87k2v2v6o1.fsf@bsb.me.uk> |
| In reply to | #63395 |
"Morten W. Petersen" <morphex@gmail.com> writes: > On Wednesday, June 17, 2015 at 11:51:15 AM UTC+2, Ben Bacarisse wrote: >> "Morten W. Petersen" <morphex@gmail.com> writes: > [...] >> > OK. Well I see different versions of stdint.h are available, and I'm >> > thinking I want to include as little external code as possible. >> > >> > Do you or anyone else here know of an include file I could use that >> > has just int32_t? I don't see the project needing any other integer >> > than that. >> >> The type want is actually int_least32_t (or uint_least32_t). There is >> no reason why your program should not compile simply because an exact >> width type is not available. >> >> But your comparatively narrow range of targets means that for C90 the >> type to use is just int (or unsigned int). None of your targets have an >> int type that is smaller than 32 bits, and I don't think any of them >> have a wider int type whist at the time having a 32-bit short. > > Then I have to ask, what kinds of other targets that have less than 32 > bit ints are there today that are alive (and even growing)? I don't know -- I'm not an exert on the diversity of C implementations. There maybe some very low-cost chips with 16-bit ints and a C compiler but I imagine even these are dwindling. Someone who knows may chip in... > A quick and easy way for the current targets is to pass around > unsigned shorts then? I don't get this at all. What are you asking here? >> But this brings up another issue. If you are writing a complete >> application the internal representation of your data matters only to >> you, but if you plan to write an XML parsing library (i.e. a parser that >> other programs can use) then your choice of representation becomes more >> significant. > > Well, the first idea I had for a project was a XML validator which was > going to be superduper fast using assembly and everything. Then I > found that it had to be valid Unicode as well. Then I found that you > have to keep track of the state as well to properly validate, and when > keeping a state, why not keep the entire structure in memory? And > when you have it all in memory, it's fairly easy to write it out as > well when you know your way around the code. > > What started as one project grew into another and it keeps growing. I > think it would be healthy and smart to avoid scope creep, so yes, it > would be nice to integrate with other projects at this level instead > of for example writing a DOM manipulator as well. > > So targets and integration are issues I need to figure out. If > unsigned shorts are 32 bits on the current targets then that should be > good enough for now. I've gone over what I said, and I can't see why you think this. On the systems you listed (basically modern POSIX systems and modern Windows systems) ints are 32-bit. That's it. Use int if you insist on old C, but on modern you could use types like char32_t and some built-in Unicode support. The only reason you might use short is on a system where int is too big and wasteful of space, but I said I know of no systems with ints bigger than 32-bts where shorts are 32-bits. I.e. there are no systems where short will be the type you need. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-17 06:05 -0700 |
| Message-ID | <95abae54-7c3a-452e-90a6-7f91bf16627b@googlegroups.com> |
| In reply to | #63401 |
On Wednesday, June 17, 2015 at 2:52:26 PM UTC+2, Ben Bacarisse wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: > > > On Wednesday, June 17, 2015 at 11:51:15 AM UTC+2, Ben Bacarisse wrote: [...] > >> But your comparatively narrow range of targets means that for C90 the > >> type to use is just int (or unsigned int). None of your targets have an > >> int type that is smaller than 32 bits, and I don't think any of them > >> have a wider int type whist at the time having a 32-bit short. > > > > Then I have to ask, what kinds of other targets that have less than 32 > > bit ints are there today that are alive (and even growing)? > > I don't know -- I'm not an exert on the diversity of C implementations. > There maybe some very low-cost chips with 16-bit ints and a C compiler > but I imagine even these are dwindling. Someone who knows may chip > in... > > > A quick and easy way for the current targets is to pass around > > unsigned shorts then? > > I don't get this at all. What are you asking here? Ah I misunderstood, I read it as you saying shorts as being 32 bits. [...] > > So targets and integration are issues I need to figure out. If > > unsigned shorts are 32 bits on the current targets then that should be > > good enough for now. > > I've gone over what I said, and I can't see why you think this. On the > systems you listed (basically modern POSIX systems and modern Windows > systems) ints are 32-bit. That's it. Use int if you insist on old C, > but on modern you could use types like char32_t and some built-in > Unicode support. > > The only reason you might use short is on a system where int is too big > and wasteful of space, but I said I know of no systems with ints bigger > than 32-bts where shorts are 32-bits. I.e. there are no systems where > short will be the type you need. Well, what I've read earlier in this thread says that a common subset of C90, C99 and C11 is a smart thing to do. I don't know the probably many different compilers there are out there, and if anything, I'd expect that a standard defined over 20 years ago should be well supported in most of them. As a developer I've learned that using libraries and existing systems is a good idea, but for my purposes, it's OK to do a little extra work because it will give me a deeper understanding of C and Assembler. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-17 15:39 +0100 |
| Message-ID | <87381qv1pk.fsf@bsb.me.uk> |
| In reply to | #63404 |
"Morten W. Petersen" <morphex@gmail.com> writes: <snip> > Well, what I've read earlier in this thread says that a common subset > of C90, C99 and C11 is a smart thing to do. It's certainly one person's strongly held view. Was it widely supported? Also, it was suggested when you have made a very general remark about running on the widest possible range of systems. I think there was also an alternate view -- that the sticking point for using modern C is Windows and that you might consider finding out what the state of the art is in Windows C compilers and using that, since you'll almost certainly find similar support on the other targets. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-17 08:02 -0700 |
| Message-ID | <9deab457-d451-4508-98cd-e5e096950ae0@googlegroups.com> |
| In reply to | #63410 |
On Wednesday, June 17, 2015 at 4:39:28 PM UTC+2, Ben Bacarisse wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: > <snip> > > Well, what I've read earlier in this thread says that a common subset > > of C90, C99 and C11 is a smart thing to do. > > It's certainly one person's strongly held view. Was it widely > supported? Also, it was suggested when you have made a very general > remark about running on the widest possible range of systems. Yes, that's true. > I think there was also an alternate view -- that the sticking point for > using modern C is Windows and that you might consider finding out what > the state of the art is in Windows C compilers and using that, since > you'll almost certainly find similar support on the other targets. Well, modern C compilers also compile "old style" code better I presume, what are the newer language features that are should-haves? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-17 16:12 +0100 |
| Message-ID | <87lhfitlmc.fsf@bsb.me.uk> |
| In reply to | #63413 |
"Morten W. Petersen" <morphex@gmail.com> writes: > On Wednesday, June 17, 2015 at 4:39:28 PM UTC+2, Ben Bacarisse wrote: <snip> >> I think there was also an alternate view -- that the sticking point for >> using modern C is Windows and that you might consider finding out what >> the state of the art is in Windows C compilers and using that, since >> you'll almost certainly find similar support on the other targets. > > Well, modern C compilers also compile "old style" code better I > presume, what are the newer language features that are should-haves? In this context I would find out if you can use any of the multi-byte character support and/or the wide character string support. What state that is in on Windows might be a deciding factor for me. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-18 10:46 +0200 |
| Message-ID | <mlu0hh$1vj$1@speranza.aioe.org> |
| In reply to | #63416 |
On 17.06.2015 17:12, Ben Bacarisse wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: > >> On Wednesday, June 17, 2015 at 4:39:28 PM UTC+2, Ben Bacarisse wrote: > <snip> >>> I think there was also an alternate view -- that the sticking point for >>> using modern C is Windows and that you might consider finding out what >>> the state of the art is in Windows C compilers and using that, since >>> you'll almost certainly find similar support on the other targets. >> >> Well, modern C compilers also compile "old style" code better I >> presume, what are the newer language features that are should-haves? > > In this context I would find out if you can use any of the multi-byte > character support and/or the wide character string support. What state > that is in on Windows might be a deciding factor for me. Yeah. Well it should be possible to create tie-ins towards different compilers and these new characters. As I said somewhere else in this thread, creating functions that "convert" or "interface" towards different types is doable. I don't know if there's a standard way of doing this or if I should use the approach Gordon Burditt suggested earlier today. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-17 16:12 +0100 |
| Message-ID | <mls2lj$cq4$1@dont-email.me> |
| In reply to | #63410 |
On 17/06/15 15:39, Ben Bacarisse wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: > <snip> >> Well, what I've read earlier in this thread says that a common subset >> of C90, C99 and C11 is a smart thing to do. > > It's certainly one person's strongly held view. Was it widely > supported? Of course! *Everybody* agrees with me, *all* the time! Didn't you get the memo?[1] > Also, it was suggested when you have made a very general > remark about running on the widest possible range of systems. This was, of course, the reason for my replying as I did. It would be hard to argue against the notion that the common subset of C90, C99, and C11 is the best way to support the widest possible range of hosted implementations. For freestanding implementations, one would have to be even stricter. For those who only need to remain compatible with, say, a couple of *nix compilers, the answer may well be very different. > I think there was also an alternate view -- that the sticking point for > using modern C is Windows and that you might consider finding out what > the state of the art is in Windows C compilers and using that, since > you'll almost certainly find similar support on the other targets. That's also a reasonable approach, as long as care is taken not to adopt any Windows-specific behaviours. [1] TINC. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-11 08:28 -0700 |
| Message-ID | <kfnvbdqyapw.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #63415 |
Richard Heathfield <rjh@cpax.org.uk> writes: > It would be > hard to argue against the notion that the common subset of C90, C99, > and C11 is the best way to support the widest possible range of hosted > implementations. On the contrary, it would be very easy to argue against said notion, depending on how "best" is defined.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-06-18 07:32 +1200 |
| Message-ID | <cue0a8FtgmiU1@mid.individual.net> |
| In reply to | #63410 |
Ben Bacarisse wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: > <snip> >> Well, what I've read earlier in this thread says that a common subset >> of C90, C99 and C11 is a smart thing to do. > > It's certainly one person's strongly held view. Was it widely > supported? Also, it was suggested when you have made a very general > remark about running on the widest possible range of systems. > > I think there was also an alternate view -- that the sticking point for > using modern C is Windows and that you might consider finding out what > the state of the art is in Windows C compilers and using that, since > you'll almost certainly find similar support on the other targets. Windows support for current C has improved somewhat now more of it is in C++! They do strive for full support of current C++ standards. I take the hint and use the language they do support! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-17 22:02 +0200 |
| Message-ID | <mlsjnq$7lo$1@speranza.aioe.org> |
| In reply to | #63453 |
On 17.06.2015 21:32, Ian Collins wrote: > Ben Bacarisse wrote: >> "Morten W. Petersen" <morphex@gmail.com> writes: >> <snip> >>> Well, what I've read earlier in this thread says that a common subset >>> of C90, C99 and C11 is a smart thing to do. >> >> It's certainly one person's strongly held view. Was it widely >> supported? Also, it was suggested when you have made a very general >> remark about running on the widest possible range of systems. >> >> I think there was also an alternate view -- that the sticking point for >> using modern C is Windows and that you might consider finding out what >> the state of the art is in Windows C compilers and using that, since >> you'll almost certainly find similar support on the other targets. > > Windows support for current C has improved somewhat now more of it is in > C++! They do strive for full support of current C++ standards. > > I take the hint and use the language they do support! Well I don't mind C99 or C11, I know little about them and I see C11 has threading which I'm interested in. Then again, I could use threading from the Apache APR and get a cross-platform threading solution right there. What kind of experience do you all have with cross-platform features like threading? Is it consistent over all platforms? -Morten (now using Thunderbird)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-17 13:16 -0700 |
| Message-ID | <lnk2v2jdjz.fsf@nuthaus.mib.org> |
| In reply to | #63455 |
"Morten W. Petersen" <morphex@gmail.com> writes:
[...]
> Well I don't mind C99 or C11, I know little about them and I see C11 has
> threading which I'm interested in.
>
> Then again, I could use threading from the Apache APR and get a
> cross-platform threading solution right there.
>
> What kind of experience do you all have with cross-platform features
> like threading? Is it consistent over all platforms?
I'm not aware of *any* C implementation that supports C11 threading.
Perhaps someone else knows of one?
https://gcc.gnu.org/wiki/C11Status marks it as "Library issue (not
implemented)".
It's an optional feature (i.e., an implementation can claim C11
conformance without providing it).
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-17 22:32 +0200 |
| Message-ID | <mlslgp$c0m$1@speranza.aioe.org> |
| In reply to | #63456 |
On 17.06.2015 22:16, Keith Thompson wrote: [...] > I'm not aware of *any* C implementation that supports C11 threading. > Perhaps someone else knows of one? > > https://gcc.gnu.org/wiki/C11Status marks it as "Library issue (not > implemented)". > > It's an optional feature (i.e., an implementation can claim C11 > conformance without providing it). OK, good to know. Then it looks like a cross-platform kit is the way to go, I see the APR has a lot of other features I'm interested in as well. -Morten
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-23 06:52 +0200 |
| Message-ID | <mmaom3$183$1@speranza.aioe.org> |
| In reply to | #63458 |
On 17.06.2015 22:32, Morten W. Petersen wrote: > On 17.06.2015 22:16, Keith Thompson wrote: > [...] >> I'm not aware of *any* C implementation that supports C11 threading. >> Perhaps someone else knows of one? >> >> https://gcc.gnu.org/wiki/C11Status marks it as "Library issue (not >> implemented)". >> >> It's an optional feature (i.e., an implementation can claim C11 >> conformance without providing it). > > OK, good to know. > > Then it looks like a cross-platform kit is the way to go, I see > the APR has a lot of other features I'm interested in as well. With regards to keeping the code and dependencies simple and small, so far it looks like pthreads is the way to go. Another thing is coding with/without threads, but I guess one can at compile-time select code, for example in pseudo code: main_parsing_loop: #if not threads read_from_fs() #endif process_data() Where the thread code always keeps maybe 10KB of data ready for processing. -Morten
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-17 16:16 -0400 |
| Message-ID | <5581D5A3.2000104@verizon.net> |
| In reply to | #63455 |
On 06/17/2015 04:02 PM, Morten W. Petersen wrote: ... > What kind of experience do you all have with cross-platform features > like threading? Is it consistent over all platforms? No - which is reason why support for threading was added to the C standard in 2011. The <threads.h> routines will generally be implemented as thin wrappers over platform-specific threading systems (such as <pthreads.h> on POSIX platforms), with the result of hiding the differences between threading systems on different platforms. Implementing a "lowest common denominator" threading system means that it lacks many useful/convenient features that are present in some of the platform-specific threading systems. You'll have to trade off between portability and functionality, if those features are of importance to you.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-17 22:44 +0200 |
| Message-ID | <mlsm6i$dpa$1@speranza.aioe.org> |
| In reply to | #63457 |
On 17.06.2015 22:16, James Kuyper wrote: > On 06/17/2015 04:02 PM, Morten W. Petersen wrote: > ... >> What kind of experience do you all have with cross-platform features >> like threading? Is it consistent over all platforms? > > No - which is reason why support for threading was added to the C > standard in 2011. The <threads.h> routines will generally be implemented > as thin wrappers over platform-specific threading systems (such as > <pthreads.h> on POSIX platforms), with the result of hiding the > differences between threading systems on different platforms. > Implementing a "lowest common denominator" threading system means that > it lacks many useful/convenient features that are present in some of the > platform-specific threading systems. You'll have to trade off between > portability and functionality, if those features are of importance to you. Right, OK. For starters I'm going to use threads in the simple ways, to make use of multiple processors/threading. For example with a 21-bit internal representation of Unicode, one thread can "run ahead" and unpack the characters into 32 bits, and the main program code can go after and evaluate whatever it has to evaluate. I guess it could be interesting to have the library be thread-safe, but I'm not sure how useful that would be and I'm thinking I'd have to put read and write requests in a queue. That way, any number of threads could read at the same time, but when a write comes all others have to wait until the write is complete and the state is consistent. Out of curiosity, what are these useful platform-specific features? -Morten
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-17 17:39 -0400 |
| Message-ID | <5581E8F6.3020502@verizon.net> |
| In reply to | #63459 |
On 06/17/2015 04:44 PM, Morten W. Petersen wrote: > On 17.06.2015 22:16, James Kuyper wrote: >> On 06/17/2015 04:02 PM, Morten W. Petersen wrote: >> ... >>> What kind of experience do you all have with cross-platform features >>> like threading? Is it consistent over all platforms? >> >> No - which is reason why support for threading was added to the C >> standard in 2011. The <threads.h> routines will generally be implemented >> as thin wrappers over platform-specific threading systems (such as >> <pthreads.h> on POSIX platforms), with the result of hiding the >> differences between threading systems on different platforms. >> Implementing a "lowest common denominator" threading system means that >> it lacks many useful/convenient features that are present in some of the >> platform-specific threading systems. You'll have to trade off between >> portability and functionality, if those features are of importance to you. ,,, > Out of curiosity, what are these useful platform-specific features? I'm no expert - but you can get a good idea of what might be missing by comparing <pthreads.h> and <threads.h>. Virtually every <threads.h> function has a corresponding and similarly named <pthreads.h> equivalent - but the reverse is far from true. The functions from <pthreads.h> that have no <threads.h> equivalent provide functionality not available from <threads.h>. Even for the ones where there is a correspondence, the corresponding <threads.h> function might not have all of the capabilities of the <pthreads.h> one - but that requires a more in-depth comparison. The simplest thing to look for is a <threads.h> function which takes fewer arguments than the corresponding <pthreads.h> function.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-06-18 01:57 -0500 |
| Message-ID | <1rq4oahd352lfi0r07fg6l6481o9n7kpek@4ax.com> |
| In reply to | #63459 |
On Wed, 17 Jun 2015 22:44:18 +0200, "Morten W. Petersen" <morphex@gmail.com> wrote: > >For starters I'm going to use threads in the simple ways, to make use >of multiple processors/threading. > >For example with a 21-bit internal representation of Unicode, one >thread can "run ahead" and unpack the characters into 32 bits, >and the main program code can go after and evaluate whatever it >has to evaluate. That's likely to be an unprofitable use of threads. Unless you can do the unpacking in fairly large chunks, the overhead of synchronization and switching between the unpacking and using threads will vastly overwhelm the work being moved to the second thread.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-18 09:29 +0200 |
| Message-ID | <mltrvl$nln$1@speranza.aioe.org> |
| In reply to | #63480 |
On 18.06.2015 08:57, Robert Wessel wrote: > On Wed, 17 Jun 2015 22:44:18 +0200, "Morten W. Petersen" > <morphex@gmail.com> wrote: >> >> For starters I'm going to use threads in the simple ways, to make use >> of multiple processors/threading. >> >> For example with a 21-bit internal representation of Unicode, one >> thread can "run ahead" and unpack the characters into 32 bits, >> and the main program code can go after and evaluate whatever it >> has to evaluate. > > > That's likely to be an unprofitable use of threads. Unless you can do > the unpacking in fairly large chunks, the overhead of synchronization > and switching between the unpacking and using threads will vastly > overwhelm the work being moved to the second thread. OK. My experience with threading comes from Python. But say I have the main program flow, and an extra unpacking thread.. At certain points one can expect to search through what could be substantial amounts of 21-bit characters. What if one updates a table that the thread checks with a pointer to the 21-bit characters and a pointer to the first entry in a malloc'd linked list which represents the unpacked values and the thread work on that? The point isn't to run the program as efficiently as possible, but to make things fast for the external caller that waits for the data. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-17 13:57 -0700 |
| Message-ID | <5c8a1046-f74d-491a-9bc3-d82f77c81f20@googlegroups.com> |
| In reply to | #63453 |
On Wednesday, June 17, 2015 at 8:32:32 PM UTC+1, Ian Collins wrote: > > Windows support for current C has improved somewhat now more of it is in > C++! They do strive for full support of current C++ standards. > > I take the hint and use the language they do support! > They've got an interface protocol called com which is effectively a binary specification of a C++ class mechanism. You can use it from C and I have done so on occasion. However for our curent project, we are using Sciter for the UI. So all the user interface dialogs and panels are written in HTML and a javascript variant called tiscript. I've then written a C++ class to communicate with the rest of the program, so you can pass messages in JSON to and from the dialogs. So most of the OS has been abstracted away.
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web