Le 14/08/2012 13:11, Warp a écrit :
>> IIRC, C++ does not duplicates the class function members (not even
>> > pointers to them) in each instance. Only the actual class (as 1 pointer)
>> > is stored within each instance. The virtual function is just an index.
>> > The first virtual/inheritance cost a pointer in the class. The next are
>> > free.(in fact, with RTTI, even without inheritance, you might already
>> > have that pointer: so no additional cost)
> But if your class were eg. the size of one pointer, then adding any virtual
> functions would double its size.


Tetracapilli... if you compile with RTTI (default for most, including
gnu), an instance of an empty class is already the size of a pointer: to
the class description.

Adding any virtual function in such case would not increase the size of
the instance.

Also, remember that even if the root class is size of a pointer, its
children can only get the same size or larger. If every layer adds a
pointer, the second layer is already the size of two: one proper, one
from parent field (and a third for RTTI)

Removing RTTI <==> no dynamic_cast<>,... might break some code, yet it's
possible (for tight embedded system, including the Embedded C++ spec,
which are just PITA and was made for very low memory system).
In Embedded C++, there is no multiple inheritance, no C++ cast (neither
down or up), no mutable attribut, no namespace, no exception, no
templates and no stdio.
Usage of EC++ is low, but that's might already be too much. It's kind of
C on very fascist mode.

Post a reply to this message

>> module Foobar (Foo (..), foobar) where
>>
>> data Foo = Foo Int deriving Show
>> data Bar = Bar Int deriving Show
>>
>> foobar :: Foo -> Bar
>> foobar (Foo x) = Bar x
>
> Correct me if I'm wrong, but apart from showing that the standard
> seemingly allows it, how would you use that in a real world scenario?
>
> By exporting foobar, you intend to use it somewhere else in your code,
> right? Which means there's another piece of code somewhere that expects
> to receive something of type bar, without knowing what type bar actually
> is!
>
> How does that work?

Well, you're right in that you cannot write any code which explicitly 
expects Bar. You can pass the result to any function that works with 
/all/ types, or any function that works with any showable type. If the 
module exported some functions that expect Bar as input, you can pass 
the result to them. But you can't write that in a type signature, 
which... yeah, is a bit silly.

My point wasn't so much that this is a something anybody is likely to 
want to do. My point was a counter-example to the "that's obviously 
impossible" argument. It's /not/ impossible at all.

Post a reply to this message

As with any language, my WTF list:

- Unsigned integers have names prefixed with "u", and signed integers 
have no prefix. Except byte, which is the other way around: "byte" and 
"sbyte". WTF?

- The "char" type works with Unicode. Well done. Oh, but wait... It only 
stores 16 bits, and yet Unicode actually requires 24 bits to represent a 
single code-point. So this "Unicode character" only actually covers the 
Basic Multilingual Plane. FAIL!

- "As of C# 2.0, it is also possible to have an array in a structure." 
(Erm, why the HELL would it not be possible to do that before??)

- "x & y" performs a Boolean-OR if the arguments are Bools, and a 
bitwise-OR if they are integers. The same goes for all the other logical 
operators. Except NOT, which has "!x" for Bools and "~x" for integers. WTF?

- "x + y" performs addition. Unless either argument is a string, in 
which case the other is converted to a string as well (if not a string 
already) and the strings are concatenated. Unless both arguments are 
delegates, in which case they are concatenated. (I guess there's a 
/reason/ the Java guys claim that operator overloading is evil!)

- Goto? Seriously? Well, I suppose /technically/ that's not actually a 
WTF...

- Anonymous delegates /and/ lambda functions?

- A delegate is a thing which is called when an event is fired, but an 
event /is/ a delegate?? (In fairness, this is probably a Wikibooks WTF 
rather than anything to do with the design of C#.)

- Extension methods. Just... what??

- A non-generic queue is called Queue, and a generic queue is called 
Queue<T>. And yet, for the other container types, the generic and 
non-generic versions have completely different, unrelated names. (I 
guess that's backwards compatibility for you... oh, wait.)

Post a reply to this message

Le 2012-08-14 04:27, Invisible a écrit :
> Actually, I've never seen Windows 2000 used anywhere, ever. Not in
> people's homes, not in places of work. Indeed, if it weren't for that
> course my employer sent me on, I wouldn't even know it /exists/... It
> never seemed to be really popular.
>

My employer used it on all its desktops and laptops when they upgraded 
from Windows 95.  So from 2000 to 2005, or thereabouts, you had close to 
400,000 users worldwide, in just one company.

My bank also _still_ uses it for the teller PCs.  (I suppose bank 
tellers are a dying breed, so they figured it was not worth it to 
develop a new standard image to be deployed across the country...


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

>>> Valid point. But in a commercial setting, pretty irrelevant.
>>
>> It will become relevant when Microsoft inevitably stops supporting XP.
>>
>> It might not happen next month, or even next year, but the clock is
>> ticking.
>
> What do you mean "when"? This has already happened.
>
> http://en.wikipedia.org/wiki/Windows_XP
>
> "Mainstream support ended 14 April 2009."

Corporate is NOT mainstream.   You can bet your ass off that if Bank Of 
America, HSBC, LuftHansa, or the Deptartment of Defense finds a weird 
problem in XP, they still have ways fo making MS cough up a patch for them.

IBM still unofficially supports OS/2 for the same reason.
-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> Tetracapilli... if you compile with RTTI (default for most, including
> gnu), an instance of an empty class is already the size of a pointer: to
> the class description.

I don't know how to explain this more clearly than I have already done.

If a class has no virtual functions, it will have no vtable pointer.
RTTI has nothing to do with this.

If you have, for example, one int as its member, the size of the class
will be typically 4 bytes.

Now add a virtual function to the class: Suddenly its size is 8 bytes
(16 if compiling a 64-bit binary). The size of the class has doubled
(quadrupled in 64-bit systems).

This is the reason why vtables are added only to classes that have virtual
functions.

> In Embedded C++, there is no multiple inheritance, no C++ cast (neither
> down or up), no mutable attribut, no namespace, no exception, no
> templates and no stdio.

That sounds like a pretty useless C++.

(Why no namespaces or templates? What do those have anything to do with
embedded systems?)

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> - Unsigned integers have names prefixed with "u", and signed integers 
> have no prefix. Except byte, which is the other way around: "byte" and 
> "sbyte". WTF?

Why would you expect bytes to be signed by default?

> - The "char" type works with Unicode. Well done. Oh, but wait... It only 
> stores 16 bits, and yet Unicode actually requires 24 bits to represent a 
> single code-point. So this "Unicode character" only actually covers the 
> Basic Multilingual Plane. FAIL!

I'm assuming it uses UTF-16.

> - "x + y" performs addition. Unless either argument is a string, in 
> which case the other is converted to a string as well (if not a string 
> already) and the strings are concatenated. Unless both arguments are 
> delegates, in which case they are concatenated. (I guess there's a 
> /reason/ the Java guys claim that operator overloading is evil!)

Using operator+ for string concatenation is pretty common. I have never
had any kind of confusion with it. (You would have to come up with a
really artificial example to deliberately make it confusing.)

Automatically converting the right hand side to a string sounds more
dubious to me. Sounds like it may easily be done inadvertently, causing
all kinds of bugs.

-- 
                                                          - Warp

Post a reply to this message

On 14/08/2012 06:38 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> - Unsigned integers have names prefixed with "u", and signed integers
>> have no prefix. Except byte, which is the other way around: "byte" and
>> "sbyte". WTF?
>
> Why would you expect bytes to be signed by default?

I don't know about "default", but a consistent naming scheme would be 
nice...

>> - The "char" type works with Unicode. Well done. Oh, but wait... It only
>> stores 16 bits, and yet Unicode actually requires 24 bits to represent a
>> single code-point. So this "Unicode character" only actually covers the
>> Basic Multilingual Plane. FAIL!
>
> I'm assuming it uses UTF-16.

Perhaps actual /strings/ allow storing all possible Unicode code-points. 
However, char, the type of a single character, apparently covers the BMP 
only. If you're going to go to all the trouble of actually supporting 
Unicode, why not support the whole thing?

> Using operator+ for string concatenation is pretty common. I have never
> had any kind of confusion with it. (You would have to come up with a
> really artificial example to deliberately make it confusing.)
>
> Automatically converting the right hand side to a string sounds more
> dubious to me. Sounds like it may easily be done inadvertently, causing
> all kinds of bugs.

Yeah, sounds like more the sort of thing you'd expect in a scripting 
language.

OTOH, it appears that it's the only autoconversion that can happen.

Pop quiz: if x is a string and y is a delegate, does it do delegate 
concatenation or string concatenation?

Post a reply to this message

Am 14.08.2012 15:12, schrieb Invisible:
>>> So what do you think Haskell solves inelegantly?
>>>
>>> It's no secret that the libraries lack vast swathes of important
>>> functionality, or that some of the build tools leave a lot to be
>>> desired. But the core language itself? It isn't perfect, but it's a
>>> damn-site more elegant than any other programming language I've ever
>>> laid eyes on.
>>
>> That may well be true, and I actually believe it, but as soon as you
>> want to do some serious programming you'll /need/ more than that elegant
>> core; you'll need those libraries of which /you/ yourself said that
>> various of them suck for this and that reason and none of them gives you
>> exactly what you need.
>>
>> An elegant core language may be nice to have, but if as a consequence it
>> takes you ages to get the job done, unless you make use of plenty
>> non-elegant language extensions or libraries, it doesn't /really/
>> qualify as "a simpler, more elegant design that solves everything".
>
> Right. So you're saying the fact that nobody has sat down and written a
> comprehensive set of libraries makes the language "non-elegant" and
> "poorly designed"?

I did not say THAT.

What I did say is that if nobody has sat down and written a 
comprehensive set of libraries, this prevents the lange from being a 
language that "solves everything" - and, consequentially, from 
qualifying as "a simpler, more elegant design that solves everything".

What I also did imply is that if anybody would indeed sit down and write 
a comprehensive cover-all set of libraries, there would likely be quite 
a number of them that would be non-elegant to use; and if those 
libraries would form a part the language's way of "solving everything", 
then THEY would disqualify the combo (core language + libraries) from 
qualifying as that "simpler, more elegant design that solves everything".


> Haskell does not have the rich set of libraries that C# has because it
> wasn't developed by a multi-billion dollar global mega corporation. It
> was developed by three beardy guys in a shed on day. If it ever becomes
> popular, we'll see more libraries being developed for it. If (as seems
> more likely) it never becomes really popular, then we won't. But either
> way, this has nothing to do with whether the language is well-designed
> or not.

Right. But it has something to do with whether the language "solves 
everything" [for practical purposes].

Can you easily model a state machine in Haskell? If not, then it doesn't 
solve everything.

Can you easily write a GUI in Haskell? If not, then it doesn't solve 
everything.

Can you easily write an OS kernel in Haskell? If not, then it doesn't 
solve everything.

Just three things that immediately spring to my mind; I'm sure there's 
gazillions of others out there.

As soon as you have libraries (or other language extensions) for all 
conceivable purposes, we'll talk again - about elegancy then.

Post a reply to this message

Am 14.08.2012 23:06, schrieb Orchid Win7 v1:

> Perhaps actual /strings/ allow storing all possible Unicode code-points.
> However, char, the type of a single character, apparently covers the BMP
> only. If you're going to go to all the trouble of actually supporting
> Unicode, why not support the whole thing?

Do you have any idea what "the whole thing" means in case of Unicode?

Hint: There's more to Unicode than just ~1 million code points with 
glyphs mapped to some of them.


> Pop quiz: if x is a string and y is a delegate, does it do delegate
> concatenation or string concatenation?

Provided it doesn't raise an error, obviously you'll get string 
concatenation, because you can't convert strings to delegates.

Post a reply to this message