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

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

Re: C2 Aims to Modernize the C Language

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: C2 Aims to Modernize the C Language David Kleinecke <dkleinecke@gmail.com> - 2018-02-10 12:41 -0800
    Re: C2 Aims to Modernize the C Language Chad <cdalten@gmail.com> - 2018-02-10 13:38 -0800
    Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 00:32 +0100
      Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-10 17:23 -0800
        Re: C2 Aims to Modernize the C Language Anton Shepelev <anton.txt@gmail.com> - 2018-02-11 13:53 +0300
          Re: C2 Aims to Modernize the C Language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-11 13:26 +0000
          Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-11 13:04 -0800
      Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-11 01:34 +0000
        Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-10 17:42 -0800
          Re: C2 Aims to Modernize the C Language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-02-10 17:50 -0800
            Re: C2 Aims to Modernize the C Language fir <profesor.fir@gmail.com> - 2018-02-14 11:54 -0800
              Re: C2 Aims to Modernize the C Language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-02-14 12:14 -0800
        Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 04:48 +0100
          Re: C2 Aims to Modernize the C Language Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-10 22:35 -0700
            Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 13:25 +0100
          Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-11 11:18 +0000
            Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-11 21:57 +0000
              Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-12 14:10 +1300
                Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 11:11 +0000
                  Re: C2 Aims to Modernize the C Language Reinhardt Behm <rbehm@hushmail.com> - 2018-02-12 20:33 +0800
                    Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 13:43 +0000
                      Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-12 06:05 -0800
                  Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-13 07:13 +1300
                    Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 01:17 +0000
                      Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 09:55 +0100
                        Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-13 12:28 -0600
                          Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-14 11:36 +1300
                            Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-14 00:59 +0000
                              Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-14 15:19 +1300
                                Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-14 14:07 +0000
                                  Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-03-06 15:46 +0000
                            Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-13 20:31 -0600
                              Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-14 15:42 +1300
                                Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-14 01:13 -0600
                                Re: C2 Aims to Modernize the C Language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-21 15:13 +0000
                                  Re: C2 Aims to Modernize the C Language supercat@casperkitty.com - 2018-02-21 08:43 -0800
                                    Re: C2 Aims to Modernize the C Language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-21 19:21 +0000
                                  Re: C2 Aims to Modernize the C Language Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 12:25 -0600
                                    Re: C2 Aims to Modernize the C Language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-21 19:28 +0000
                                      Re: C2 Aims to Modernize the C Language Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 18:29 -0600
                                  Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-22 08:33 +1300
                              Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-14 14:48 +0000
                                Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-14 11:54 -0600
                        Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 20:41 +0000
            Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 00:00 +0100
              Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 00:59 +0000
                Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 12:29 +0100
                  Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 12:18 +0000
                    Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-12 15:27 +0100
                      Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 15:19 +0000
                        Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-12 16:49 +0100
                          Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 17:16 +0000
                            Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-13 07:30 +1300
                            Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-12 22:37 +0100
                              Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 22:15 +0000
                                Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-13 17:05 +1300
                                  Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 11:11 +0000
                                Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 10:32 +0100
                                  Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 11:10 +0000
                                    Re: C2 Aims to Modernize the C Language gordonb.5itdn@burditt.org (Gordon Burditt) - 2018-02-14 12:57 -0600
                                      Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-14 20:29 +0000
                                        Re: C2 Aims to Modernize the C Language gordonb.nrdl0@burditt.org (Gordon Burditt) - 2018-02-14 19:22 -0600
                                          Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-15 14:59 +0000
                                  Re: C2 Aims to Modernize the C Language already5chosen@yahoo.com - 2018-02-13 04:00 -0800
                                    Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 14:46 +0100
                                      Re: C2 Aims to Modernize the C Language already5chosen@yahoo.com - 2018-02-13 08:49 -0800
                                        Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-13 09:52 -0800
                                  Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-13 13:47 +0100
                                    Re: C2 Aims to Modernize the C Language already5chosen@yahoo.com - 2018-02-13 05:11 -0800
                                      Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 14:49 +0100
                                        Re: C2 Aims to Modernize the C Language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-13 21:52 +0800
                                        Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 14:45 +0000
                                        Re: C2 Aims to Modernize the C Language Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-13 07:45 -0800
                                    Re: C2 Aims to Modernize the C Language Chad <cdalten@gmail.com> - 2018-02-13 05:35 -0800
                                  Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 13:21 +0000
                                    Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 13:24 +0000
                    Re: C2 Aims to Modernize the C Language Egor <egor@ruby.local> - 2018-02-13 13:14 +0200
                      Re: C2 Aims to Modernize the C Language already5chosen@yahoo.com - 2018-02-13 04:38 -0800
                        Re: C2 Aims to Modernize the C Language Egor <egor@ruby.local> - 2018-02-14 13:25 +0200
                      Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 13:39 +0000
                        Re: C2 Aims to Modernize the C Language Egor <egor@ruby.local> - 2018-02-14 13:42 +0200
      Re: C2 Aims to Modernize the C Language supercat@casperkitty.com - 2018-02-15 13:17 -0800
    Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 04:41 +0100
    Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-12 17:25 +0100
      Re: C2 Aims to Modernize the C Language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-12 17:28 +0000
        Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-12 21:01 +0100
      Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 17:51 +0000
        Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 19:28 +0100
          Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 20:02 +0000
            Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 23:32 +0100
              Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 10:42 +0100
                Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-13 13:26 +0100
                  Re: C2 Aims to Modernize the C Language Richard Damon <Richard@Damon-Family.org> - 2018-02-13 08:06 -0500
                    Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-13 15:16 +0100
                  Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 14:53 +0100
                    Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-13 15:22 -0600
          Re: C2 Aims to Modernize the C Language Keith Thompson <kst-u@mib.org> - 2018-02-12 12:26 -0800
            Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 23:45 +0100
            Re: C2 Aims to Modernize the C Language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-02-12 15:52 -0800
              Re: C2 Aims to Modernize the C Language Chad <cdalten@gmail.com> - 2018-02-12 17:13 -0800
        Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-12 21:15 +0100
          Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 21:42 +0000
            Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-12 23:21 +0100

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

#126703

On 14/02/2018 18:57, Gordon Burditt wrote:
>> Writing from scratch is easy. The problem is interfacing with APIs
>> written in another language, where not really designed to be used from
>> another.
> 
> It's very easy to write a C program that will give you the size,
> signedness, and on some compilers alignment of a C typedef or
> built-in type on the platform you are running it on.

This is what I sometimes resort to doing. Below is the output of such a 
program giving the sizes of certain WinAPI structs for 32-bit Windows. 
Another test is for 64 bits. This is so I can check the duplicate 
structs I create are at least the size they are supposed to be.

What I object to is this:

* I need to sometimes resort to writing programs to extract this kind of 
information

* I need to sometimes use programs like cdecl to understand certain type 
specs

* I need to sometimes run a C compiler with -E to unscramble a complex 
declaration (and even that might only be a snapshot of what it might be 
due to conditional dependencies; this applies to the above too).

This doesn't really bode well for what is regarded in this group as a 
universal interface description language - mainly by people who use that 
language heavily. It should be clear enough without having to run 
special tools.

And if using a library from a different language, I don't want to have 
to acquire or run a compiler for the language at all.

If you wanted to use, in C, a binary library written in Fortran, say, 
with a description of the functions given in Fortran notation, do you 
really want to have to locate, download, install and learn to use a 
Fortran system just to make sense of the interface?

And in the end it turns out that function just takes 2 32-bit signed 
ints and returns a 32-bit float; why didn't they say so in the first place!

