Invisible <voi### [at] devnull> wrote:
> >    As for increasing the size of the executable, who cares? If the executable
> > gets a few hundreds of bytes larger, big deal.

> Yeah, that's the really puzzling bit. I mean, unless the function is 
> huge [which is a bad idea anyway], or is called from a bazillion places, 
> why would inlining it "bring its own performance costs"? I don't get that.

  In fact, inlining can actually sometimes reduce the size of the executable
(because a function call may be replaced with an expression that gets
calculated at compile time and optimized away).

> >    Anyways, 'inline' should usually only be used for very short functions
> > that are absolutely crucial for speed. Otherwise there's little benefit.

> The book claims that if you write a function body inside a class 
> definition, that makes the method inline. Is this true? I thought there 
> was no difference either way...

  A function definition inside a class definition is implicitly 'inline'
(without having to explicitly use the keyword; you could specify it, but
it would be redundant.)

  Likewise template functions are implicitly 'inline' without having to
explicitly say so.

> Even so, there might be 15^2 function calls, but only at most 15 of them 
> will be /active/ simultaneously - which means only 15 stack frames at 
> once. No?

  You may be right.

> Well, yes. As I understand it, by default C++ doesn't reserve a whole 
> lot of stack space, so you're likely to overflow it quite quickly.

  It depends on the OS. (In most unixes you can actually set how much
stack is given to a process.)

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> orphi@linux-z30b:~/Work/Logic-01> make Test
> g++     Test.cpp   -o Test

  You need to put a "CXXFLAGS=-Wall -O2" in your Makefile. (With Gnu make
that's probably the only think that you need to put there.)

  Of compile it directly with "g++ -Wall -O3 Test.cpp -o Test".

-- 
                                                          - Warp

Post a reply to this message

On 17/04/2012 03:26 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> Now /that/ actually makes sense. Where are these typedefs located? Do
>> you have to include them specifically, or...?
>
>    IIRC they are in<cstdint>.

A quick Google search indicates that cstdint defines std::int8_t, 
std::int16_t and so on, plus uint versions (presumably unsigned). It 
also defines std::int_fast8_t and friends, std::int_least8_t and so on, 
a std::intmax_t and a std::intintptr_t.

>> I had hoped for maybe a compile-time warning. I haven't actually tried
>> it to see if I get one though...
>
>    Some compilers will give you a warning if they think that a variable
> is being used uninitialized, but given that the general problem of
> determining that is unsolvable, it's not fool-proof.
>
>    There are some tools (such as valgrind) that will tell you at runtime.

I may yet end up having to investigate valgrind. It seems it's the only 
reliable way to discover if your code leaks memory...

>> Aren't expressions guaranteed to execute left-to-right?
>
>    Expressions with side-effects can happen in any order. The compiler is
> free to optimize expressions in any way it likes (as long as the result
> is always the same if the expression had no multiple side-effects on the
> same variable).

I see. So that's why programs tend to break if you turn the optimisation 
settings up too high?

>> But that's just it. All C programmers always code in this kind of style.
>> It's part of what makes C so terrifying to try to read.
>
>    C programmers (at least competent ones) do not have multiple side-effects
> on the same variable inside the same expression. They may have multiple
> side-effects on *different* variables, which is ok. For example:
>
>      while(*dest++ = *src++) {}
>
>    There are two side-effects there, but they are operating on different
> variables, so there's no ambiguity.

It still makes my head hurt. >_<

>    What do you think this will print?
>
>      bool b = true;
>      std::cout<<  b<<  std::endl;

Well, I guess now that C++ has /names/ for true and false, I don't have 
to worry about it.

Is bool still regarded as an alias to an integer type? Or does it really 
get treated as a separate, distinct type?

Post a reply to this message

>> why would inlining it "bring its own performance costs"? I don't get that.
>
>    In fact, inlining can actually sometimes reduce the size of the executable
> (because a function call may be replaced with an expression that gets
> calculated at compile time and optimized away).

That's what I figured.

>> The book claims that if you write a function body inside a class
>> definition, that makes the method inline. Is this true? I thought there
>> was no difference either way...
>
>    A function definition inside a class definition is implicitly 'inline'
> (without having to explicitly use the keyword; you could specify it, but
> it would be redundant.)

Hmm, OK. So is it a good idea to include simple accessor methods in a 
header file then? (The book seems to suggest it is.)

>    Likewise template functions are implicitly 'inline' without having to
> explicitly say so.

Well, by definition a template generates a new copy of the function each 
time you use it, no?

>> Even so, there might be 15^2 function calls, but only at most 15 of them
>> will be /active/ simultaneously - which means only 15 stack frames at
>> once. No?
>
>    You may be right.

I usually am. :^)

