Am 18.01.2020 um 13:18 schrieb Florian Klämpfl:
Am 18.01.20 um 12:53 schrieb Sven Barth via fpc-devel:
Am 18.01.2020 um 12:46 schrieb Florian Klämpfl:
Am 16.01.20 um 23:22 schrieb J. Gareth Moreton:
Hey everyone,
Maybe I'm being a bit pedantic with this, but must we abide by
C/C++ standards and go by the name __m128 etc. for the 128-bit data
type?
They can be added additionally. After some thinking, I came to the
conclusion we should first go with the same naming C uses (as we do
in every library header meanwhile), on top of this some more
pascalish way can be added.
But these are not library headers. These are going to be base
language types and I don't see a real reason to follow the C
convention here, only because they were the first and other
developers might easily recognize them this way. As mentioned in my
other mail we don't have the name conflict problem that C/C++ faced
when adding these types.
* there is a lot of example code out there for C, and same naming
makes it much easier to use it in FPC. Actually, I encountered this
already when playing with some C examples from SO. Even though I am
very familiar with this topic, I ended up to put the C code into
godbolt to find out which assembler instructions it uses and then I
tried to find the right FPC intrinsics (we don't :(). Lesson learned :)
I don't necessarily mean the intrinsics (though we could still declare
them as e.g. x86_mm_extract_epi32, so that it's clear that A) it's x86
only and B) that they have the same name part as the C examples). But
the type names should be more Pascal like. For day to day use I imagine
most of the intrinsics to be hidden by normal Pascal language code (e.g.
somearray := somessevar calling the corresponding intrinsic). However
the types will be used more (also we can document that these are
equivalent to the corresponding C types). And for those that want C
compatible type names we can always add aliases to the ctypes unit.
* finding a systematic, pascal-like naming scheme is not easy, there
are countless cases to consider
* they are part of the system unit, so they are prone to name clashes
(this is something I were thinking to try: if they could be moved
without too much hazzle into a seperate unit)
But those name clashes are restricted to the System unit which, while
not that small, is still finite. The C/C++ devs had to consider all code
out there due to the missing concept of namespaces.
Regards,
Sven
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
