Enlightened
-
@asdf fortunately, I escaped that Korean concentration camp some time ago. Looking at Tizen source brought back some memories...
-
@NeighborhoodButcher Can you maybe explain to me why they insist on not using SSL?
-
@Amihai short answer: they're idiots. Long answer: some Korean manager most likely told them to do it this way, and since Samsung management is modeled after Korean society, nobody was allowed to object, because a manager is always right by definition and good employees should not question any orders, ever.
For example - people were told to allow widgets to fetch any http content. Ok, so now widgets are allowed to fetch http, but not https:
https://review.tizen.org/git/?p=platform/framework/web/wrt.git;a=blob;f=src/view/webkit/injected-bundle/injected_bundle_uri_handling.cpp;h=6ed9810bf9b8af0176c596a605c09b35d6e66dfd;hb=HEAD#l138EDIT: Upon inspection, it turns out the non-TV wrt does not have http explicitly enabled. Now that's a surprise.
-
Just downloaded the official open source package for TVs, and I see Samsung conveniently omitted much code. I wonder how many licenses they break by that.
-
@NeighborhoodButcher does it compile?
-
@NeighborhoodButcher said in Enlightened:
You might also notice how an app is launched. I'm leaving figuring out what's wrong with it as an exercise to the reader (hint: _start, _init...).
A bit late to the party, but ... fuck ... why?
-
@cvi said in Enlightened:
A bit late to the party, but ... fuck ... why?
My best guess is that they've got some great mushrooms in the forests near Seoul…
-
@cvi said in Enlightened:
@NeighborhoodButcher said in Enlightened:
You might also notice how an app is launched. I'm leaving figuring out what's wrong with it as an exercise to the reader (hint: _start, _init...).
A bit late to the party, but ... fuck ... why?
-
@dkf said in Enlightened:
@cvi said in Enlightened:
A bit late to the party, but ... fuck ... why?
My best guess is that they've got some great mushrooms in the forests near Seoul…
At some point you begin to wonder if that shouldn't be a mushroom cloud. And then you realize: North Korea - they're not as evil as you might think!
-
@Greybeard said in Enlightened:
@asdf There's a tag cloud on desktop. Made me wonder if it was Community Server.
It's a modified version of SMF. The URL structure tells me it's SMF with the Pretty URL mod, certain aspects of the design aren't even modified from stock but whatever the mobile thing is, is broken garbage since that is definitely not stock nor any other mod I can think of.
-
@Arantor I bow to the master of forum software identification.
(Okay, so you used to work for them.)
-
Singletons - the Korean way:
template <typename T> class singleton { public: static T * ms_singleton; singleton() { assert(!ms_singleton); long offset = (long) (T*) 1 - (long) (singleton <T>*) (T*) 1; ms_singleton = (T*) ((long) this + offset); } virtual ~singleton() { assert(ms_singleton); ms_singleton = 0; } static T & instance() { assert(ms_singleton); return (*ms_singleton); } static T & Instance() { assert(ms_singleton); return (*ms_singleton); } static T * instance_ptr() { return (ms_singleton); } }; template <typename T> T * singleton <T>::ms_singleton = NULL;
-
-
@RaceProUK said in Enlightened:
(long) (T*) 1 - (long) (singleton <T>*) (T*) 1
So...
0
?I sense black magic pointer arithmetic trying to find the difference between the size of a singleton<T> and a T, or something like that. Possibly a failed attempt.
I believe
(long) (T*) 1
ends up being something likesizeof(T)
, but I don't know what the end result of(singleton <T>*) (T*) 1
is. My C(++) is extremely rusty, and I've never really pulled this kind of hacks anyway.It's entirely possible that you are right at it is zero.
-
@Zecc The first cast in each is a cast to a pointer, and a pointer is always the same size (
size_t
IIRC), no matter what it points to. Now, my C++ is rusty too, but the way I read it, it's twoint
s of value1
that are cast to pointers of value1
, then one is cast to a different pointer of value1
, then they're both cast tolong
of value1
. And unless someone's broken the universe,1 - 1 === 0
;)
-
@NeighborhoodButcher said in Enlightened:
Singletons - the Korean way:
template <typename T> class singleton {
public:
static T * ms_singleton;singleton() { assert(!ms_singleton); long offset = (long) (T*) 1 - (long) (singleton <T>*) (T*) 1; ms_singleton = (T*) ((long) this + offset); } virtual ~singleton() { assert(ms_singleton); ms_singleton = 0; } static T & instance() { assert(ms_singleton); return (*ms_singleton); } static T & Instance() { assert(ms_singleton); return (*ms_singleton); } static T * instance_ptr() { return (ms_singleton); } }; template <typename T> T * singleton <T>::ms_singleton = NULL;
Can you prove this exists or existed in the Tizen codebase?
-
Here we are talking when we could be coding:
Spoiler alert: you are right.
The thing I was thinking about was
(long)( &( ((Foobar*)0) [1] ) )
.
-
-
@RaceProUK said in Enlightened:
a pointer is always the same size (size_t IIRC)
At least in theory, size_t has nothing to do with the pointer size. If you want to do pointer arithmetic, you should use
ptrdiff_t
,uintptr_t
andintptr_t
.
-
@asdf said in Enlightened:
At least in theory, size_t has nothing to do with the pointer size. If you want to do pointer arithmetic, you should use
ptrdiff_t
,uintptr_t
andintptr_t
.size_t
is the type of the size of a memory object, the type of whatsizeof
produces, and what you can pass tomalloc()
. It's unsigned.ptrdiff_t
is the type of the difference between two pointers. It is signed.uintptr_t
andintptr_t
are unsigned/signed integer types that can have a pointer cast into them and back safely, without information loss.- There's also
ssize_t
on some platforms, which is likesize_t
except it also allows-1
(typically as a special marker).
On sane platforms, they're all signed and unsigned integers of the same size as pointers. If you were using Real Mode x86, you'd have to be more careful. Also, you'd need a good drink as the 20-bit addressing scheme it used was madder than a march hare.
-
@NeighborhoodButcher I'm actually surprised that it sometimes doesn't crash when you instantiate it with primitive types.
-
@RaceProUK said in Enlightened:
a pointer is always the same size
Really? I don't think so. Given this declaration:
char *p;
, what issizeof(p)
?16-bit x86: It depends. Compiled in the small or medium model, it's 2. In the large, huge, or compact models, it's 4. (I might have medium and compact reversed.)
Is that pointer-to-data the same size as a pointer-to-function? No, except by coincidence. In particular, in the 16-bit x86 medium and compact models, they are NOT the same size.
Is
int SomeClass::*pSCi;
the same size asint *pi;
? Possibly not, since it must in certain cases carry additional information, and in other cases it might even end up being smaller than a non-member pointer (e.g. 16-bit x86 in a large-data-pointer memory model, wheresize_t
is 16-bits - a pointer-to-data-member can be a simple offset into the class when there is no virtual inheritance going on).In general, if you simply assume that a pointer variable is the size that it is (which is a pretty safe assumption, in general), and you assume nothing else about its size, you'll be better off.
-
@Steve_The_Cynic I'd be very surprised if the size of a pointer changes in the middle of a statement :P
-
@RaceProUK said in Enlightened:
@Steve_The_Cynic I'd be very surprised if the size of a pointer changes in the middle of a statement :P
So would I, as a matter of fact. So yes, you can assume that as well.
-
@Steve_The_Cynic I'd expect pointer-to-method-of-an-instance to end up being larger than most other pointers, as it will have a pointer to the method implementation (i.e., a code pointer) and a pointer to the actual instance (i.e., a data pointer) inside. C++ hides all sorts of shenanigans inside itself...
-
@dkf said in Enlightened:
@Steve_The_Cynic I'd expect pointer-to-method-of-an-instance to end up being larger than most other pointers, as it will have a pointer to the method implementation (i.e., a code pointer) and a pointer to the actual instance (i.e., a data pointer) inside. C++ hides all sorts of shenanigans inside itself...
That's not what pointer-to-member-function is. Given:
void (SomeClass::*pMFSC)(int param);
andSomeClass *pSC
, to call the indicated method of*pSC
viapMFSC
and, you need this syntax:pSC->*pMFSC(n);
, that is, you need an object and the pointer. If instead ofpSC
you have simplySomeClass obj;
, the syntax isobj.*pMFSC(n);
. C++ pointers-to-member-function are NOT closures.It will be larger than a normal function pointer, but that is because it must carry additional information to make sure that two different pointers to the same defined-inline member function, created in different compilation units, will compare equal, AND optionally (there are other ways of doing it) that the correct virtual-member override is called if that is appropriate.
-
@dkf said in Enlightened:
On sane platforms, they're all signed and unsigned integers of the same size as pointers.
TIL that in modern C++, the
size_type
of the default allocator (and therefore also thesize_type
of all standard containers) is guaranteed to be the unsigned version of the pointer difference type:Therefore,
size_t
andptrdiff_t
are now more or less guaranteed to be the same size, unless you're dealing with a very weird platform / standard library where the size type of the standard containers is notsize_t
.
-
@Zecc it might be an attempt to circumvent offsets with multiple inheritance when, you know, you want to include your singleton in the middle of the class tree.
-
@NeighborhoodButcher said in Enlightened:
include your singleton in the middle of the class tree
-
@dkf because Koreans.
Also, I'm surprised nobody noticed how many instances of this singleton can be created and what the results are.
-
@NeighborhoodButcher said in Enlightened:
Also, I'm surprised nobody noticed how many instances of this singleton can be created and what the results are.
Now you mention it, I've had another look, and this singleton just... isn't. It's also a massive leaker of memory, even when used properly, since it never actually unallocates memory before nullifying the reference to it.
In fact, the more I look at the code, the more I want to do this:
-
@RaceProUK said in Enlightened:
In fact, the more I look at the code, the more I want to do this:
Friendly tip: stop looking at that code, for your own sanity
-
-
@RaceProUK said in Enlightened:
I had sanity?
Depends on how long you've been working in this industry
-
@NeighborhoodButcher said in Enlightened:
@dkf because Koreans.
Also, I'm surprised nobody noticed how many instances of this singleton can be created and what the results are.
That was the first thing I noticed. I'm still cringing.
There's another singleton class hiding somewhere that's used as a helper class for this one, right? (Oh $deity, I'm going to have nightmares now...)
-
@TimeBandit said in Enlightened:
@RaceProUK said in Enlightened:
I had sanity?
Depends on how long you've been working in this industry
Almost 11 years
-
-
@RaceProUK said in Enlightened:
Almost 11 years
Newby. 25 years on Windows with C/C++.
I maintain my sanity by leaving at 4p (I'm in at 8.), and going off-grid on the weekends to compete with my dog. Those weekends are often 3-days. Thank $deity for unlimited vacation! (I took 32 days last year)
-
-
@RaceProUK said in Enlightened:
@dcon said in Enlightened:
compete with my dog
What do you compete in?
Best avatar photo, obviously!
-
@RaceProUK said in Enlightened:
@dcon said in Enlightened:
compete with my dog
What do you compete in?
Agility. He's now 10 years old and has multiple championships in multiple venues (AKC, ASCA, USDAA). Still competing strong (and loving it).
-
@Onyx said in Enlightened:
Best avatar photo, obviously!
That's my old girl who passed away in 2015 at 16.5y.
-
@dcon said in Enlightened:
@Onyx said in Enlightened:
Best avatar photo, obviously!
That's my old girl who passed away in 2015 at 16.5y.
Awww, damn, that joke seems mean now
-
@Onyx said in Enlightened:
@dcon said in Enlightened:
@Onyx said in Enlightened:
Best avatar photo, obviously!
That's my old girl who passed away in 2015 at 16.5y.
Awww, damn, that joke seems mean now
Nah. She had a good life. And it is obviously the Best Avatar Photo.
-
@Steve_The_Cynic I had a need for bound method pointers in C++, but nope. I found a proposal to add them to the language, but it was off sitting in the long grass.
So instead we have a macro for declaring callback methods which also defines a static trampoline function.
-
I've been doing C for 10 years now. I have seen C++ on occasion, and sometimes people make it look nice and friendly, but I'm convinced it's evil. I'll stick with C where it's safe.
-
@PleegWat said in Enlightened:
I'm convinced it's evil.
It's a language where you can do great things very easily and clearly once you've set up your classes and templates, but where the process of getting those classes and templates right is indeed a trip into the depths of Coding Hell. It's also very inclined to mix things up between the API and the ABI, making long-term support far more problematic than with C, C# or Java.
And C++ remains the
@mikeTheLiarworst of the worst for compilation speed and gnosticity of error messages.
-
@dkf said in Enlightened:
And C++ remains the worst of the worst for compilation speed and gnosticity of error messages.
As one of my co-workers likes to say: The moment GCC's error messages start making sense to you, you'll know you've lost your sanity.
-
@dkf said in Enlightened:
@Steve_The_Cynic I'd expect pointer-to-method-of-an-instance to end up being larger than most other pointers, as it will have a pointer to the method implementation (i.e., a code pointer) and a pointer to the actual instance (i.e., a data pointer) inside. C++ hides all sorts of shenanigans inside itself...
In C and C++, a pointer-to-a-method and a pointer-to-an-instance are exactly the same. The difference is that the second points to somewhere in the .data section or the heap, and the first points to somewhere in the .text section. They are fully interchangeable, though it's
usuallynearly always recommended to avoid trying tricks with that, unless you have a really good reason. (I think I remember reading/hearing that Russian programmers did so with their space program's rocket code, because of the memory limitations they worked under.)The "shenanigans" only occur within the compiler itself and any extra code that it adds to enforce RTTI. The pointers remain the same. Actually, the special
*_cast<>
pointer casts that C++ recommends are simply indications to the compiler that RTTI should be applied to the pointer and its "pointee".Differences in the memory modes (tiny, small, compact, medium, large, huge) in x86 Real Mode (and 16-bit) change only the size of the pointer, but pointers remain the same size across the program (unless specified differently, which takes special syntax, IIRC), so a
char *
, along long *
, afloat *
, and aT*
will all be the same size.The only "pointer" that would produce a different
sizeof()
result would be one statically declared as aT arr[xx]
, where "xx" is a number, because thensizeof(arr)
is actually the size of the entire "arr" array, butsizeof((T*)arr)
==sizeof(&arr[0])
==sizeof(T*)
==sizeof(int*)
.
-
@asdf said in Enlightened:
@dkf said in Enlightened:
And C++ remains the worst of the worst for compilation speed and gnosticity of error messages.
As one of my co-workers likes to say: The moment GCC's error messages start making sense to you, you'll know you've lost your sanity.
I must be insane, because they (mostly) make sense to me.