That's exactly what people are saying about C libraries: they want to 
force the language on people who might not be interested in having 
anything to do with it.

> Or, you could make a collection of *ALL* of the built-in C types
> and typedefs you are likely to run in to (even if not all of them
> are defined by C standards, you'll run into POSIX, UNIX, and various
> other types also), and have the program spit out a complete list
> of them on any new platform you encounter.  (Granted, it may take
> some work to figure out at compile time if and where something like
> dev_t or ino_t or goat_t is defined.)  Or just keep adding them as
> you run into them.

Or, maybe, people could just use short and int; or int16_t and int32_t. 
Or, if a type will depend on the platform, a denotation created just for 
that purpose. Not invent a new typedef for each of thousands of struct 
members or function parameters.

-------------------------------

-- 32 BITS
BOOL 4
WORD 2
INT 4
INPUT_RECORD 20
WCHAR 2
DWORD 4
HWND 4
UINT 4
CHAR 1
KEY_EVENT_RECORD 16
WPARAM 4
LPARAM 4
SCROLLINFO 28
SCROLLBARINFO 60
COLORREF 4
LOGPALETTE 8
PALETTEENTRY 4
PALETTEENTRY 4
BITMAP 24
BITMAPCOREHEADER 12
BITMAPCOREINFO 16
BITMAPFILEHEADER 14
BITMAPINFO 44
BITMAPINFOHEADER 40
BITMAPV4HEADER 108
BITMAPV5HEADER 124
BLENDFUNCTION 4
DIBSECTION 84
RGBQUAD 4
RGBTRIPLE 3
SIZE 8
LPSIZE 4
TRIVERTEX 16
RGNDATA 36
RGNDATAHEADER 32
PAINTSTRUCT 64
LOGBRUSH 12
ABC 12
ABCFLOAT 12
ENUMLOGFONT 156
TEXTMETRIC 56
NEWTEXTMETRIC 72
LOGFONT 60
EXTLOGFONT 192
EXTLOGPEN 28
LOGPEN 16
MSG 28
CHAR_INFO 4
CONSOLE_CURSOR_INFO 8
CONSOLE_FONT_INFO 8
CONSOLE_SCREEN_BUFFER_INFO 22
INPUT_RECORD 20
KEY_EVENT_RECORD 16
FOCUS_EVENT_RECORD 4
MENU_EVENT_RECORD 4
MOUSE_EVENT_RECORD 16
SMALL_RECT 8
WINDOW_BUFFER_SIZE_RECORD 4
COORD 4
POINT 8
POINTS 4
RECT 16
DISPLAY_DEVICE 424
STARTUPINFO 68
PROCESS_INFORMATION 16
WNDCLASSEX 48
LRESULT 4
OPENFILENAME 88


-- 
bartc

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

#126710

>> It's very easy to write a C program that will give you the size,
>> signedness, and on some compilers alignment of a C typedef or
>> built-in type on the platform you are running it on.
> 
> This is what I sometimes resort to doing. Below is the output of such a 
> program giving the sizes of certain WinAPI structs for 32-bit Windows. 
> Another test is for 64 bits. This is so I can check the duplicate 
> structs I create are at least the size they are supposed to be.
> 
> What I object to is this:
> 
> * I need to sometimes resort to writing programs to extract this kind of 
> information

Who is it you expect to document this information?  The C library author
wrote it in terms of C types, and may never have even heard of the
platform you are now using, because it was invented after s/he/it died?


> * I need to sometimes use programs like cdecl to understand certain type 
> specs

The same thing can be said about fdecl needed to understand certain
FORTRAN type specs, but maybe FORTRAN isn't used enough for someone
to have actually written it yet.  

Ok, I'll concede that things like pointer-to-function declarations
can be confusing, but the size of types isn't what's at issue here.
What really gets confusing is the C function that takes 4 pointers
to callback functions each of which also have callback function
pointers as arguments.

> * I need to sometimes run a C compiler with -E to unscramble a complex 
> declaration (and even that might only be a snapshot of what it might be 
> due to conditional dependencies; this applies to the above too).
> 
> This doesn't really bode well for what is regarded in this group as a 
> universal interface description language - mainly by people who use that 
> language heavily. It should be clear enough without having to run 
> special tools.

C types are NOT a universal interface description language - the
lack of ability to describe byte endianness and bit endianness
(There are 20.9 trillion (16!) possible bit-endiannesses for a
16-bit integer, not 2) for one, and although IEEE has standardized
a number of floating point formats, things like exponent range and
number of significant bits or digits cannot be described independently.
 
> And if using a library from a different language, I don't want to have 
Using or *writing*?
> to acquire or run a compiler for the language at all.
Are the two languages referred to in that sentence the same language
or different ones?

If the two have to interface with each other (e.g. the different-language
library does some kind of I/O, and the system library in C is all
that is provided for OS interface, then the two have to be able to
talk to each other, or use a third library to mediate the differences.

> If you wanted to use, in C, a binary library written in Fortran, say, 
> with a description of the functions given in Fortran notation, do you 
> really want to have to locate, download, install and learn to use a 
> Fortran system just to make sense of the interface?

Question:  what is the size of an integer in FORTRAN (as in INTEGER I,J 
not INTEGER*3.141592 I,J) ?  Is your answer platform-independent
between 8086 MS-DOS and the latest 64-bit machines running Linux,
Windows 10, or FreeBSD?

From the experience I've had with FORTRAN, which is not very recent,
FORTRAN libraries are loaded with references to run-time routines
which are not portable between FORTRAN compilers of different
vintage.  So in order to use that library *AT ALL* (even from
FORTRAN), you at least need the FORTRAN run-time package.  The same
applies to stuff written in C.  Lose the C shared library, say, to
a bad disk sector, and unless critical programs are linked static,
the system won't boot to a point where you can try to restore it
from a backup.

This is also true of C, especially when floating point either
has to be implemented in software, or for math operations that are
not provided by the instruction set and the compiler does not expand
these inline every time, e.g. 64 bit * 64 bit multiply giving 64 bit
result on a machine with a hardware multiply 32 * 32 -> 64 and no larger.
(Essentially, the stuff provided in libgcc.a with GCC.)  It is very
easy to end up with 2 C compilers on the same machine, where neither
recognizes the other's object output as anything but unrecognizable
garbage.  I seem to recall that happened under MS-DOS where both C
compilers in question were from the same vendor (Microsoft).

FORTRAN also had a way of munging symbols in a way that was different
from C.  C stuck underscores on the beginning of the symbol (true of
early C compilers but not of recent GCC or Clang) and FORTRAN stuck
underscores on the end of the symbol.  Therefore, unless the symbol
was of the form _symbol_, you couldn't call it from both FORTRAN and C
without an intermediate wrapper routine.  As I recall, the FORTRAN
libraries included hundreds or thousands of these wrapper routines
(roughly, one per exported symbol in the C library, except some of
them were more complicated and translated a FORTRAN file handle into
a C file descriptor as part of the translation).

> And in the end it turns out that function just takes 2 32-bit signed 
> ints and returns a 32-bit float; why didn't they say so in the first place!

Because it's probably NOT TRUE, unless you limit the discussion to
the particular platform you are using.



> That's exactly what people are saying about C libraries: they want to 
> force the language on people who might not be interested in having 
> anything to do with it.

What they *WANT* doesn't create an obligation on the part of
someone else to provide it.

Well, lots of standards are written in English, and many people
don't want to have anything to do with English, but unless they
can find a translation, they're stuck with it.  And I don't think
it's because someone is trying to force English on people.

>> Or, you could make a collection of *ALL* of the built-in C types
>> and typedefs you are likely to run in to (even if not all of them
>> are defined by C standards, you'll run into POSIX, UNIX, and various
>> other types also), and have the program spit out a complete list
>> of them on any new platform you encounter.  (Granted, it may take
>> some work to figure out at compile time if and where something like
>> dev_t or ino_t or goat_t is defined.)  Or just keep adding them as
>> you run into them.
> 
> Or, maybe, people could just use short and int; or int16_t and int32_t. 
> Or, if a type will depend on the platform, a denotation created just for 
> that purpose. Not invent a new typedef for each of thousands of struct 
> members or function parameters.

Speaking of that, who tells people trying to interface C to some
other language whether that argument described as "32-bit signed
integer" is supposed to be an int or a long (on a system where int
and long are both 32-bit signed integers) and which printf format
they are supposed to use to print its value?  (I want it!  I want
it!  I want it!  Scream, stamp feet, threaten to hold breath).

I happen to *LIKE* the idea of making a typedef for various different
entities that might be function arguments, like uid_t, pid_t, gid_t,
dev_t, etc.  Yes, this could be extended into applications and,
except for the problem that POSIX reserved all the names of *_t,
could result in things like order_number_t (Amazon may have to
expand this from 128 bits to 4096 bits), invoice_number_t,
customer_number_t, shoe_size_t, hat_size_t, etc.  One of the big
advantages here is that if you see a need to change one of the
types, the functions that just pass that type around don't need
much in the way of changes, just recompilation, and those that do
can be found by looking for the typedef.  (UNIX UIDs used to be
limited to 8 bits and pid_t s used to fit in a signed short.)

Perhaps it's taking it a bit far to have length_t, area_t, volume_t,
mass_t, and density_t and have the compiler know that when you
multiply two length_t s you get an area_t, so assigning the result
to a length_t is an error.

Imagine that you are working on a library in some language you
invented.  You need to do a lot of memory allocation and deal with
big collections of things.  In Jacob's terminology, part of it is
a "Container Library", except this one is in C, not C++.  What type
do you use for the number of things currently in the container?  It
is both kept internally and is available to the code using the
library as the return value of some function.

You need to support this language on old MS-DOS machines, since
there are so many people in desperate need of it and they'll pay a
lot for it, but using a 64-bit item count when you really can't use
more than 20 bits on this platform will slow things down.  You need
to support this language on 64-bit machines where a user process
can legitimately have way more than 4GB of RAM, so 32 bits isn't
enough.  And then there's the 32-bit machines where a 32-bit item
count is just about right.

Well, the C type that corresponds to this is size_t.  You might not
want to formally use that, but you still probably want different
sizes on the MS-DOS machines and the 64-bit machines.

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

#126730

On 15/02/2018 01:22, Gordon Burditt wrote:
>>> It's very easy to write a C program that will give you the size,
>>> signedness, and on some compilers alignment of a C typedef or
>>> built-in type on the platform you are running it on.
>>
>> This is what I sometimes resort to doing. Below is the output of such a
>> program giving the sizes of certain WinAPI structs for 32-bit Windows.
>> Another test is for 64 bits. This is so I can check the duplicate
>> structs I create are at least the size they are supposed to be.
>>
>> What I object to is this:
>>
>> * I need to sometimes resort to writing programs to extract this kind of
>> information
> 
> Who is it you expect to document this information?  The C library author
> wrote it in terms of C types, and may never have even heard of the
> platform you are now using, because it was invented after s/he/it died?

If a library has been written in C, and is only ever intended to be used 
by other C programs, then that's fair enough. Apart from knowing how to 
use the library, no one has to bother with untangling every detail.

But there are many libraries (ie. precompiled binaries) which provide 
access to OS features, printers, graphics, USB, internet ... which are 
too useful just to limit to other C programs.

They may have been written in C because it is apt for the task, but 
should be available to any language.

Because I've spent decades working with non-standard languages, I 
probably have a different perspective on this. I'm very well aware of 
the problems in using libraries written in other languages, and writing 
functions that I might expect to be used outside my language.

> 
>> * I need to sometimes use programs like cdecl to understand certain type
>> specs
> 
> The same thing can be said about fdecl needed to understand certain
> FORTRAN type specs, but maybe FORTRAN isn't used enough for someone
> to have actually written it yet.

I'm not saying Fortran would be better or worse than C; it's just an 
example of a language that could also introduce its own idiosyncrasies 
into an API description.

>> This doesn't really bode well for what is regarded in this group as a
>> universal interface description language

> C types are NOT a universal interface description language - the
> lack of ability to describe byte endianness and bit endianness
> (There are 20.9 trillion (16!) possible bit-endiannesses for a
> 16-bit integer, not 2) for one, and although IEEE has standardized
> a number of floating point formats, things like exponent range and
> number of significant bits or digits cannot be described independently.
>   
>> And if using a library from a different language, I don't want to have
> Using or *writing*?
>> to acquire or run a compiler for the language at all.
> Are the two languages referred to in that sentence the same language
> or different ones?

Say one language is called C, and the other is called M.

Usually I want to call C functions from M. That is, functions in a 
prebuilt binary (.dll on Windows, or possibly .obj) where the functions 
in that library are described in C source notation. For example in a C 
header file.

> Because it's probably NOT TRUE, unless you limit the discussion to
> the particular platform you are using.

This requires a clarification of the purpose of an API description.

The API may not be the same as what is used by the language itself (eg. 
what's inside a C header file). But in the MSDN docs for Win32, the API 
uses C notation.

Without the link to the language, then the API can solve some of the 
specification problems.

> I happen to *LIKE* the idea of making a typedef for various different
> entities that might be function arguments, like uid_t, pid_t, gid_t,
> dev_t, etc.

It needs language support to do properly (as Ada does), so why bother?

Does C stop you assigning a pid_t to gid_t? No. Does it even help you 
when writing code? Probably not; it sounds more of a hindrance.

> Imagine that you are working on a library in some language you
> invented.  You need to do a lot of memory allocation and deal with
> big collections of things.  In Jacob's terminology, part of it is
> a "Container Library", except this one is in C, not C++.  What type
> do you use for the number of things currently in the container?

int or int64. Or uint or uint64 if your want it signed.

For an int that varies according to machine size, then create a new 
type, but I don't think many like 'size_t'. (My language uses intm and 
wordm, which are signed/unsighed and either 32 or 64 bits.)


-- 
bartc

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

#126652

On Tuesday, February 13, 2018 at 11:32:26 AM UTC+2, David Brown wrote:
> On 12/02/18 23:15, bartc wrote:
> > On 12/02/2018 21:37, David Brown wrote:
> >> On 12/02/18 18:16, bartc wrote:
> > 
> >>> The 32-bit DWORD here is misaligned.
> >>
> >> And whose fault is that?  C's fault - or Microsoft's?
> > 
> > I'm talking about APIs specified in C. They are necessarily outside the
> > language, but the language allows that ambiguity. If padding and
> > alignment don't need to be considered then the DWORD is at offset +0002
> > and it would be correct.
> > 
> > (And actually, on x86, alignment is not crucial. What's crucial is
> > creating an exact duplicate of that struct in an different language.)
> > 
> 
> Alignment is crucial on x86 for performance, 

