D http benchmarks
Just sharing https://github.com/tchaloupka/httpbench
Re: extern (c)
On Wednesday, 11 October 2023 at 13:36:16 UTC, Paul wrote: On Wednesday, 11 October 2023 at 12:54:53 UTC, user1234 wrote: `extern(C)` on module level functions affect the mangling and the calling convention. - Mangling is used by the linker to link symbols between objects. - Calling convention affects the compiler backend in how code is generated for a CALL instruction. So C doesn't use name mangling and extern (C) in a D prog would turn off D mangling thereby allowing C and D object files to be linked together? I didn't know C and D had different calling conventions...i.e. different ABI's? https://dlang.org/spec/abi.html
Re: extern (c)
On Wednesday, 11 October 2023 at 13:36:16 UTC, Paul wrote: On Wednesday, 11 October 2023 at 12:54:53 UTC, user1234 wrote: `extern(C)` on module level functions affect the mangling and the calling convention. - Mangling is used by the linker to link symbols between objects. - Calling convention affects the compiler backend in how code is generated for a CALL instruction. So C doesn't use name mangling I see what you mean. I just consider no mangling as a kind of mangling, that is "just the symbol name". and extern (C) in a D prog would turn off D mangling thereby allowing C and D object files to be linked together? I didn't know C and D had different calling conventions...i.e. different ABI's? They are mostly similar but according to https://dlang.org/spec/abi.html#function_calling_conventions there are differences.
Re: extern (c)
On Wednesday, 11 October 2023 at 12:54:53 UTC, user1234 wrote: `extern(C)` on module level functions affect the mangling and the calling convention. - Mangling is used by the linker to link symbols between objects. - Calling convention affects the compiler backend in how code is generated for a CALL instruction. So C doesn't use name mangling and extern (C) in a D prog would turn off D mangling thereby allowing C and D object files to be linked together? I didn't know C and D had different calling conventions...i.e. different ABI's?
Re: extern (c)
On Wednesday, 11 October 2023 at 12:36:58 UTC, Paul wrote: What does the extern (c) attribute(?) do? Does it tell the compiler/linker to build the function like a C compiler would build a C function? If so what does that mean? Does it tell the compiler/linker to let C functions know it exists? If so what does that mean? Is it meant for the compiler or linker or both? Thanks for any assistance. `extern(C)` on module level functions affect the mangling and the calling convention. - Mangling is used by the linker to link symbols between objects. - Calling convention affects the compiler backend in how code is generated for a CALL instruction.
Re: extern (c)
On Wednesday, 11 October 2023 at 12:36:58 UTC, Paul wrote: What does the extern (c) attribute(?) do? Does it tell the compiler/linker to build the function like a C compiler would build a C function? If so what does that mean? Does it tell the compiler/linker to let C functions know it exists? If so what does that mean? Is it meant for the compiler or linker or both? Thanks for any assistance. It is about name mangling. It prevents symbol names from using D's name mangling. https://dlang.org/blog/2017/12/20/ds-newfangled-name-mangling/
extern (c)
What does the extern (c) attribute(?) do? Does it tell the compiler/linker to build the function like a C compiler would build a C function? If so what does that mean? Does it tell the compiler/linker to let C functions know it exists? If so what does that mean? Is it meant for the compiler or linker or both? Thanks for any assistance.
Re: how to assign multiple variables at once by unpacking array?
On Saturday, 7 October 2023 at 07:31:45 UTC, mw wrote:
https://stackoverflow.com/questions/47046850/is-there-any-way-to-assign-multiple-variable-at-once-with-dlang
How to do this Python code in D:
...
...
Is there a better way (since 2017)?
Each programming language has their pros and cons. They all have
their way of solving the problem. A higher level language,
generally, allows you to write less code compared to a lower
level one.
ie - A Python program thats 20 LOC could be 50 LOC in C99 or much
much more.
The downside to (something like) python is that writing less code
has its drawbacks. What does it do in background? Can there be a
huge performance penalty once inside a loop?
D provides you the power of being low level like C, or high level
that can be comparable in a number of ways to C#. I have a choice
to turn off the GC, if I want to!
My response to this is, without sounding rude, who cares about
your example?
- Could D be able to achieve this? Maybe.
- If not, could it in the future? Maybe.
- Would you still have to write an extra line or two compared to
the Python example? Maybe.
You are just splitting a string to 3 variables as ints.
```
s = "1 2 3"
A,B,C = map(int, s.split(" "))
A,B,C
(1, 2, 3)
```
"What if" s has more than 3 numbers?
"What if" s includes characters?
Python will spit out an error - "not enough values" or "invalid
literal"
To build reliable code in your example add more LOC.
I can do this in D. May not be the best example. Is stores them
in int arrays and
handles potentials characters:-
```d
void main()
{
import std.stdio;
import std.array;
import std.string;
import std.algorithm;
import std.conv;
auto s = "1 2 a 3";
auto abc = s.split(' ').map!(s => isNumeric(s) ? s.to!int :
-1);
writeln(abc); // [1, 2, -1, 3]
}
```
I will leave it there.
Re: how to assign multiple variables at once by unpacking array?
On Sunday, 8 October 2023 at 06:02:14 UTC, Jonathan M Davis wrote:
The problem is that the compiler needs to be able to verify
that the types match, and when the return type of a function is
a dynamic array such as int[], it has no way of knowing how
many elements the array has and therefore can't verify at
compile time that the assignment will work. add a runtime check
to verify that the number of elements match, but that's not the
sort of thing that you typically do with a statically typed
language.
I agree.
And solutions like "algebraic types" used by typescript are not
applicable to D (You cant declare int|undefined)
```typescript
const sorted=([first,...xs]:T[]):T[] => first===undefined ?
[] : [
...sorted(xs.filter(x=> x<=first )), first, ...sorted(
xs.filter(x=> x > first))
];
console.log( sorted([1,2,3,4,-1,-2,-3]) );
```
But it should with pattern matching
```D
auto sorted(T)(T[] entries) =>
match(entries) {
case [item, ...others] => ...
otherwise => []
}
```
Or with overloading (patter matching expressions on function
signature... similar to haskell)
```D
auto sorted(T)(T[] [item, ...others]) => ...;
auto sorted(T)(T[] []) => [];
```
Well, not really: because compiler can't predict witch "sorted"
version will be called on compile time. (May be it should be a
syntax suggar of an unique sorted method with match in the body)
However, while there are some benefits to being able to do
this, the response by many programmers from statically typed
languages is that it's cleaner to create a struct for this sort
of thing
I completly agree
, since then the values are contained together, and they have
names associated with them (since they'll be member variables
of the struct). So, while some programmers definitely want
tuple types to be built into D, a number of others don't like
the idea. As such, it's an open question whether we'll ever
have such tuples in D.
Destructuring is only a **Syntax sugar** applicable to well known
types (i.e. Structs). It is not related (exclusively) with
tuples:
The type of a function call (or a parameter) is perfectly known.
Typescript applies destructuring based on type matching (type
members names):
```typescript
type ICounter = {
inc: ()=>void
dec: ()=>void
value: ()=>number
}
function Counter(n:number=0):ICounter {
return {
inc: ()=>{ n++ };
dec: ()=>{ n-- }
value: ()=> n;
}
}
const {inc,value} = Counter();
inc();
inc();
console.assert( value() === 2 );
inc();
console.assert( value() === 3 );
```
It could be portable with Structs in D.
Personally, I found it is specially useful with parameters for
"dependencies injection":
```typescript
function CarsDAO( {db:{ withTransaction }, logger:{ info }}:
IContext ):ICarsDao {
return {
createCar,
updateCar
}
function createCar(data:CarDto):Promise {
info("Lets create a car");
return withTransaction( trx=> trx.executeQuery("insert .
returning key") );
}
}
const context:IContext = {
logger: Singleton(logger),
db: Singleton(Db),
carsDao: Singleton(CarsDao),
}
(async ({ carsDAO:{ createCar }, logger }:IContext)=>{
data:CarDTO = { registration: "ASD1232", model: "Citroën XS" };
const key = await createCar( data )
logger.info( `Car ${key} has been registered`);
})(context);
```
This kind of destructuring is semantically rich.
Note: The "hard" part for this kind of solutions (dependency
injection not based on classes) is the clousures management, and
D solves it magnificently...
Either way, the unpacking of dynamic arrays likely stands no
chance whatsoever of ever being added, > because it would
require runtime checks to determine whether the unpacking was
valid.
This is what pattern matching, some day, at runtime, should solve
:-)
-- Antonio
Re: allocated object address as high as 46th bit (i.e in the 131072 GB range)
The reason high bits are often set is because an address layout is actually 4 indicies into the page table and a page byte offset. So all the way to bit 48 there is index info the cpu uses.