>> Well, yes. As I understand it, by default C++ doesn't reserve a whole
>> lot of stack space, so you're likely to overflow it quite quickly.
>
>    It depends on the OS. (In most unixes you can actually set how much
> stack is given to a process.)

Yeah, I should think most times you can throw a compiler switch, or ask 
the OS to reserve more at run-time.

PS. I can't believe I just wrote "I usually am". Heh.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >    Likewise template functions are implicitly 'inline' without having to
> > explicitly say so.

> Well, by definition a template generates a new copy of the function each 
> time you use it, no?

  No. A new version is created for each used *type*.

-- 
                                                          - Warp

Post a reply to this message

On 17/04/2012 04:06 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>>>     Likewise template functions are implicitly 'inline' without having to
>>> explicitly say so.
>
>> Well, by definition a template generates a new copy of the function each
>> time you use it, no?
>
>    No. A new version is created for each used *type*.

Oh, I see. I'm still thinking of macro expansion, aren't I? OK.

Post a reply to this message

>> What, you mean like programs involving complex data manipulations?
>> Problems where you want to actually get the correct answer? Problems
>> where you'd like to be able to still understand the code in two years'
>> time? Because, to me, that sounds like a pretty /huge/ problem domain.
>> ;-)
>
> Give a specific example then, of a real commercial problem where
> selecting Haskell would be the best choice. I'm not saying none exist,
> just wondering exactly what type of software problem Haskell would excel
> at. Presumably it's not making a 3D game or an application that is
> mostly GUI.

> In the end companies that are trying to make money will just use
> whichever system lets them solve the problems as quickly as possible.
> This results in all manner of different languages being used (even
> Haskell!). But I think the reason you imagine C++/Java/C# being so
> popular is that the huge markets of software don't match with Haskell.
> Desktop software needs a familiar GUI and easy documented access to
> APIs. Apps for phones need good access to hardware (and usually the OS
> maker has chosen a language for you). Games need high performance and
> good access to hardware APIs.

I think /everybody/ wants to write code which is robust, reliable, 
portable and maintainable. The problem, as you say, is that usually 
getting access to the native resources is usually a highER priority than 
writing beautiful code.

If you release a Windows application which requires you to install GTK 
before it will work, nobody is going to care how beautiful the code is. 
(Except your dev team.) They're all going to think it looks like crap. 
And if you release an application written in low-level C and structured 
like spaghetti, nobody will care as long as it actually works reasonably 
well and it looks nice.

A guess fundamentally, if you write your application in C or C++, then 
you can use any code library that has ever been written, interface with 
any system, do absolutely anything you want. If you write your 
application in Haskell... then in theory you can do the same. In 
reality, it's going to take forever to write bindings to an external 
library, and because the binding is so low-level, you lose most if not 
all of the benefits of Haskell anyway.

If there ever comes a day when Haskell ships out of the door with 
top-quality libraries for doing most or all of the things that a typical 
developer would want to get done, then maybe Haskell will start to 
become popular. I don't see that day being particularly soon.

Post a reply to this message

On 17/04/2012 03:36 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> orphi@linux-z30b:~/Work/Logic-01>  make Test
>> g++     Test.cpp   -o Test
>
>    You need to put a "CXXFLAGS=-Wall -O2" in your Makefile.

OK, /now/ I at least get a warning.

I'm still a bit baffled that this is a valid thing to do, however...

Post a reply to this message

> If there ever comes a day when Haskell ships out of the door with
> top-quality libraries for doing most or all of the things that a typical
> developer would want to get done, then maybe Haskell will start to
> become popular.

The problem is that F# exists already, and I guess you wouldn't call it 
"popular" in the way that you would like Haskell to become.  So Haskell 
would need to become, in some way, superior to F# in order to become 
popular.

Post a reply to this message

On 17/04/2012 04:49 PM, scott wrote:
>> If there ever comes a day when Haskell ships out of the door with
>> top-quality libraries for doing most or all of the things that a typical
>> developer would want to get done, then maybe Haskell will start to
>> become popular.
>
> The problem is that F# exists already, and I guess you wouldn't call it
> "popular" in the way that you would like Haskell to become. So Haskell
> would need to become, in some way, superior to F# in order to become
> popular.

Haskell is /already/ superior to F#. ;-)

For a start, F# is functional in the same way that C++ is 
object-oriented. I.e., not very. F# is a normal OO language with a few 
slightly functional ideas bolted on the side as an afterthought.

But in all seriousness: Haskell will never be popular. Writing clean, 
maintainable code just isn't a high priority. Bashing out code as fast 
as possible is a high priority. Producing six point-releases per 
calendar month is a high priority. Being paid per LoC is a high 
priority. Nobody will ever want to use Haskell.

Still, at least if Haskell shipped with decent libraries, *I* could 
still enjoy using it. :-P

Post a reply to this message