What century you are living in?
In the 2nd decade of 21st century on x86 non-aligned access to scalar types has 
no penalty when the item does not cross cache line, very small penalty when it does cross cache line, but does not cross page boundary and relative big penalty (but still, no more than, say 1-2 mispredicted branches) when it does cross page boundary.
In practice it means that padding to natural boundary is a pessimization when we talking about medium-large arrays. For small arrays it approximately does not matter.
Moderm ARM and modern Power are approximately the same as modern x86.

> and for correctness in some
> situations (like data shared between cpus, 

Only for atomic primitives. The bulk of data could be happily non-aligned.

> and in SIMD code). 

On Intel - only MMX/SSE. AVX does not care.
On AMD - even SSE can be configured to not care.

> But x86
> cpus can access non-aligned data.
> 
> The problem here is MS's limited foresight when they made 16-bit Windows
> and thought that 16-bit alignment was enough.  The fault lies solely and
> squarely at their door.

In this particular case unaligned field creates problems for less sophisticated users that try to create their own header files directly from MS documentation.
It's certainly not a problem from performance perspective. And it's not a problem for those who use vendor-supplied combo of windows.h + compiler.
But it does illustrate that C is far from ideal language for specification of exact layout of "external" data structures.

Many languages are better than C in that regard. For example, Ada is particularly good.

Of course, even more languages out there are worse than C in that regard, but most of them are never used for this sort of parsing of binary structures.

> 
> The common way to handle structs like this, with non-natural alignment,
> is to specify that it is a packed struct.  Different compilers have
> different ways to declare that (and it would be nice if there were a
> standardised method).
> 
> >> Yes, you made an amazing confusion out of clock_t.
> > 
> > Remind me again what the type was. How hard is it to just stipulate it
> > as int32 or int64 and be done with it. And all those typedefs and macros
> > were real.
> 
> No, we are not going to bring it up again.  Get yourself a proper IDE
> and learn how to use it.  You choose to cripple your productivity and
> come to c.l.c. to cry - it is /your/ problem.  Giving you advice or help
> is pointless when you never take it, in case it spoils your
> opportunities for whining.
> 
> > 
> >> Whose fault is it that there are different kinds of calling
> >> conventions in the Windows world?
> > 
> > Again, this is what you get in APIs. C is not as ideal a universal
> > format for specifying interfaces as you seem to think.
> 
> It is a marvellous format, as long as it is used correctly.  MS does not
> use it sensibly.  But even in Windows, it is better than any alternative
> (when augmented by calling convention specifiers and other MS awkwardness).

It is better than alternatives only because Windows API is very "C-oriented" to start with. Not because C is good at particular task of exact specification of layout of data structures.
One very common example of less than full adequacy of C synatx/semantics are Ethernet datagrams that encapsulate IP datagrams. Their structure can be described in terms of C structures, but not in straight-forward way.

> 
> > 
> >> I have never looked at one of MSVC's header files, and /I/ can make a
> >> solid guess about most of these attributes.  I can also make a good
> >> guess where to find out more details - MS's developer websites, or
> >> just use google.  How is it /possible/ to be so wilfully, stubbornly
> >> and determinedly ignorant as you are?
> > 
> > Listen: YOU use C. YOU can just use:
> > 
> >   #include <windows.h>
> > 
> > and be done with it. It's all done for you (by those 500,000 lines of
> > headers).
> 
> I don't /have/ <windows.h>.  (Not that there is a standard <windows.h>
> file anyway).  I don't do C programming for Windows.  But I don't /need/
> that to understand what that example function declaration does.
> 
> > 
> > When you've written a major application around Win32 API in a C
> > equivalent language without benefit of windows.h, then see if you still
> > think it's easy, and everyone else who disagrees is ignorant.
> > 
> 
> Only a complete moron would try, in this century, to write a major
> application around the Win32 API in C - with or within <windows.h>. 
> It is a stupid choice of language for the job, and programming directly to
> the Win32 API as your main target is a masochistic idea. 

Do you mean *GUI* windows application?
Because for non-GUI it's pretty sane as long as API includes standard C library and, depending on scale of the job, non-crazy even without standard C library. At approximately the same level of sanity as writing similar application to POSIX API.
As to scale, proceeding without standard C library is not crazy at very small scale and at very big scale, but not in the middle, the later case because a job of preparation of you own replacement library would be well-amortized upon large body of the rest of the work. Still, there should be very good reason and I don't see what it can be.

> The Win32 API
> is there to provide a base - you write your widget toolkit or your
> language wrappers on top of it if that is the kind of programming you
> are doing.  Your "major app" is written in an appropriate language -
> C++, C#, Java, Python, whatever - not in C, and not against the raw
> Win32 API.  (The same applies to raw X API programming on *nix.  No sane
> developer does it for anything but tiny little programs.)

Well, doing GUI to Win32 API is, of course, insane, but not quite to the level insanity of building GUI from raw X.

> 
> I certainly never claimed that programming to the Win32 API in C is
> easy.  All I said is that the sample function declaration you gave is
> easy to understand.
> 
> 
> > Oh, and try doing it without the internet.
> 
> Try beating your head against a tree as a method of chopping it down.
> Go on - I'll wait.
> 
> > 
> >>> This from another MS header; what are those _dev_t and _ino_t types:
> >>
> >> Look them up.
> > 
> > We've been through this. It's a hunting exercise trawling sub-headers
> > and subdirectories. Or you have to create a dummy program, and compile
> > with -E to get preprocessed output, and then trawl through /that/ to
> > find out what they are.
> > 
> > That should not be necessary. (And when we discussed it last time, I
> > said it should be possible to use such a library without needing a C
> > compiler. So the -E option is out. And it should not be necessary to
> > dive deep into system headers either. The docs should stand on their own.)
> 
> No one /cares/ what you think "should be necessary" - your perfect
> simple world does not match reality, and it does not match the needs of
> everyone else.
> 
> > 
> >> If you don't understand the point of typedefs, I'd recommend going
> >> back to a beginners course in C programming.
> > 
> > YOU seem incapable of understanding when typedefs are overused.
> > 
> > The first six members of a struct are just simple ints (some mix of 16
> > and 32 bits, I don't recall), and there are FIVE different typedefs?
> > Come on!
> > 
> 
> Why is that a problem?  Honestly, I cannot see why you get so worked up
> about this.
> 
> > You probably think this is good coding:
> > 
> >  typedef struct {
> >      _dayno_t   day;
> >      _monthno_t month;
> >      _yearno_t  year;
> >  } rdate;
> > 
> > Can you even make a guess as to how many bytes such a struct has? Are
> > those even integers?
> 
> Does it matter?  If it does, then "sizeof" will give me the answer.
> 
> Perhaps "_dayno_t" is an enumerated type.  Perhaps these types are small
> types for minimising memory usage (for large arrays, or for small
> embedded systems).  Perhaps they are large types.  Perhaps the types are
> used to make the code more flexible.  If more people used typedefs like
> this, rather than hard-coding "int", "short", etc., then we'd have far
> fewer problems like Y2K or Y2039, and a much easier job porting between
> platforms.
> 
> C's typing system is very weak.  In languages with stronger typing,
> giving these parts a different type would mean that the language (mostly
> at compile time, possibly at run time) can spot mixups between the
> types, and support nice, clear use of these types with automatic
> conversions.  You don't get that in C (except by wrapping in structs),
> but having specific type names can make the source code clearer.
> Knowing that "x" is a "dayno_t" gives you far more useful information
> than knowing it is an "int".
> 
> > 
> > Most people would prefer this:
> > 
> >  typedef struct {
> >      int8_t  day;
> >      int8_t  month;
> >      int16_t year;
> >  } rdate;
> > 
> > Total size, 32 bits. But I guess you're too ignorant to understand why
> > something like this is better.
> 
> /Sometimes/ it is better - sometimes not.  Sometimes unsigned types make
> sense.  Sometimes you want small types like this, sometimes you want
> bigger types that might be faster.  Sometimes you want enumerated types.
>  Sometimes you want stronger types.
> 
> Usually when you think that one method of coding is better, it is
> because you can't see beyond your own navel and imagine why other people
> might do something different.
> 
> > 
> >>> I've been battling with this stuff since the earlier nineties (when I
> >>> first started using C functions).
> >>
> >> You have been battling with it all right - you have never spent five
> >> minutes trying to understand it.  You declared it to be wrong in the
> >> early nineties when you first looked at it, and have spend the next
> >> three decades trying to justify that conclusion to yourself.
> > 
> > Have you ever spent five minutes not doing this stuff with C, C++ or
> > Python, where everyone else has already done all the hard work? Just you
> > and the library, but no ready-made headers, interface files or bindings
> > for your language.
> > 
> 
> In most of my C programming, I write virtually everything in the code.
> I make little use of the C library.  On some of my systems I wrote all
> the startup code - everything from the power-on reset up to the start of
> main().  Yes, I have plenty of experience of working from scratch.

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

