Hacker News new | past | comments | ask | show | jobs | submit | pjmlp's comments login

Given the professional title, in an university approved by the Engineering Order, definitely.

Unfortunately not something with the same value everywhere.


There is no better alternative for Windows and console game development, except C++ Builder and Delphi.

Even Google now ships VS plugins for Android game development and Stadia.


That you have to thank the traditional WinDev vs DevDiv political wars.

As usual the .NET product (XNA), got replaced by a C++ one (DirectXTK).

https://walbourn.github.io/welcome/

They acknowledged they should have behaved better, years later with the new management adding support for MonoGame on the XBox,

https://news.xbox.com/en-us/2016/03/14/letter-chris-charla-i...


You mean 1997?

By 1999 I was already using our own version of mod_tcl and unfortunely fixing exploits every now and then in our native libs called by Tcl.



Looking from the point of view that most people that actually want to do mobile work are using laptops or hybrid devices like Surface clones, they are doing pretty alright.

Sure they lost the mobile phones, but that market has already plateud, newer Android and iOS versions are only gimmicks for those on 2 year contract renewals to change devices.


Consumption on the go world, yes.

Mobile revolution for doing actual work on the go is mostly done in laptops, and Windows is still the champion on that regard.


Including XPC, D-BUS and COM into the picture, which allow for dynamic linking, or if one wants static linking like experience with out-of-process servers, and still there are some issues with it.

Woah there, UNIX only reached academic world after UNIX V6, released in 1975 and its first Assembly version was born in 1969, only being released to the world in 1973.

Yes, SDS from Redis project.

https://github.com/antirez/sds

However the moment you call into other C libraries, they naturally only expect a char *.


I got tired of running into this problem and decided to simply eat the cost of using `char *` in my string library.

And that is why most such efforts eventually die.

WG14 could naturally work into something like SDS for strings and arrays, but of course that is out of their goals to ever do that.


> WG14 could naturally work into something like SDS for strings and arrays, but of course that is out of their goals to ever do that.

Maybe it is, but even if it were, sds strings are a poor choice. I used them extensively in a private project.

1. Typedef'ing `sds` to a pointer type. This leaves no indication to the reader of code that any `sds` typed variable needs an `sdsfree`. IOW, for every other standard type it is clear when the data object needs a `free`, `fclose`, etc. This is a big deal, it's difficult to change the typedef for sds due to the way it returns pointers.

2. Not compatible with current string functions, strike 1: storing binary data in the strings, like the nul character makes it silently lose data when used with current string functions that accept `const char *`. This is a very big deal!

3. Not compatible with current string functions, strike 2: an sds string is only compatible with current string functions that take a `const char *`. This isn't such a big deal (for example, it provides a replacement for `strtok` as the standard `sds` type won't work for `strtok`) but it's unnecessarily incompatible.

4. With the current way it's exposed to a caller, you cannot use `const sds` variables anywhere, which removes a lot of compiler-checking. Trying to use `const` on any sds variable is pointless as you get none of the error-checking.

While sds solves many problems with raw C strings, those problems can be solved by adding standard library functions that work with existing C strings. In addition, it adds a few more problems of its own.


My point regarding WG14 wasn't to add SDS as they are, rather vocabulary types for strings and arrays in the same spirit as SDS.

When they exist as vocabulary types, the ecosystem can rely on their existence and slowly adopt their use, similarly to threads support introduction in C11, for example.


> My point regarding WG14 wasn't to add SDS as they are, rather vocabulary types for strings and arrays in the same spirit as SDS.

Well, yes, I'd love to see some proper string support too, so at least we're in agreement about that :-)

But, overhauling C with additional (memory-safe) array types and string types that are nonetheless still compatible with legacy uses is probably a non-starter anyway. The only way forward would be to add a new type that isn't compatible, which is unpalatable to a lot of people (myself included).

Adding memory-safe functions and/or semantics is easier, but will probably not cover 100% of the memory-safety desired.

> When they exist as vocabulary types, the ecosystem can rely on their existence and slowly adopt their use, similarly to threads support introduction in C11, for example.

Threads, I feel, are a poor example for two reasons: 1) Hardly any code uses the `thread_t` type for a variety of reasons, and 2) There was no need for a `thread_t` type to be backward compatible with anything.


For full memory safety with C the only option are the C Machines, meaning hardware memory tagging.

Already in use for a decade in Solaris SPARC, and eventually mainstream across all variations of ARM CPUs.

Unfortunely Intel botched their MPX implementation and now it is gone.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: