Enlightened
-
@neighborhoodbutcher said in Enlightened:
Is anyone registered there to post a link to this topic in a comment?
There were already half a dozen links to here already. I find that anywhere EFL comes up (Slashdot, Ars Technica, etc.), this thread gets linked.
-
@neighborhoodbutcher said in Enlightened:
even despite the fact C, like C++, doesn't have a standardized ABI
Each platform typically does have a standard ABI for that. The lack of standardisation between platforms isn't typically a problem, given the large number of other things that also vary.
-
@bulb said in Enlightened:
you can still be using C++ in the private parts though
Keep your C++ away from my private parts!
Filed under: My private parts originated back when FORTRAN was the hot new thing.
-
@dkf that's only when there's a general consensus, which thankfully, usually is the case within a platform+version. But formally, there is no ABI, so any compiler can just use it's own, so ¯_(ツ)_/¯
-
@neighborhoodbutcher said in Enlightened:
But formally, there is no ABI
The C standard does not define one, but that doesn't mean that there is not a standard for a particular platform. Unless you're claiming that it isn't a standard if it isn't set by a standardisation process at a standards body, and that's the sort of
definition chopping that just irritates everyone.The only platform I'm aware of where there hasn't been a single platform ABI at a time was on some versions of Windows, where key parts of the system were just plain old different between compilers. It made working with Windows much more annoying than it needed to be (e.g., if you had a library, you often had to expose the memory allocator used by the library as a callable set of functions so that client code could match up with it even if it was built with a different compiler). This isn't to say that other platforms didn't change ABI, but you didn't generally have two ABIs in use at once for native applications; everything would be built to use just one at a time (and sometimes there would be compatibility hacks to allow older apps to run).
The ABI/API nasties in C++ tend to be a lot more annoying, especially as the symptoms of breakage are usually that things don't work and the error messages involved are both nothing to do with your code and completely inscrutable. BTDT. :(
-
@dkf you just explained to yourself what I meant. The fact is that the compiler authors are free to do whatever they like. When you don't have a single standardization body, you only get a collection of competing de facto standards per platform, just like in the classic xkcd comic. You can call it
but it still doesn't make it untrue.
-
@dkf I believe gcc does have a bunch of compiler flags and function attributes to specify calling convention per function. Though I'm not sure which platforms they apply to and I don't feel like digging into it.
-
Ok, let's get back to the topic. People on Hacker News point out errors in that C primer stuff. Rasterman and his merry EFL bunch cannot even write a C tutorial, apparently. Which is actually not a surprise given the quality of their work.
-
@neighborhoodbutcher said in Enlightened:
@blakeyrat why in hell would anyone want to learn C nowadays?
FFI. Or WinAPI. Or legacy codebases that are written in C that they now have to work with. There are many possibilities.
-
@gąska in other words, you don't need to unless you have to. Also, using C API doesn't require using C. I've used WinAPI for years and not a single time was programming in C.
-
@gąska said in Enlightened:
Or WinAPI
GitHub - microsoft/cppwinrt: C++/WinRT
C++/WinRT. Contribute to microsoft/cppwinrt development by creating an account on GitHub.
-
@gąska said in Enlightened:
FFI
Family Firm Institute? ... ok.
@gąska said in Enlightened:
Or WinAPI.
.Net does it better.
@gąska said in Enlightened:
Or legacy codebases that are written in C that they now have to work with.
Do they really have to work with it.
@gąska said in Enlightened:
There are many possibilities.
Yes but more people deluding themselves about how much they need a low-level language.
-
And about the primer itself...
#include <stdio.h>This tells the compiler to literally include the stdio.h file into your application. The compiler will find this file in the standard locations to look for include files and literally “paste” it there where the include line is. This file provides some “standard I/O” features, such as
printf().I wonder if they realize this paragraph only makes sense to people who already know C.
The next thing is something every application will have - a
main()function. This function must exist only once in the applicationLike every other function.
because this is the function that is run AS the application.
Depending what exactly you mean by "run" and "application", they're either wrong or even more wrong.
The
main()function always returns anintegervalue, and is given 2 parameters on start.Since it's basic tutorial, I'll let it slide that their poor wording makes it look like every program's main() has 2 parameters.
The next thing that happens is for the code to call a function
printf()with a string “Hello world!\n”. Why the “\n” at the end? This is an “escape”. A way of indicating a special character. In this case this is the newline character. Strings in C can contain some special characters like this, and “\” is used to begin the escaped string.Character. Begins the escaped character. Also, you never say which special character is
\n.You will notice a few things.
If you don't tell me I probably won't.
First lines starting with
#are commands, but don't have a;.This sentence probably mean something. I would be able to tell for sure if it means something if someone told me what "command" and ";" are.
Reality is that you are dealing with a machine. A real modern piece of hardware.
If you're writing C, chances are it's anything but modern.
This table could use a "meaning of instruction meaning" column.
Numbers to a computer normally come in sizes that indicate how many bits they use. The sizes that really matter are:
There's something wrong with every single row of this table. Amazing.
- Will C folks never learn the difference between
charandunsigned char? - It's 2018. Can't we get rid of this stupid "word/dword" thing already and just call it short int?
- Integer is a much broader term than
int. In particular, it encompasses every integer type in the table. - No one uses
longanymore. It shouldn't be included in the list of sizes that matter. - "Long Long Integer" isn't the common term for that. 64-bit integer is.
- I thought it was supposed to be about integer sizes, not all primitive types? (repeat for last 3 rows)
Pointers are also just integers.
Fuck you.
Floats and doubles can encode numbers with “a decimal place”. Like 3.14159.
It's funny because neither float nor double can encode 3.14159 exactly.
Thus both floats and doubles consist of a mantissa and exponent. The mantissa determines the digits of the number and the exponent determines where the decimal place should go.
It's irrelevant to 99.99999999% of programming work. But since you're talking about this already, you could've mentioned somewhere that the digits are binary, not decimal, and thus most decimal fractions can't be represented exactly - this is the one piece of information about floats that absolutely IS relevant to programming work, and you never mention it.
A catch - on ARM systems chars often are unsigned by default.
It really sounds like they're not aware there are three char types in C.
Standard ARM systems are 32 bit, except for very new 64 bit ARM systems
Was it really written recently? Because this sentence is so 2015.
In the end pointers are nothing more than a number saying “go to memory row 2943298 and get me the integer (4 bytes) located there” (if it was a pointer to an integer).
Fun fact: 2943298 isn't aligned to 4 bytes.
The pointer itself just stores the PLACE in memory where you find the data. The data itself is what you get when you de-reference a pointer.
This is the first time they mention this "de-reference" thing. It really feels like this primer is targeted at people who already know C enough that they don't need a primer.
Since pointers are numbers, you can do math on them like any other.
Fuck you.
In general machines like to store these numbers in memory at a place that is aligned to their size.
Oh, so they do know about alignment. Makes the point 3x above even funnier.
Note that in addition to memory, CPUs will have “temporary local registers” that are directly inside the CPU. They do not have addresses. The compiler will use them as temporary scratch space to store data from memory so the CPU can work on it. Different CPU types have different numbers and naming of such registers. ARM CPUs tend to have more registers than x86 for example.
Nothing in this paragraph is useful to C programmers.
When you first see some C code, you likely see some variables and these are stored on the stack. This is a special place in memory for such temporary variables and data. It grows and shrinks as needed
Except it doesn't.
Structs (structured data) are very important and allow C to become rather complex and powerful when it comes to data storage
It's only powerful to people who never coded in anything but C.
A function is a basic unit of execution.
It's like they slap random words together with no regard to whether they make sense or not. Function is an aggregation of statements, and thus cannot be called basic unit.
C provides a host of basic types. The common ones are:
Oh boy, another table!
char A single byte almost always signed except on ARM where it likely is unsigned by default (use signed char explicitly to get signed on ARM)
I love the passive aggressive voice here. I also love the complete disregard of any architecture besides x86 and ARM throughout the whole article.
short 2 bytes together as a short word, signed
You know, it would really help if you explained anywhere in the article what you mean by "word".
struct x A custom defined set of N bytes, broken up into sub-types as per the struct definition of “x”
As usual with C folks, they cannot think of variables as anything else but named bytes somewhere in memory. Abstraction is a word unknown to them.
* z A pointer to type “z”.
They've got it backwards. Most likely because, as usual with C folks, they think of pointers as a special property of some variables, not as types of their own.
So
x = a * b - c / dis unclear as to what you intended.Only if you don't know 2nd grade math.
It is wise to explicitly group like
x = a * ((b - c) / d).They do realize it's semantically different than the previous one, right? Right???
You also have shortcuts like
i = i + 1can bei++.There's a subtle difference in case you use it as part of more complex expression. Of course, the right thing to do is never use either assignments nor increments in complex expressions, but they're C folks so I'm sure they abuse both.
<meaning “is less than”,>meaning “is greater than”,⇐meaning “is less than or equal to” and>=meaning “is greater than or equal to”.That's why you don't write about programming in Word.
Like most languages you will have seen, C can loop with for loops as well as while loops and do while loops.
So their target audience is people who already know how to code, just not in C. They could have scrapped half of the article then.
I'm done for now. Maybe I'll continue tomorrow, maybe I won't.
- Will C folks never learn the difference between
-
@neighborhoodbutcher said in Enlightened:
@gąska in other words, you don't need to unless you have to.
I tend to reply to some posts before reading the entire thread. This was an instance of it.
@neighborhoodbutcher said in Enlightened:
Also, using C API doesn't require using C.
But using C API in languages other than C still requires at least basic knowledge of C.
@blakeyrat said in Enlightened:
@gąska said in Enlightened:
FFI
Family Firm Institute? ... ok.
I know you know what FFI means in this context.
@gąska said in Enlightened:
Or WinAPI.
.Net does it better.
How do I make global hook in .Net?
@gąska said in Enlightened:
Or legacy codebases that are written in C that they now have to work with.
Do they really have to work with it.
They're paid for working with it.
@gąska said in Enlightened:
There are many possibilities.
Yes but more people deluding themselves about how much they need a low-level language.
Many people are deluding themselves about being transgender, but it doesn't make gender dysphoria not real.
-
@gąska said in Enlightened:
I know you know what FFI means in this context.
I honestly did not, and Google brought up Family Firm Institute.
But think what you want.
Maybe if you're trying to communicate thoughts to people you could actually express those thoughts in, you know, words? Just a pro-tip there.
-
@blakeyrat said in Enlightened:
@gąska said in Enlightened:
I know you know what FFI means in this context.
I honestly did not, and Google brought up Family Firm Institute.
I checked on http://isearchfrom.com/ and the first search result for FFI in USA is Foreign Function Interface. Either the site is broken, Google decided you're more of an enterpreneur than a programmer, or you're lying.
Maybe if you're trying to communicate thoughts to people you could actually express those thoughts in, you know, words? Just a pro-tip there.
Where did you get this idea that I was trying to communicate with YOU?
-
@gąska said in Enlightened:
It really feels like this primer is targeted at people who already know C enough that they don't need a primer.
They are
slappingpatting themselves on the backs and pretending the practices they use are not completely wrong.
-
@gąska said in Enlightened:
I checked on http://isearchfrom.com/ and the first search result for FFI in USA is Foreign Function Interface. Either the site is broken, Google decided you're more of an enterpreneur than a programmer, or you're lying.
Now I'm worried of what Google thinks of me, since the first result I got was fatal familial insomnia.
-
@gąska said in Enlightened:
Pointers are also just integers.
[...]
Since pointers are numbers, you can do math on them like any other.EFL makes extensive use of these factoids.
@Gąska said in Enlightened:
So
x = a * b - c / dis unclear as to what you intended.Only if you don't know 2nd grade math.
It is wise to explicitly group like
x = a * ((b - c) / d).They do realize it's semantically different than the previous one, right? Right???
I think that may be their point.
-
@djls45 said in Enlightened:
Since pointers are numbers, you can do math on them like any other.
EFL makes extensive use of these factoids.
On the topic of pointless factoids about C(++) pointer arithmetic:
Whenarrayis a pointer,array[5]means the same as5[array]
becausea[b]means*(a+b)and+is commutative.
-
@Adynathos said in Enlightened:
@djls45 said in Enlightened:
Since pointers are numbers, you can do math on them like any other.
EFL makes extensive use of these factoids.
On the topic of pointless factoids about C(++) pointer arithmetic:
Whenarrayis a pointer,array[5]means the same as5[array]
becausea[b]means*(a+b)and+is commutative.And in the x86 Assembly code I've seen, either the latter form was used or both terms were inside the square brackets.
-
@gąska said in Enlightened:
The next thing is something every application will have - a main() function. This function must exist only once in the application
Like every other function.
Hahaha. No. There are levels of shenanigans that you're ignoring here (of which the most obvious variety involves
static). Remember, we're dealing with C; those sorts of tricks are commonly used.Pointers are also just integers.
Fuck you.
You need to learn to write an OS for an embedded device, something with memory mapped hardware. That'll disabuse you of all sorts of notions of fanciness. Pointers really are (on sane architectures) integers that are interpreted as addresses. All your higher order notions of references and so on are based on that ground truth.
On insane architectures like old 8086 PCs or Crays, pointers are afflicted with shit due to things like memory segments or hardware that can't address anything at granularities less than a word, and all that crap is nasty and nobody wants it any more. The C standard still needs to allow for it, but that's more of an unfortunate legacy rather than anything else. (While a lot of actual hardware still has the word-access restriction, it's often got more hardware to hide the fact, at least when desired. But never assume that
sizeof(int*) == sizeof(char*); that's not guaranteed.)
-
@dkf said in Enlightened:
@gąska said in Enlightened:
The next thing is something every application will have - a main() function. This function must exist only once in the application
Like every other function.
Hahaha. No. There are levels of shenanigans that you're ignoring here (of which the most obvious variety involves
static).You can't have more than one function with external linkage that has the same name, and more than one function with the same name in one compilation unit. It's as much true of main as of any other function.
Pointers are also just integers.
Fuck you.
Pointers really are (on sane architectures) integers that are interpreted as addresses.
They are. But treating them just like any random number is wrong and leads to all kinds of problems - usually it just makes your code impenetrable to outsiders (also yourself in 3 months), leading to extreme unmaintainability, but it's easy to get pointer arithmetic wrong, which leads to all kinds of problems. Actually, two kinds of problem - bad reads and misaligned reads.
On insane architectures like old 8086 PCs or Crays, pointers are afflicted with shit due to things like memory segments or hardware that can't address anything at granularities less than a word, and all that crap is nasty and nobody wants it any more. The C standard still needs to allow for it, but that's more of an unfortunate legacy rather than anything else.
I'm pretty sure C requires each byte to have separate address. Though non-conforming implementations wouldn't surprise me in the least.
But never assume that
sizeof(int*) == sizeof(char*); that's not guaranteed.The standard explicitly says that casting any pointer to char* must yield the address of the first byte of the object pointed to. But see above.
-
@gąska quoted in Enlightened:
char A single byte almost always signed except on ARM where it likely is unsigned by default (use signed char explicitly to get signed on ARM)
Oh fucking hell, that's so stupidly wrong. The default signedness of
chardepends on what the compiler wants to do. The computer itself doesn't care (as it attaches signs to operations, not values).
-
@gąska said in Enlightened:
You can't have more than one function with external linkage that has the same name, and more than one function with the same name in one compilation unit. It's as much true of main as of any other function.
You still have much to learn, grasshopper. The standard linker will only bind each name it manipulates to a single address, but that's very much not the only thing going on and it only really works as you believe when all the libraries you're talking about are static libraries.
I'm pretty sure C requires each byte to have separate address.
And they did; the address format for byte-level addressing on this particular Cray was really a struct with one field being the actual word address, and the other field being the offset within the word. Arguably, more modern computers also do something like this, except that they pretend that the offset within the word is the bottom few bits of the address and you get to pretend that everything is flat.
-
@adynathos said in Enlightened:
@djls45 said in Enlightened:
Since pointers are numbers, you can do math on them like any other.
EFL makes extensive use of these factoids.
On the topic of pointless factoids about C(++) pointer arithmetic:
Whenarrayis a pointer,array[5]means the same as5[array]
becausea[b]means*(a+b)and+is commutative.That's also true when
arrayis an actual, you know, array. You know, because the value of the name of an array is a pointer to the array's first element. (Note to one and all: this is not the same as "an array is [or contains] a pointer to its first element".)
-
@gąska said in Enlightened:
@dkf said in Enlightened:
@gąska said in Enlightened:
The next thing is something every application will have - a main() function. This function must exist only once in the application
Like every other function.
Hahaha. No. There are levels of shenanigans that you're ignoring here (of which the most obvious variety involves
static).You can't have more than one function with external linkage that has the same name, and more than one function with the same name in one compilation unit. It's as much true of main as of any other function.
Even that's not true. Consider MYPROG.EXE which is built for 32-bit Windows, with non-DLL C runtime. It is also statically linked to MYDLL.LIB, the import library for MYDLL.DLL. That DLL, too, is built for 32-bit Windows and non-DLL C runtime. Both contain an external-linkage function called
malloc.The only real specialness about
mainis that calling it explicitly in your code is UB. (The C runtime library's startup code is obviously allowed to callmain, but that might be alternatively done by compiler-generated code in the opening brace ofmainthat calls the CRT initialiser and then continues executing main.)Pointers are also just integers.
Fuck you.
Pointers really are (on sane architectures) integers that are interpreted as addresses.
They are. But treating them just like any random number is wrong and leads to all kinds of problems - usually it just makes your code impenetrable to outsiders (also yourself in 3 months), leading to extreme unmaintainability, but it's easy to get pointer arithmetic wrong, which leads to all kinds of problems. Actually, two kinds of problem - bad reads and misaligned reads.
Misaligned reads are only an actual problem on architectures that enforce alignment checks.
Um.
Including x86, if you set the AC bit in the flags register.
On insane architectures like old 8086 PCs or Crays, pointers are afflicted with shit due to things like memory segments or hardware that can't address anything at granularities less than a word, and all that crap is nasty and nobody wants it any more. The C standard still needs to allow for it, but that's more of an unfortunate legacy rather than anything else.
I'm pretty sure C requires each byte to have separate address. Though non-conforming implementations wouldn't surprise me in the least.
I doubt it's actually required. In fact, the non-requirement of this is why
char *andint *don't have to be the same size. The extra information inchar *is required, if present, so that code that dereferences it can find the correct character. And that information is why casting between unrelated types is (or should be) UB, even if you pass viavoid *.But never assume that
sizeof(int*) == sizeof(char*); that's not guaranteed.The standard explicitly says that casting any pointer to char* must yield the address of the first byte of the object pointed to. But see above.
Yes, it does, but that doesn't mean that the two pointer types have the same size.
char *might have to contain an "offset within targeted memory word" that isn't needed inint *, soint *doesn't have it. That cast fromint *tochar *will create a pointer with an offset of zero.FWIW I have worked with a (non-Cray) machine where each memory location (as seen by assembler code) was 16 bits wide. The assembly language had special instructions for accessing the octet you wanted in an array of octet-sized characters, although the definition on such a machine of "byte" is unclear at the best of times.
-
@blakeyrat said in Enlightened:
People who make that "but what about arcane microcontrollers!!!"
There's nothing particularly "arcane" about ARM. What would you use, instead of C?
-
@gąska said in Enlightened:
@blakeyrat said in Enlightened:
@gąska said in Enlightened:
Or WinAPI.
.Net does it better.
How do I make global hook in .Net?
Hey, look what two seconds of googling nets you!
-
@pie_flavor said in Enlightened:
Hey, look what two seconds of googling nets you!
That's a bit like saying that python/luajit/etc are better than the Win32 API, because those too can load and then call the Win32 API directly (on Windows).
-
@steve_the_cynic said in Enlightened:
@gąska said in Enlightened:
@dkf said in Enlightened:
@gąska said in Enlightened:
The next thing is something every application will have - a main() function. This function must exist only once in the application
Like every other function.
Hahaha. No. There are levels of shenanigans that you're ignoring here (of which the most obvious variety involves
static).You can't have more than one function with external linkage that has the same name, and more than one function with the same name in one compilation unit. It's as much true of main as of any other function.
Even that's not true. Consider MYPROG.EXE which is built for 32-bit Windows, with non-DLL C runtime.
Now we're exiting the realm of C and entering the world of messed up configurations and dependency hell. I don't wish to participate in that discussion. If we're talking about conflicting definitions of C runtime functions, we might as well talk about cosmic rays randomly switching bits in RAM leading to access violations and other fun stuff.
@steve_the_cynic said in Enlightened:
The only real specialness about
mainis that calling it explicitly in your code is UB.It's not - you can call main() in a well-formed program just fine.
@steve_the_cynic said in Enlightened:
Pointers are also just integers.
Fuck you.
Pointers really are (on sane architectures) integers that are interpreted as addresses.
They are. But treating them just like any random number is wrong and leads to all kinds of problems - usually it just makes your code impenetrable to outsiders (also yourself in 3 months), leading to extreme unmaintainability, but it's easy to get pointer arithmetic wrong, which leads to all kinds of problems. Actually, two kinds of problem - bad reads and misaligned reads.
Misaligned reads are only an actual problem on architectures that enforce alignment checks.
They are ALWAYS a problem. Sometimes a correctness problem (on architectures that enforce alignment checks), sometimes "just" a performance problem. Also, obtaining an unaligned pointer is either implementation-defined or undefined behavior, depending on how exactly you've got it - so be wary of optimizing compilers.
@steve_the_cynic said in Enlightened:
On insane architectures like old 8086 PCs or Crays, pointers are afflicted with shit due to things like memory segments or hardware that can't address anything at granularities less than a word, and all that crap is nasty and nobody wants it any more. The C standard still needs to allow for it, but that's more of an unfortunate legacy rather than anything else.
I'm pretty sure C requires each byte to have separate address. Though non-conforming implementations wouldn't surprise me in the least.
I doubt it's actually required.
ISO/IEC 9899:2011 subclause 3.6:
1 byte
addressable unit of data storage large enough to hold any member of the basic character set of the execution environment
2 NOTE 1 It is possible to express the address of each individual byte of an object uniquely.@steve_the_cynic said in Enlightened:
In fact, the non-requirement of this is why
char *andint *don't have to be the same size.That's true. But...
@steve_the_cynic said in Enlightened:
casting between unrelated types is (or should be) UB, even if you pass via
void *....this is false. See 6.3.2.3.1:
A pointer to void may be converted to or from a pointer to any object type. A pointer to any object type may be converted to a pointer to void and back again; the result shall compare equal to the original pointer.
Also related is 6.3.2.3.7:
A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned 68) for the referenced type, the behavior is undefined. Otherwise, when converted back again, the result shall compare equal to the original pointer. When a pointer to an object is converted to a pointer to a character type, the result points to the lowest addressed byte of the object. Successive increments of the result, up to the size of the object, yield pointers to the remaining bytes of the object.
So yes, the sizes of different pointers can be unequal (with some caveats described in 6.2.5.28), and you have to be careful with alignment, but otherwise casting pointers back and forth is perfectly fine. Also, I'm pretty sure C++ is different in this regard, but I'd have to check, and I've reached my daily limit of language lawyering.
-
@pie_flavor said in Enlightened:
[DllImport("user32.dll")]
static extern IntPtr SetWindowsHookEx(int idHook, LowLevelKeyboardProc callback, IntPtr hInstance, uint threadId);Oh look, WinAPI!
-
@pie_flavor also. I find it amusing that the first thing you've found in Google within 2 seconds is a code snippet from Russian hacker.
-
@gordonjcp Rust.
-
@cvi @Gąska Exactly; the stated point was that you need to learn C to use WinAPI, and in fact you do not.
-
-
@dkf There's a library for everything, and libraries are free.
-
@gąska said in Enlightened:
I know you know what FFI means in this context
Well that's great but I have no fucking clue
-
@djls45 said in Enlightened:
@Adynathos said in Enlightened:
@djls45 said in Enlightened:
Since pointers are numbers, you can do math on them like any other.
EFL makes extensive use of these factoids.
On the topic of pointless factoids about C(++) pointer arithmetic:
Whenarrayis a pointer,array[5]means the same as5[array]
becausea[b]means*(a+b)and+is commutative.And in the x86 Assembly code I've seen, either the latter form was used or both terms were inside the square brackets.
I don't think x86 assembly even has a form for
array[5].5[array]could be an access to the 5th member of the array, but it could also be read as5[pstruct], accessing the member at offset 5 in the struct pstruct points to.Generally my assembly knowledge is pretty crappy though, so I may be wrong.
-
@pie_flavor Does rust actually work with microcontrollers? It looks like it generates absolutely huge binaries.
Also, it doesn't look like it's very friendly towards memory management.
-
@pie_flavor said in Enlightened:
Exactly; the stated point was that you need to learn C to use WinAPI, and in fact you do not.
You need to learn enough C to understand the documentation, assuming you're not prepared to blindly copy code from random russian "hackers". That's not a lot of C; still, in the example you posted, you find values, pointers, and function pointers.
-
@dkf said in Enlightened:
Of course, I wouldn't suggest that Enlightenment is a particularly great example of how to do such bindings.
Nor would I. I would, however, say it about GTK.
@neighborhoodbutcher said in Enlightened:
@bulb said in Enlightened:
Well, Enlightenment was not written in 21st century. Its first release predates the C++ standard by a year and it has probably been under development for some time before that.
That doesn't imply it's a good choice today, even if we discard how horribly written it is. The first program loader was written in Fortran, but that doesn't mean we should use it now. It could be used in legacy code (my definition of "bing forced"), but in no way it's a candidate for anything new.
C wouldn't be a good candidate for the new code, but using a well written C framework for it is. We are still using heaps of C libraries that are well tested over the years—or don't have better alternatives (e.g. libxml2 is a piece of crap, but I concluded replacing it with xerces, written in kind of C-with-classes, would not help much). That EFL is horribly written is the important bit.
@neighborhoodbutcher said in Enlightened:
yet the example of Qt shows it's not really a problem, at least not in a general sense.
My experience with Qt bindings is that they are rather a lot more fragile than GTK ones. But then, the main reason is the simple parent-deletes-children memory management compared to GTK's reference-counting, not really the language.
-
@gordonjcp The Rust stdlib gets statically linked in, so it can be run on systems without the Rust runtime. You can remove the stdlib with
#![no_std]and depend onlibcmanually, or you could forego that too and write the whole thing by hand.
See this page: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html
Edit: Oh, you edited. Rust is perfectly friendly towards memory management, what are you talking about? You can pick one of a couple different allocator implementations (jemalloc is one of those things that gets linked in to increase the runtime size since it's the default allocator), it's got the Heap API (still being worked on, but works perfectly as it is), and ausizecan be cast to a*constor*mutjust fine.
-
@jaloopa said in Enlightened:
@gąska said in Enlightened:
I know you know what FFI means in this context
Well that's great but I have no fucking clue
Same. And when I Google it, the first results are Fatal familial insomnia and then the Family Firm Institute. But surely we are lying, because @Gąska's idiot search site tells him so.
-
@jaloopa @heterodox have you tried reading past the very first result? I'm 99% positive it's somewhere on the first page, and it's the only result related to programming.
Could you post screenshots of your result? I wonder how it looks like compared to what I can reproduce.
-
FFI stands for Foreign Function Interface. An FFI describes how functions in a language can be called by functions in another language. Things like Rust's
extern "C" fns, Java's JNI, C#'s P/Invoke, the Python API in C, etc. Commonly confused with calling convention, but calling convention is only one component of an FFI.
-
@bulb said in Enlightened:
I would, however, say it about GTK.
Only if it is a lot better than it used to be. The bindings from C were really annoying back when I used it, but that was admittedly a long time ago now.
-
@pie_flavor said in Enlightened:
write the whole thing by hand
That's pretty much what you do when you're working on an embedded system. There'll be a few little bits of assembly for absolutely critical bits (typically the code to intercept the CPU startup, and some of the interrupt handlers) but the rest you'll write in a higher level language (traditionally C) because writing an OS entirely in assembly really sucks.
-
@gąska said in Enlightened:
Could you post screenshots of your result? I wonder how it looks like compared to what I can reproduce.
Here's what I got, FWIW:
- Fatal Familial Insomnia: 5 search results; first result; 3 of 4 entries in "People also ask"
- Foreign Function Interface: 3 search results; second result (so under "People also ask")
- Family Firm Institute: 1 search result; Infobox on right
- Foreign Financial Institution: 1 search result; 1 of 4 entries in "People also ask"
-
@dkf That's the thing - C sucks balls for most non-trivial tasks, and Rust can do the exact same thing while remaining extremely powerful. Consider Redox.