#126662

On 13/02/18 13:00, already5chosen@yahoo.com wrote:
> On Tuesday, February 13, 2018 at 11:32:26 AM UTC+2, David Brown
> wrote:
>> On 12/02/18 23:15, bartc wrote:
>>> On 12/02/2018 21:37, David Brown wrote:
>>>> On 12/02/18 18:16, bartc wrote:
>>> 
>>>>> The 32-bit DWORD here is misaligned.
>>>> 
>>>> And whose fault is that?  C's fault - or Microsoft's?
>>> 
>>> I'm talking about APIs specified in C. They are necessarily
>>> outside the language, but the language allows that ambiguity. If
>>> padding and alignment don't need to be considered then the DWORD
>>> is at offset +0002 and it would be correct.
>>> 
>>> (And actually, on x86, alignment is not crucial. What's crucial
>>> is creating an exact duplicate of that struct in an different
>>> language.)
>>> 
>> 
>> Alignment is crucial on x86 for performance,
> 
> What century you are living in? In the 2nd decade of 21st century on
> x86 non-aligned access to scalar types has no penalty when the item
> does not cross cache line, very small penalty when it does cross
> cache line, but does not cross page boundary and relative big penalty
> (but still, no more than, say 1-2 mispredicted branches) when it does
> cross page boundary. 

Crossing cache lines has a penalty - spanning two lines that are not in
cache has a bigger penalty, and spanning two lines where one is in the
cache and the other not has a huge penalty (in comparison to a hit).

Perhaps "crucial" for performance is too strong a word - "relevant" or
"important" would be better, depending on the code in question.

No matter what, getting the correct behaviour is far more important than
getting optimal speed.

> In practice it means that padding to natural
> boundary is a pessimization when we talking about medium-large
> arrays. For small arrays it approximately does not matter. 

Fair enough - if padding is necessary.  Often careful arrangement of
struct members can avoid or reduce the need for padding.

> Moderm ARM
> and modern Power are approximately the same as modern x86.
> 

There are /many/ ARM and Power devices with limited or no support for
accessing misaligned data.

>> and for correctness in some situations (like data shared between
>> cpus,
> 
> Only for atomic primitives. The bulk of data could be happily
> non-aligned.
> 
>> and in SIMD code).
> 
> On Intel - only MMX/SSE. AVX does not care. On AMD - even SSE can be
> configured to not care.

My understanding is that this varies between instructions - I don't know
the details.

> 
>> But x86 cpus can access non-aligned data.
>> 
>> The problem here is MS's limited foresight when they made 16-bit
>> Windows and thought that 16-bit alignment was enough.  The fault
>> lies solely and squarely at their door.
> 
> In this particular case unaligned field creates problems for less
> sophisticated users that try to create their own header files
> directly from MS documentation. It's certainly not a problem from
> performance perspective. And it's not a problem for those who use
> vendor-supplied combo of windows.h + compiler. But it does illustrate
> that C is far from ideal language for specification of exact layout
> of "external" data structures.

C is fine for specifications, but is dependent on the target.  This can
be a limitation for target independent layouts like file structures.  If
you stick to "natural" alignments, it will be portable across almost any
realistic system.  My personal preference is to include all padding
manually (and check the result, using compiler warnings and static
asserts on the expected size of the struct).

> 
> Many languages are better than C in that regard. For example, Ada is
> particularly good.

Ada would be fine, yes.

C is not perfect, but it is good enough for the job.

A key missing feature from C is the ability to specify endianness.

> 
> Of course, even more languages out there are worse than C in that
> regard, but most of them are never used for this sort of parsing of
> binary structures.
> 

<snip>

>> 
>>> 
>>> When you've written a major application around Win32 API in a C 
>>> equivalent language without benefit of windows.h, then see if you
>>> still think it's easy, and everyone else who disagrees is
>>> ignorant.
>>> 
>> 
>> Only a complete moron would try, in this century, to write a major 
>> application around the Win32 API in C - with or within <windows.h>.
>>  It is a stupid choice of language for the job, and programming
>> directly to the Win32 API as your main target is a masochistic
>> idea.
> 
> Do you mean *GUI* windows application? 

Yes - sorry for being imprecise.

> Because for non-GUI it's
> pretty sane as long as API includes standard C library and, depending
> on scale of the job, non-crazy even without standard C library. At
> approximately the same level of sanity as writing similar application
> to POSIX API. As to scale, proceeding without standard C library is
> not crazy at very small scale and at very big scale, but not in the
> middle, the later case because a job of preparation of you own
> replacement library would be well-amortized upon large body of the
> rest of the work. Still, there should be very good reason and I don't
> see what it can be.
> 
>> The Win32 API is there to provide a base - you write your widget
>> toolkit or your language wrappers on top of it if that is the kind
>> of programming you are doing.  Your "major app" is written in an
>> appropriate language - C++, C#, Java, Python, whatever - not in C,
>> and not against the raw Win32 API.  (The same applies to raw X API
>> programming on *nix.  No sane developer does it for anything but
>> tiny little programs.)
> 
> Well, doing GUI to Win32 API is, of course, insane, but not quite to
> the level insanity of building GUI from raw X.
> 

I would hate to have to compare the levels of insanity for GUI
programming in raw X and raw Win32...

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

#126671

On Tuesday, February 13, 2018 at 3:46:16 PM UTC+2, David Brown wrote:
> On 13/02/18 13:00, already5chosen@yahoo.com wrote:
>
> I would hate to have to compare the levels of insanity for GUI
> programming in raw X and raw Win32...
>


Disclaimer: I never wrote Windows GUI app in C with Win32 API and nothing else. But I saw [never read] books that describe how it could be done.

You seem to think that GUI-related stuff of Win32 API is on the same level of abstraction as X. In reality it is on the same level of abstraction as Motif.

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

#126673

On Tuesday, February 13, 2018 at 2:49:21 PM UTC-2, already...@yahoo.com wrote:
> On Tuesday, February 13, 2018 at 3:46:16 PM UTC+2, David Brown wrote:
> > On 13/02/18 13:00, wrote:
> >
> > I would hate to have to compare the levels of insanity for GUI
> > programming in raw X and raw Win32...
> >
> 
> 
> Disclaimer: I never wrote Windows GUI app in C with Win32 API and nothing else. But I saw [never read] books that describe how it could be done.
> 
> You seem to think that GUI-related stuff of Win32 API is on the same level of abstraction as X. In reality it is on the same level of abstraction as Motif.

I have done many GUI programs using the windows API.
The Visual Studio IDE is more customized to work with MFC /ATL(WTL)
that is in C++. For instance, using the dialog resource 
editor the IDE can add entries for windows messages. This will
not work in C. You have to manually add some switch case. 

In windows 7, some new APIs were added. For instance the ribbon
and direct2d. Both APIs are acceded using COM interfaces and 
C++ have some direct representation. I never worked using C in 
this case. The same happens with directx. But it is possible to use C
and COM.


I don't have idea what Microsoft is planning but there are changing
some traditional windows GUI to use the UWP. In my opinion the new 
apps are bad in performance ant interface.

  

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

#126655

On Tue, 13 Feb 2018 10:32:15 +0100
David Brown <david.brown@hesbynett.no> wrote:
 
> Only a complete moron would try, in this century, to write a major
> application around the Win32 API in C - with or within <windows.h>.
> It is a stupid choice of language for the job, and programming
> directly to the Win32 API as your main target is a masochistic idea.
> The Win32 API is there to provide a base - you write your widget
> toolkit or your language wrappers on top of it if that is the kind of
> programming you are doing.  Your "major app" is written in an
> appropriate language - C++, C#, Java, Python, whatever - not in C,
> and not against the raw Win32 API.  (The same applies to raw X API
> programming on *nix.  No sane developer does it for anything but tiny
> little programs.)

I like morons because they can do things that so-called "smart" people
can't do, such as porting GTK+ over the Win32 API. :-)

-- 
GOTHIER Nathan

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

#126657

On Tuesday, February 13, 2018 at 2:49:42 PM UTC+2, GOTHIER Nathan wrote:
> On Tue, 13 Feb 2018 10:32:15 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>  
> > Only a complete moron would try, in this century, to write a major
> > application around the Win32 API in C - with or within <windows.h>.
> > It is a stupid choice of language for the job, and programming
> > directly to the Win32 API as your main target is a masochistic idea.
> > The Win32 API is there to provide a base - you write your widget
> > toolkit or your language wrappers on top of it if that is the kind of
> > programming you are doing.  Your "major app" is written in an
> > appropriate language - C++, C#, Java, Python, whatever - not in C,
> > and not against the raw Win32 API.  (The same applies to raw X API
> > programming on *nix.  No sane developer does it for anything but tiny
> > little programs.)
> 
> I like morons because they can do things that so-called "smart" people
> can't do, such as porting GTK+ over the Win32 API. :-)
> 
> -- 
> GOTHIER Nathan

You got it backward.
The team of dozen or two of smart people that are porting that or another advanced GUI framework to that or another low-level API for the benefit of thousands of developer which, due to their work, would not have to deal with said low-level API are an opposite of morons that David was talking about.

Of course, I can't approve his choice of word. The word 'masochist' that he used in other post looks more appropriate.

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

#126663

On 13/02/18 14:11, already5chosen@yahoo.com wrote:
> On Tuesday, February 13, 2018 at 2:49:42 PM UTC+2, GOTHIER Nathan
> wrote:
>> On Tue, 13 Feb 2018 10:32:15 +0100 David Brown
>> <david.brown@hesbynett.no> wrote:
>> 
>>> Only a complete moron would try, in this century, to write a
>>> major application around the Win32 API in C - with or within
>>> <windows.h>. It is a stupid choice of language for the job, and
>>> programming directly to the Win32 API as your main target is a
>>> masochistic idea. The Win32 API is there to provide a base - you
>>> write your widget toolkit or your language wrappers on top of it
>>> if that is the kind of programming you are doing.  Your "major
>>> app" is written in an appropriate language - C++, C#, Java,
>>> Python, whatever - not in C, and not against the raw Win32 API.
>>> (The same applies to raw X API programming on *nix.  No sane
>>> developer does it for anything but tiny little programs.)
>> 
>> I like morons because they can do things that so-called "smart"
>> people can't do, such as porting GTK+ over the Win32 API. :-)
>> 
>> -- GOTHIER Nathan
> 
> You got it backward. The team of dozen or two of smart people that
> are porting that or another advanced GUI framework to that or another
> low-level API for the benefit of thousands of developer which, due to
> their work, would not have to deal with said low-level API are an
> opposite of morons that David was talking about.

Exactly - as I said, you use the Win32 API (or raw X) as the base to
provide the toolkit, such as GTK+.  You write the /application/ against
GTK+, not Win32.

> 
> Of course, I can't approve his choice of word. The word 'masochist'
> that he used in other post looks more appropriate.
> 

The /decision/ to write a "major application" in C and using the Win32
API directly is moronic.  Willingly writing it is masochistic.  Is that
better wording?

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

#126664

On 13/2/2018 21:49, David Brown wrote:
>
> The /decision/ to write a "major application" in C and using the Win32
> API directly is moronic.  Willingly writing it is masochistic.  Is that
> better wording?

Not if you are *ONLY* developing for Window$. Directly calling WIN32 API 
could speed things up. Not all programs need to be cross-platform.

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

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

#126667

On 13/02/2018 13:49, David Brown wrote:

> Exactly - as I said, you use the Win32 API (or raw X) as the base to
> provide the toolkit, such as GTK+.  You write the /application/ against
> GTK+, not Win32.

Suppose you want to write a library like GTK? And you're not using C or C++.

Even suppose you are using your own language, and want to use GTK rather 
than Win32; GTK is not going to be that much simpler to use than Win32.

I've got a version of GTK installed; it has nearly 600 header files, and 
all in C, to be converted to a form I can use.

The whole thing is also 3000 files in total; even if I did succeed in 
writing a program using GTK, how many of those 3000 files needs to 
accompany it to make it work? It's a complex dependency that doesn't 
happen with Win32 because the latter is already part of Windows.

I still don't think you have the right perspective to appreciate what I 
have to battle with.

-----------------
GTK is a massively complicated library anyway, really a collection of 
other libraries.

One function I picked at random takes a GdkDragContext* parameter (I've 
no idea of the difference between GDK and GTK). That is a pointer to 
this struct:

struct _GdkDragContext {
   GObject parent_instance;

   /*< public >*/

   GdkDragProtocol GSEAL (protocol);

   gboolean GSEAL (is_source);

   GdkWindow *GSEAL (source_window);
   GdkWindow *GSEAL (dest_window);

   GList *GSEAL (targets);
   GdkDragAction GSEAL (actions);
   GdkDragAction GSEAL (suggested_action);
   GdkDragAction GSEAL (action);

   guint32 GSEAL (start_time);

   /*< private >*/

   gpointer GSEAL (windowing_data);
};

Your task is to duplicate this struct in your language.

There are 10,000 lines of GDK headers like this. And 30,000 lines of GTK 
headers. And there are a dozen sub-libraries.

You see the problem?

The real problem of course why people write such big and complicated 
libraries (and those 3000 files/100MB don't even include any source code).

> The /decision/ to write a "major application" in C and using the Win32
> API directly is moronic.  Willingly writing it is masochistic.

Writing the majority of this stuff in a language like C or even C++ I 
consider masochistic. Does GTK sit on on top of Win32? In this case, 
Win32 is doing most of the actual work (creating windows and doing any 
drawing into them); all that's needed is scripting.

However, using scripting, no system exists at present, like DLLs, to 
make such a library available to other languages, not even other 
scripting languages.

In that case I would have kept such a wrapper library to the minimum 
that absolutely needs to be compiled code.

-- 
bartc

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

#126669

On Tuesday, February 13, 2018 at 1:49:47 PM UTC, David Brown wrote:
> On 13/02/18 14:11, already5chosen@yahoo.com wrote:
> > On Tuesday, February 13, 2018 at 2:49:42 PM UTC+2, GOTHIER Nathan
> > wrote:
> >> On Tue, 13 Feb 2018 10:32:15 +0100 David Brown
> >> <david.brown@hesbynett.no> wrote:
> >> 
> >>> Only a complete moron would try, in this century, to write a
> >>> major application around the Win32 API in C - with or within
> >>> <windows.h>. It is a stupid choice of language for the job, and
> >>> programming directly to the Win32 API as your main target is a
> >>> masochistic idea. The Win32 API is there to provide a base - you
> >>> write your widget toolkit or your language wrappers on top of it
> >>> if that is the kind of programming you are doing.  Your "major
> >>> app" is written in an appropriate language - C++, C#, Java,
> >>> Python, whatever - not in C, and not against the raw Win32 API.
> >>> (The same applies to raw X API programming on *nix.  No sane
> >>> developer does it for anything but tiny little programs.)
> >> 
> >> I like morons because they can do things that so-called "smart"
> >> people can't do, such as porting GTK+ over the Win32 API. :-)
> >> 
> >> -- GOTHIER Nathan
> > 
> > You got it backward. The team of dozen or two of smart people that
> > are porting that or another advanced GUI framework to that or another
> > low-level API for the benefit of thousands of developer which, due to
> > their work, would not have to deal with said low-level API are an
> > opposite of morons that David was talking about.
> 
> Exactly - as I said, you use the Win32 API (or raw X) as the base to
> provide the toolkit, such as GTK+.  You write the /application/ against
> GTK+, not Win32.
> 
> > 
> > Of course, I can't approve his choice of word. The word 'masochist'
> > that he used in other post looks more appropriate.
> > 
> 
> The /decision/ to write a "major application" in C and using the Win32
> API directly is moronic.  Willingly writing it is masochistic.  Is that
> better wording?
>
Baby X is written to the Win32 API, in C. But Baby X programs themselves
shouldn't call any windows specific functions.

Baby X isn't intended for major applications, however. It's meant for
getting baby programs with one graphics window and a few buttons or
numerical input spinners up and running quickly. 

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

#126660

On Tuesday, February 13, 2018 at 4:49:42 AM UTC-8, GOTHIER Nathan wrote:
> On Tue, 13 Feb 2018 10:32:15 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>  
> > Only a complete moron would try, in this century, to write a major
> > application around the Win32 API in C - with or within <windows.h>.
> > It is a stupid choice of language for the job, and programming
> > directly to the Win32 API as your main target is a masochistic idea.
> > The Win32 API is there to provide a base - you write your widget
> > toolkit or your language wrappers on top of it if that is the kind of
> > programming you are doing.  Your "major app" is written in an
> > appropriate language - C++, C#, Java, Python, whatever - not in C,
> > and not against the raw Win32 API.  (The same applies to raw X API
> > programming on *nix.  No sane developer does it for anything but tiny
> > little programs.)
> 
> I like morons because they can do things that so-called "smart" people
> can't do, such as porting GTK+ over the Win32 API. :-)
> 
> -- 

None of the developers at my job even tried to write around the WinAPI in C. Instead they used .NET. Sitting on top of that is a specialized version of JavaScript. And from that point, we can write cross platform GUIs using things like Swift and Java.

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

#126658

On 13/02/2018 09:32, David Brown wrote:
> On 12/02/18 23:15, bartc wrote:

>> When you've written a major application around Win32 API in a C
>> equivalent language without benefit of windows.h, then see if you still
>> think it's easy, and everyone else who disagrees is ignorant.
> 
> Only a complete moron would try, in this century,

This was actually last century.

  to write a major
> application around the Win32 API in C - with or within <windows.h>.  It
> is a stupid choice of language for the job, and programming directly to
> the Win32 API as your main target is a masochistic idea.

If you write GUI for Windows, then you need to use APIs such as GUI. 
(Maybe there are some other options provided by MS now; I don't  think 
they're any easier or simpler. I think some require C++; that definitely 
is not easier if your goal to do all this from your own language.)

> The Win32 API
> is there to provide a base - you write your widget toolkit or your
> language wrappers on top of it if that is the kind of programming you
> are doing.

OK. We are talking about WRITING whatever it is that sits on top of 
Win32 API.

>  Your "major app" is written in an appropriate language -
> C++, C#, Java, Python, whatever - not in C, and not against the raw
> Win32 API.

Most of my GUI coding in my 90s apps was written in my add-on scripting 
language. Again, we talking about implementing all the gubbins that 
makes that possible - low-level functions in a low-level language.

We are also talking about implementing the language that is to be used 
to implement the gubbins, that is not the same as the language used to 
express the API.


>> Oh, and try doing it without the internet.
> 
> Try beating your head against a tree as a method of chopping it down.
> Go on - I'll wait.

When start trying to use Windows' API is was around 1992; I didn't have 
internet. And even if I did, the resources available were limited.

But the problems I always go on about regarding C, were there long 
before. Throwing 21st century resources at it doesn't really fix them.

-- 
bartc

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

#126659

On 13/02/2018 13:21, bartc wrote:

> If you write GUI for Windows, then you need to use APIs such as GUI.

... such as GDI.

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

#126651

bartc <bc@freeuk.com> wrote:
> On 12/02/2018 11:29, GOTHIER Nathan wrote:
> You keep saying this. But you don't just call a label:
> 
>    call printf
> 
> There are arguments to be passed, and values to be returned. That 
> information is documented in C terms. The mechanics might be stipulated 
> by the platform, but before that, you need to understand what the 
> parameters are. And that's where C gets in the way.

I can only think of two ways in which C influences ABI design decisions:
1) null-terminated strings
2) caller-cleans for variadic functions. Having variadic callee-cleans
functions is possible, but it's PITA to juggle the stack around before
returning (Also it's easier to mess up the stack, if e.g. too many
arguments are passed)

Many ABI things are done a certain way because of the hardware, not
because "it's defined like that in C". Take for example padding in
structures: it's not there because of C, it's there because it's more
efficient to access aligned words on most architectures, and some even
throw exceptions at you if you access a word at an odd address (e.g.
m68k). Another example: char being up-converted to int when passed to
functions: you can only push words (and not bytes) on many arches
including x86 and PDP-11 (which is what C was originally developed for)

Clearly you don't need C to define the parameters of a function. The
reason why C is usually chosen for documentation of function interface,
is because C is the only low level language that's universally known,
and is very portable.

The major advantage of C over something like C2 is that it uses the
"local convention" for types and ABI. By locking-in your FFI to certain
types, you disregard every program which uses system ABI. Even if i32 is
the usual way to pass integers to a function on *your* system, that
doesn't mean that another system won't use i16 or i64 for that purpose.
C doesn't do this, and so it doesn't have interoperability issues with
other languages.

In short, if it wasn't documented in C, it'd need to be documented
separately for each platform.

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

#126654

On Tuesday, February 13, 2018 at 2:00:43 PM UTC+2, Egor wrote:
> bartc <bc@freeuk.com> wrote:
> > On 12/02/2018 11:29, GOTHIER Nathan wrote:
> > You keep saying this. But you don't just call a label:
> > 
> >    call printf
> > 
> > There are arguments to be passed, and values to be returned. That 
> > information is documented in C terms. The mechanics might be stipulated 
> > by the platform, but before that, you need to understand what the 
> > parameters are. And that's where C gets in the way.
> 
> I can only think of two ways in which C influences ABI design decisions:
> 1) null-terminated strings
> 2) caller-cleans for variadic functions. Having variadic callee-cleans
> functions is possible, but it's PITA to juggle the stack around before
> returning (Also it's easier to mess up the stack, if e.g. too many
> arguments are passed)
> 

It seems like you were exposed to C for too long, Or not exposed enough to other languages.
The biggest C-ism in Windows API is how you pass all arrays, not just strings.
In many (most ?) other languages arrays are passed as descriptors, containing at least, starting address and length, but sometimes other things as well, like offset of sub-array withing bigger array and sometimes even non-unit stride. Also, many other languages have real support for mulch-dimensional arrays. C also has something like that since C99, but Win32 API is in C90.
Everything passed by value is also C-ism, but less blatant than pointers instead of arrays.
Another C-ism is non-automatic memory management, where arrays are either caller-alocated (most of the time) or callee-alocated (rare in Win32 API, but exist), but who is responsible for allocation and de-alloocation has to be specified in docs and up-front.

> Many ABI things are done a certain way because of the hardware, not
> because "it's defined like that in C". Take for example padding in
> structures: it's not there because of C, it's there because it's more
> efficient to access aligned words on most architectures, and some even
> throw exceptions at you if you access a word at an odd address (e.g.
> m68k). Another example: char being up-converted to int when passed to
> functions: you can only push words (and not bytes) on many arches
> including x86 and PDP-11 (which is what C was originally developed for)
> 
> Clearly you don't need C to define the parameters of a function. The
> reason why C is usually chosen for documentation of function interface,
> is because C is the only low level language that's universally known,
> and is very portable.
> 
> The major advantage of C over something like C2 is that it uses the
> "local convention" for types and ABI. By locking-in your FFI to certain
> types, you disregard every program which uses system ABI. Even if i32 is
> the usual way to pass integers to a function on *your* system, that
> doesn't mean that another system won't use i16 or i64 for that purpose.
> C doesn't do this, and so it doesn't have interoperability issues with
> other languages.
> 
> In short, if it wasn't documented in C, it'd need to be documented
> separately for each platform.

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

#126689

already5chosen@yahoo.com wrote:
> It seems like you were exposed to C for too long, Or not exposed enough to other languages.
Not counting VM (java/c#) and interpreted languages, I mostly use
assembly, C and C++, so I guess you have a point.
> The biggest C-ism in Windows API is how you pass all arrays, not just strings.
> In many (most ?) other languages arrays are passed as descriptors, containing at least, starting address and length, but sometimes other things as well, like offset of sub-array withing bigger array and sometimes even non-unit stride. Also, many other languages have real support for mulch-dimensional arrays. C also has something like that since C99, but Win32 API is in C90.
I believe that this is not influenced by C. It's simply the simplest
way to pass arrays. Having an object for describing an array is a pretty
high level concept. I've never seen it done like that in assembly, even
in environments that don't use C as the main language (e.g. DOS and
Megadrive).
> Everything passed by value is also C-ism, but less blatant than pointers instead of arrays.
This is another example of C codifying existing assembly practices.
In aforementioned environments where assembly prevails, it is usual to
pass arguments through registers. Each subroutine documented its inputs
and outputs, along with which registers are clobbered. Most of the time
the inputs were clobbered, because it'd be a waste to save those in
callee, when caller might not need to use the value anymore. This was
effectively pass by value, because caller would restore the original
value of the argument after the return of subroutine.

I'd argue that pass by reference is rarely needed. It only makes sense
to use it when you need to get output from function (use pointers for
that) or when you have something big (array/struct) that you want to
pass to function, but you don't want it to be modified (const *).
I guess in languages where everything is immutable by default, this
would make more sense, but for base types which are smaller or equal to
the size of a pointer, it's just an unnecessary extra layer of
complexity.
> Another C-ism is non-automatic memory management, where arrays are either caller-alocated (most of the time) or callee-alocated (rare in Win32 API, but exist), but who is responsible for allocation and de-alloocation has to be specified in docs and up-front.
Again, this is not a C-ism, this is just simplicity. All that an ABI is
concerned with, is passing arguments in and out of function. It isn't
aware about arrays, since the only way to pass an array is by pointer,
and that gets treated just like any other pointer.

Some objects might need extra cleanup (see c++ destructors) so you can't
have automatic memory management unless you treat pointers of different
types differently. c++ name decoration does this, but it can't be
applied universally as-is, as it encodes information in c++ types.

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

#126661

On 13/02/2018 11:14, Egor wrote:
> bartc <bc@freeuk.com> wrote:

>> There are arguments to be passed, and values to be returned. That
>> information is documented in C terms. The mechanics might be stipulated
>> by the platform, but before that, you need to understand what the
>> parameters are. And that's where C gets in the way.
> 
> I can only think of two ways in which C influences ABI design decisions:
> 1) null-terminated strings
> 2) caller-cleans for variadic functions. Having variadic callee-cleans
> functions is possible, but it's PITA to juggle the stack around before
> returning (Also it's easier to mess up the stack, if e.g. too many
> arguments are passed)
> 
> Many ABI things are done a certain way because of the hardware, not
> because "it's defined like that in C". Take for example padding in
> structures: it's not there because of C, it's there because it's more
> efficient to access aligned words on most architectures, and some even
> throw exceptions at you if you access a word at an odd address (e.g.
> m68k). Another example: char being up-converted to int when passed to
> functions: you can only push words (and not bytes) on many arches
> including x86 and PDP-11 (which is what C was originally developed for)

Formal ABIs are fairly recent. When I first used x86 family 
(8088/86/188) it was a with a data sheet and a soldering iron. There was 
no concept of ABI, only the instruction set.

Even now, out of two compilers I develop for x86, one doesn't use the 
Win64 ABI needed for x64 running Windows; it uses its own. (Yes, that's 
allowed.) It only uses Win64 ABI for calling foreign functions or for 
call-backs.

(My C compiler has to use Win64 ABI because it can't tell what is a 
foreign function and what isn't; it's ALL C functions!)

Anyway, the actual ABI, the recommended mechanics of passing data around 
and what goes into which register, is just part of the story.

If C and a platform ABI are distinct entities, then perhaps library APIs 
can use a neutral scheme related to the ABI, rather than to a specific 
language. Even if the library might have been written in that language.

If a library is written in C, then such a representation could be 
exported by the compiler as it will have all that information.

> Clearly you don't need C to define the parameters of a function. The
> reason why C is usually chosen for documentation of function interface,
> is because C is the only low level language that's universally known,
> and is very portable.

A clearly defined subset of C, minus extraneous typedefs and attributes, 
and obfuscating macros, could also do the job.

But that doesn't happen.

-- 
bartc

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

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

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

csiph-web