> IDEs are only really useful for OO languages.

I do not agree.

> You know, you have a
> variable holding an instance of a class, then you type "." and get a
> list of methods available... no such thing in functional programming
> where the order is reversed: you have a function and want to apply
> arguments to it. You may list arguments that match that function
> definition and you may even know their types (assuming "intellisense"
> got type inference), but most likely you're not directly applying those
> arguments to the function, but applying some other function to it first.
> It sounds too much of hassle to use "intellisense" in those situations...

Did you know that there's a program called Djinn which can take any 
Haskell type signature and generate Haskell source code for it, if it's 
possible to write it without recursion?

Of course, there's usually more than one possible expression for a given 
type signature. So the code you get may well not be the code you 
actually wanted. But still, it's interesting that just a type signature 
is sometimes enough to generate useful, runnable code. (Try doing /that/ 
in a normal programming language...)

> I fear IDEs are really only useful at getting away with lesser
> languages' weaknesses
>
> so, all that would seem to rest of usefulness for an IDE is project
> management.

I do not agree.

Consider the things that a typical IDE does:

- Syntax highlighting. Bracket pairing.

- Generate parts of an expression as you type. (E.g., generate the 
matching close bracket, generate the "then" and "else" keywords when you 
type "if".)

- Highlight any syntax errors, mismatched brackets, unused variables.

- Allow you to compile the whole project with one keypress.

- Highlight the line of source code that the compiler is complaining about.

- Display a summary of what entities are defined in each file, what 
their types are, whether they're public or private, etc.

- Let you navigate to each entity in the list.

- Run the document extraction tool.

- Take you to the documentation for a given entity (regardless of 
whether its in your project or an installed 3rd party library).

- Easily launch your application.

- Run your test suite and log the results.

- Integrate with your source control system. Show interactive diffs. 
Show the history tree. Manage commits and reverts and branches.

- Integrate with the debugger. Let you single-step through your code. 
Let you create watches, inspect variables in scope, drill down through 
complex data structures.

Tell me, how do any of these things stop being useful if your 
programming language isn't object-oriented?

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >    It can be argued using the same logic as with uninitialized variables,
> > though: There are situations where execution never reaches the end of the
> > function, and hence having a 'return' statement there would be useless.

> Sure. But like I said, the Java compiler seems to detect this.

  But the C++ compiler cannot break the standard by making the situation
an error. It can only issue a warning.

  (And besides, any kind of detection of this cannot be 100% accurate,
as the problem "will this line of code ever be reached?" is unsolvable
in the general case.)

-- 
                                                          - Warp

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> The benefit of class over a simple struct/collection is in the
> private/protected parts, and the mandatory centralisation of the
> prototypes of all related functions (until you start playing with
> friend, but that's another story).

  Well, classes also support inheritance and dynamic binding, which
is sometimes useful.

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Hey Warp, you ever think about writing a book? I bet you could do a 
> better job than this idiot...

  There already exist good books.

  If you want to read something actually useful about C++, try the
"Effective" book series by Scott Meyers (or at the very least "Effective
C++" and "More Effective C++"). They actually contain some competent and
easy to understand information.

  "Effetive STL" is probably also good.

-- 
                                                          - Warp

Post a reply to this message

On 18/04/2012 12:13 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>>>     It can be argued using the same logic as with uninitialized variables,
>>> though: There are situations where execution never reaches the end of the
>>> function, and hence having a 'return' statement there would be useless.
>
>> Sure. But like I said, the Java compiler seems to detect this.
>
>    But the C++ compiler cannot break the standard by making the situation
> an error. It can only issue a warning.

Sure. I understand that. The problem is that the standard requires this 
to be permissible. I was just pointing out that "because it's impossible 
to detect" is not a valid reason for the standard being written this 
way. (Backwards compatibility is, of course.)

>    (And besides, any kind of detection of this cannot be 100% accurate,
> as the problem "will this line of code ever be reached?" is unsolvable
> in the general case.)

Sure.

Post a reply to this message

On 18/04/2012 12:17 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> Hey Warp, you ever think about writing a book? I bet you could do a
>> better job than this idiot...
>
>    There already exist good books.

Well, I guess.

>    If you want to read something actually useful about C++, try the
> "Effective" book series by Scott Meyers (or at the very least "Effective
> C++" and "More Effective C++"). They actually contain some competent and
> easy to understand information.
>
>    "Effetive STL" is probably also good.

Noted.

(Basically the only reason I'm persisting with this poorly written and 
probably outdated text is that we've already bought it. But I'm thinking 
it might be better to just save myself the trouble and go read a real 
explanation...)

Post a reply to this message

Invisible escreveu:
>> IDEs are only really useful for OO languages.
> 
> I do not agree.
> 
>> You know, you have a
>> variable holding an instance of a class, then you type "." and get a
>> list of methods available... no such thing in functional programming
>> where the order is reversed: you have a function and want to apply
>> arguments to it. You may list arguments that match that function
>> definition and you may even know their types (assuming "intellisense"
>> got type inference), but most likely you're not directly applying those
>> arguments to the function, but applying some other function to it first.
>> It sounds too much of hassle to use "intellisense" in those situations...
> 
> Did you know that there's a program called Djinn which can take any 
> Haskell type signature and generate Haskell source code for it, if it's 
> possible to write it without recursion?
> 
> Of course, there's usually more than one possible expression for a given 
> type signature. So the code you get may well not be the code you 
> actually wanted. But still, it's interesting that just a type signature 
> is sometimes enough to generate useful, runnable code. (Try doing /that/ 
> in a normal programming language...)

AFAIK, the hindley-milner type system is turing complete, so it's not 
surprising at all.  So, if you want you may indeed just provide 
mind-boggling complex types and let djinn extract the program behaviour 
from that, just as a C++ programmer can go overkill and write with 
templates a compile-time lisp interpreter and run factorial 100 on it 
and just output 
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000

at run-time.

It's all feasible, just not very useful.

>> I fear IDEs are really only useful at getting away with lesser
>> languages' weaknesses
>>
>> so, all that would seem to rest of usefulness for an IDE is project
>> management.
> 
> I do not agree.
> 
> Consider the things that a typical IDE does:
> 
> - Syntax highlighting. Bracket pairing.
> 
> - Generate parts of an expression as you type. (E.g., generate the 
> matching close bracket, generate the "then" and "else" keywords when you 
> type "if".)

all common features of the most featureless text editors out there 
besides scumbag notepad.

> - Highlight any syntax errors, mismatched brackets, unused variables.

that requires a bit more working, specially unused variables. 
Mismatched brackets is a (mis)feature of languages that are not lisp. ;)

> - Allow you to compile the whole project with one keypress.

that's only useful for languages still in the old edit-compile-test 
cycle... ;)

in any case, even humble C can do that, provided a Makefile is ready. 
heck, Makefiles are language-agnostic even...

> - Highlight the line of source code that the compiler is complaining about.

emacs and vim both allow that kind of integration with external tools 
such as compilers... I'm sure other featureful text editors too.

> - Display a summary of what entities are defined in each file, what 
> their types are, whether they're public or private, etc.

For C/C++ that's as easy as simply taking a look at each header file. :)

> - Let you navigate to each entity in the list.

ever heard of exhuberant C-tags?  I'm sure it got support for haskell 
too, and is such a tool that generates for a codebase a tags file and 
lets you navigate through source code using those tags.  Support for it 
in both emacs and vim at least.

> - Run the document extraction tool.

what's wrong with man? ;)

> - Take you to the documentation for a given entity (regardless of 
> whether its in your project or an installed 3rd party library).
> 
> - Easily launch your application.

like ./out ?

> - Run your test suite and log the results.

like ./test > log.txt ?

> - Integrate with your source control system. Show interactive diffs. 
> Show the history tree. Manage commits and reverts and branches.

well, I'm stopping now.  It's clear you're just a button masher who 
enjoys mashing buttons than simply harnessing from an integrated textual 
development environment.

> - Integrate with the debugger. Let you single-step through your code. 
> Let you create watches, inspect variables in scope, drill down through 
> complex data structures.

you are not even talking like a haskeller anymore!  Is there such a 
haskell debugger?  Last time I heard, debugging and lazy evaluation were 
at odds...

> Tell me, how do any of these things stop being useful if your 
> programming language isn't object-oriented?

They are all very useful and none requiring a bloated and costly IDE. 
Intellisense is the only really thing useful in such IDEs, and, like I 
said, it's only really useful for OO languages.

Post a reply to this message

>> Did you know that there's a program called Djinn which can take any
>> Haskell type signature and generate Haskell source code for it, if
>> it's possible to write it without recursion?
>
> AFAIK, the hindley-milner type system is turing complete, so it's not
> surprising at all.

Basic Hindley-Milner isn't Turing-complete, no. Add a few extensions and 
it can be /made/ Turing-complete, however.

> So, if you want you may indeed just provide
> mind-boggling complex types and let djinn extract the program behaviour
> from that, just as a C++ programmer can go overkill and write with
> templates a compile-time lisp interpreter
>
> It's all feasible, just not very useful.

Not really.

Suppose I have two Maybe values, and I want a utility function to pick 
the first one which has a value in it. I run Djinn and say

   select ? Maybe x -> Maybe x -> Maybe x

It immediately replies

   select a b =
     case a of
       Nothing -> b
       Just c  -> Just c

which is the correct way to do this. (Although ever so slightly more 
verbose than necessary.)

Now actually there are /several/ possible functions with this type 
signature, and in a sense it's just a fluke that Djinn happens to have 
picked the one I wanted. However, this is not exactly a "mind-boggling 
complex type". Actually it's a pretty damned /simple/ type. :-P

So far I've fed all sorts of stuff into Djinn, and mostly it produces 
the code I wanted. The killer limitation is that it can't handle 
recursion. You can't have recursive types, you can't generate recursive 
code. That's a pretty big limitation. But for simple boilerplate that 
just involves lots of type conversions, it works great!

>> - Allow you to compile the whole project with one keypress.
>
> that's only useful for languages still in the old edit-compile-test
> cycle... ;)

Compiling a program is a useful way to check for errors, even if you 
don't intend to actually /run/ it. (Well, it is if you aren't coding in 
C anyway...)

> in any case, even humble C can do that, provided a Makefile is ready.
> heck, Makefiles are language-agnostic even...

Makefiles only work on Unix. :-P But hey, you can write a simple script 
to build your project under Windows.

The /real/ problem, of course, is that you have to open a command 
window, CD to the right folder, and type in "make program1" or whatever. 
This takes significantly longer than pressing F7 (or whatever).

Heck, KDevelop lets you have the terminal window embedded right there in 
the text editor, and it /still/ takes longer switching back and forth 
between windows than it would to just jab a key.

>> - Display a summary of what entities are defined in each file, what
>> their types are, whether they're public or private, etc.
>
> For C/C++ that's as easy as simply taking a look at each header file. :)

...and skipping over all the preprocessor directives, comments, inline 
functions, and other cruft. :-P

>> - Let you navigate to each entity in the list.
>
> ever heard of exhuberant C-tags?

What are "tags"?

>> - Run the document extraction tool.
>
> what's wrong with man? ;)

Oh Jesus, where do I even *start* with that??

>> - Easily launch your application.
>
> like ./out ?

Sure, once you take your hands off the keyboard and onto the mouse to 
switch from the text editor window to the command prompt window. :-P

> well, I'm stopping now.

...that's not what it looks like from here. ;-)

>> - Integrate with the debugger. Let you single-step through your code.
>> Let you create watches, inspect variables in scope, drill down through
>> complex data structures.
>
> you are not even talking like a haskeller anymore! Is there such a
> haskell debugger?

Yes, there is. OK, it doesn't actually /frigging work properly/, but it 
exists. And has a horrifyingly bad UI, BTW. Mainly because trying to do 
interactive program exploration using a CLI is really unintuitive.

>> Tell me, how do any of these things stop being useful if your
>> programming language isn't object-oriented?
>
> They are all very useful and none requiring a bloated and costly IDE.
> Intellisense is the only really thing useful in such IDEs, and, like I
> said, it's only really useful for OO languages.

Bloated I'll give you. But costly? Do you have any idea how many free 
IDEs there are?

Basically, what you've just said is "you can recreate some of the 
features of an /integrated/ development environment by manually linking 
tools together yourself". Sure, you can, it's just harder.

For the most part, I use a non-integrated development environment when 
I'm coding Haskell. That doesn't mean I don't see the value in something 
like Leksah.

An IDE is way, way more than just code completion.

Post a reply to this message

Le 2012-04-19 04:17, Invisible a écrit :
>> in any case, even humble C can do that, provided a Makefile is ready.
>> heck, Makefiles are language-agnostic even...
>
> Makefiles only work on Unix. :-P But hey, you can write a simple script
> to build your project under Windows.

WAT?

http://gnuwin32.sourceforge.net/packages/make.htm
http://msdn.microsoft.com/en-us/library/dd9y37ha%28VS.71%29.aspx

>
> The /real/ problem, of course, is that you have to open a command
> window, CD to the right folder, and type in "make program1" or whatever.
> This takes significantly longer than pressing F7 (or whatever).
>

Which you only have to do once... After that you only need to hit 
ALT-TAB and the up arrow.

> Heck, KDevelop lets you have the terminal window embedded right there in
> the text editor, and it /still/ takes longer switching back and forth
> between windows than it would to just jab a key.
>

Starting notepad++ and a command prompt take significantly less time 
than starting any IDE.  So you still have quite a few 
"F7-is-faster-than-alt-tab" to do before you catch up...

>>> - Easily launch your application.
>>
>> like ./out ?
>
> Sure, once you take your hands off the keyboard and onto the mouse to
> switch from the text editor window to the command prompt window. :-P
>

As mentioned previously,  ALT-TAB.  Much faster - and a lot easier on 
your elbow and shoulder tendons - than lifting your right hand going 
over the numeric keypad and using the mouse.


-- 
/*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

>>> in any case, even humble C can do that, provided a Makefile is ready.
>>> heck, Makefiles are language-agnostic even...
>>
>> Makefiles only work on Unix. :-P But hey, you can write a simple script
>> to build your project under Windows.
>
> WAT?

To tell you the truth, I don't even /like/ Make all that much. (I think 
it's the tab characters. Or the slightly clunky way it deals with 
targets that aren't files.) I only really use it for building C, because 
it's either that or work out how to invoke the compiler manually...

But as I say, a tiny amount of shell scripting will automate most tasks, 
without the need for Make.

>> The /real/ problem, of course, is that you have to open a command
>> window, CD to the right folder, and type in "make program1" or whatever.
>> This takes significantly longer than pressing F7 (or whatever).
>
> Which you only have to do once... After that you only need to hit
> ALT-TAB and the up arrow.

That works great - /until/ your command history has more than one 
command in it. E.g., if you use the same window to run the compiler, run 
the main program, and control your SCM. Then you end up jabbing up-arrow 
endlessly, or executing the wrong command, or both. Very annoying.

(I wonder why nobody has yet thought of making an editor where you can 
add buttons to the toolbar and kind arbitrary commands to them? You 
could even give them keyboard shortcuts...)

> Starting notepad++ and a command prompt take significantly less time
> than starting any IDE.

Depends on the IDE. Some are slower than others. I do take your point 
though - some of them do take an absurd amount of time to start. Then 
again, "you only do that once". :-P

>> Sure, once you take your hands off the keyboard and onto the mouse to
>> switch from the text editor window to the command prompt window. :-P
>>
>
> As mentioned previously, ALT-TAB. Much faster.

And if in the middle of your coding session, you quickly switch to your 
email client to check something, next time you try to use Alt+Tab, it 
takes you to the wrong window.

It sounds trivial, but it's really very, very annoying.

(It becomes even more fun when what you're working on involves more 
windows. E.g., right now I'm writing some TeX, so I have my text editor 
open, my command window open, and my DVI window open. You can 100% 
guarantee that almost every time I change window I change to the wrong 
one...)

Post a reply to this message

Francois Labreque escreveu:
> Le 2012-04-19 04:17, Invisible a écrit :
>>> in any case, even humble C can do that, provided a Makefile is ready.
>>> heck, Makefiles are language-agnostic even...
>>
>> Makefiles only work on Unix. :-P But hey, you can write a simple script
>> to build your project under Windows.
> 
> WAT?
> 
> http://gnuwin32.sourceforge.net/packages/make.htm
> http://msdn.microsoft.com/en-us/library/dd9y37ha%28VS.71%29.aspx
> 
>>
>> The /real/ problem, of course, is that you have to open a command
>> window, CD to the right folder, and type in "make program1" or whatever.
>> This takes significantly longer than pressing F7 (or whatever).
>>
> 
> Which you only have to do once... After that you only need to hit 
> ALT-TAB and the up arrow.
> 
>> Heck, KDevelop lets you have the terminal window embedded right there in
>> the text editor, and it /still/ takes longer switching back and forth
>> between windows than it would to just jab a key.
>>
> 
> Starting notepad++ and a command prompt take significantly less time 
> than starting any IDE.  So you still have quite a few 
> "F7-is-faster-than-alt-tab" to do before you catch up...
> 
>>>> - Easily launch your application.
>>>
>>> like ./out ?
>>
>> Sure, once you take your hands off the keyboard and onto the mouse to
>> switch from the text editor window to the command prompt window. :-P
>>
> 
> As mentioned previously,  ALT-TAB.  Much faster - and a lot easier on 
> your elbow and shoulder tendons - than lifting your right hand going 
> over the numeric keypad and using the mouse.

thank you ?)

Post a reply to this message

Invisible escreveu:
> But as I say, a tiny amount of shell scripting will automate most tasks, 
> without the need for Make.

yes.  It's easy to rewrite Make from scratch for your every projects.

BTW, do your scripts handle automatic compilation of only the parts that 
were last updated?

> That works great - /until/ your command history has more than one 
> command in it. E.g., if you use the same window to run the compiler, run 
> the main program, and control your SCM. Then you end up jabbing up-arrow 
> endlessly, or executing the wrong command, or both. Very annoying.

ctrl+Rghc
ctrl+Rmain
etc

oh, sorry.  Forgot you use a lameass DOS command prompt...

> (I wonder why nobody has yet thought of making an editor where you can 
> add buttons to the toolbar and kind arbitrary commands to them? You 
> could even give them keyboard shortcuts...)

emacs can do that.  And any decent text editor allows you to bind some 
keyboard shortcut to some command.

>>> Sure, once you take your hands off the keyboard and onto the mouse to
>>> switch from the text editor window to the command prompt window. :-P
>>>
>>
>> As mentioned previously, ALT-TAB. Much faster.
> 
> And if in the middle of your coding session, you quickly switch to your 
> email client to check something, next time you try to use Alt+Tab, it 
> takes you to the wrong window.

it`s much easier when you it all on the command-line. ;)

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

On 19/04/2012 06:14 PM, nemesis wrote:
> Invisible escreveu:
>> But as I say, a tiny amount of shell scripting will automate most
>> tasks, without the need for Make.
>
> yes. It's easy to rewrite Make from scratch for your every projects.
>
> BTW, do your scripts handle automatic compilation of only the parts that
> were last updated?

No, my compiler does that. :-P

Besides, compiling the entire thing takes less than 400 ms. Why would I 
care about speeding up compilation?

> oh, sorry. Forgot you use a lameass DOS command prompt...

There's a DOS command prompt that /isn't/ lame?

>> (I wonder why nobody has yet thought of making an editor where you can
>> add buttons to the toolbar and kind arbitrary commands to them? You
>> could even give them keyboard shortcuts...)
>
> emacs can do that.

Emacs doesn't even have a GUI yet. :-P

> And any decent text editor allows you to bind some
> keyboard shortcut to some command.

I've yet to find one, but OK.

>>> As mentioned previously, ALT-TAB. Much faster.
>>
>> And if in the middle of your coding session, you quickly switch to
>> your email client to check something, next time you try to use
>> Alt+Tab, it takes you to the wrong window.
>
> it`s much easier when you it all on the command-line. ;)

Yeah. That way you can't look at more than one file at once. Oh, wait...

Post a reply to this message

Orchid Win7 v1 escreveu:
> On 19/04/2012 06:14 PM, nemesis wrote:
>> BTW, do your scripts handle automatic compilation of only the parts that
>> were last updated?
> 
> No, my compiler does that. :-P

so, all your programs are some monolithic piece of software with all 
parts compiled in one go?

>> oh, sorry. Forgot you use a lameass DOS command prompt...
> 
> There's a DOS command prompt that /isn't/ lame?

No, but there's at least powershell, which is lame *and* heavy.

>>> (I wonder why nobody has yet thought of making an editor where you can
>>> add buttons to the toolbar and kind arbitrary commands to them? You
>>> could even give them keyboard shortcuts...)
>>
>> emacs can do that.
> 
> Emacs doesn't even have a GUI yet. :-P

it's GUI is useful enough to have buttons per-mode and to write a web 
browser for.

>> And any decent text editor allows you to bind some
>> keyboard shortcut to some command.
> 
> I've yet to find one, but OK.

you should look at any editor aside notepad.

>> it`s much easier when you it all on the command-line. ;)
> 
> Yeah. That way you can't look at more than one file at once. Oh, wait...

you're nuts.  Any decent editor has support for several file buffers. 
You may navigate them through with file buffer lists or tag files...

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

>>> BTW, do your scripts handle automatic compilation of only the parts that
>>> were last updated?
>>
>> No, my compiler does that. :-P
>
> so, all your programs are some monolithic piece of software with all
> parts compiled in one go?

Yes. Why?

>>> And any decent text editor allows you to bind some
>>> keyboard shortcut to some command.
>>
>> I've yet to find one, but OK.
>
> you should look at any editor aside notepad.

To be fair, SciTE allows you to define what F5, F7 and Ctrl+F7 do. (But 
only once per file-extension.) Sadly it doesn't let you do "when I press 
F7, compile THAT file, not the file I'm currently editing".

>>> it`s much easier when you it all on the command-line. ;)
>>
>> Yeah. That way you can't look at more than one file at once. Oh, wait...
>
> you're nuts. Any decent editor has support for several file buffers.

Any decent GUI-mode text editor, yes. On the a text terminal, you can't 
do that.

(Correction: Emacs can do it. And it looks awful.)

Post a reply to this message

On 18/04/2012 12:17 PM, Warp wrote:

>    If you want to read something actually useful about C++, try the
> "Effective" book series by Scott Meyers (or at the very least "Effective
> C++" and "More Effective C++"). They actually contain some competent and
> easy to understand information.
>
>    "Effetive STL" is probably also good.

I had a look at Effective C++ on Amazon. They let you look at a handful 
of pages before you buy it. By doing so, I already learned more about 
C++ in a few pages than anything the naff book I'm currently reading 
taught me.

On the other hand, it appears to be aimed at people who already know the 
C++ language. That isn't really me, yet. I know some of the syntax, but 
certainly not all of it, or what all of it actually does.

I'll see what kind of prices I can find for it...

Post a reply to this message

Orchid Win7 v1 escreveu:
>>>> BTW, do your scripts handle automatic compilation of only the parts 
>>>> that
>>>> were last updated?
>>>
>>> No, my compiler does that. :-P
>>
>> so, all your programs are some monolithic piece of software with all
>> parts compiled in one go?
> 
> Yes. Why?

because it's both wrong and dumb.

>>>> And any decent text editor allows you to bind some
>>>> keyboard shortcut to some command.
>>>
>>> I've yet to find one, but OK.
>>
>> you should look at any editor aside notepad.
> 
> To be fair, SciTE allows you to define what F5, F7 and Ctrl+F7 do. (But 
> only once per file-extension.) Sadly it doesn't let you do "when I press 
> F7, compile THAT file, not the file I'm currently editing".

yeah, while we're at it, it should also guess that THAT file is the 
right file you have in mind...

>>>> it`s much easier when you it all on the command-line. ;)
>>>
>>> Yeah. That way you can't look at more than one file at once. Oh, wait...
>>
>> you're nuts. Any decent editor has support for several file buffers.
> 
> Any decent GUI-mode text editor, yes. On the a text terminal, you can't 
> do that.
> 
> (Correction: Emacs can do it. And it looks awful.)

emacs, vi, pico etc...

it may look awful, but it behaves great.  Ever heard "don't judge a book 
by its cover"?

Post a reply to this message

>>> so, all your programs are some monolithic piece of software with all
>>> parts compiled in one go?
>>
>> Yes. Why?
>
> because it's both wrong and dumb.

That's right up there with saying that Haskell is better than C because 
C is both wrong and dumb. Yeah, it's true, but it won't convince anybody...

>>> you should look at any editor aside notepad.
>>
>> To be fair, SciTE allows you to define what F5, F7 and Ctrl+F7 do.
>> (But only once per file-extension.) Sadly it doesn't let you do "when
>> I press F7, compile THAT file, not the file I'm currently editing".
>
> yeah, while we're at it, it should also guess that THAT file is the
> right file you have in mind...

How hard would it be to allow each directory to contain a file saying 
what commands each key should be bound to? Or a text box to let you 
change it just for this session? Or *something*...

>>> you're nuts. Any decent editor has support for several file buffers.
>>
>> Any decent GUI-mode text editor, yes. On the a text terminal, you
>> can't do that.
>>
>> (Correction: Emacs can do it. And it looks awful.)
>
> emacs, vi, pico etc...
>
> it may look awful, but it behaves great. Ever heard "don't judge a book
> by its cover"?

The whole point of a text editor is for looking at text. Why make it 
look awful when you can make it look good? Why make your job harder when 
you can make it easier?

Post a reply to this message

Orchid Win7 v1 escreveu:
>>>> so, all your programs are some monolithic piece of software with all
>>>> parts compiled in one go?
>>>
>>> Yes. Why?
>>
>> because it's both wrong and dumb.
> 
> That's right up there with saying that Haskell is better than C because 
> C is both wrong and dumb. Yeah, it's true, but it won't convince anybody...

The time of monolithic pieces of software is long buried in the past. 
Today it's all composable by hundreds of small libs, perhaps even loaded 
at runtime.  Ever even heard of web mashups?  Application servers?

well, ok, for sufficiently small toy applications and scripts, 
monolithic is good enough.

> How hard would it be to allow each directory to contain a file saying 
> what commands each key should be bound to?

with a Makefile file in each directory each time you press make on the 
command-line it makes that part. ;)

>>>> you're nuts. Any decent editor has support for several file buffers.
>>>
>>> Any decent GUI-mode text editor, yes. On the a text terminal, you
>>> can't do that.
>>>
>>> (Correction: Emacs can do it. And it looks awful.)
>>
>> emacs, vi, pico etc...
>>
>> it may look awful, but it behaves great. Ever heard "don't judge a book
>> by its cover"?
> 
> The whole point of a text editor is for looking at text.

no, the whole point of a text *editor* is for *editing* text.

> Why make it 
> look awful when you can make it look good? Why make your job harder when 
> you can make it easier?

Nobody is making it look awful.  But between spending time making it 
look good and do nothing and looking awful and doing a shitton of stuff, 
you know what open-source developers will do...

plus, looking awful does not your job harder.  On the contrary:  in my 
experience the most beautiful-looking text editors out there are usually 
the most featureless and useless there are.  Why implement features that 
will make it complex and awful-looking?  Better just have a simple 
interface and when the user wants to copy the next 5 long paragraphs and 
paste them 5 times they should do it manually by constant repetition of 
the basic, beautiful and simple mechanisms, rather than just typing 
y5}5p... clearly the latter is making your job far harder!

Post a reply to this message

On 4/17/2012 1:52, Invisible wrote:
> Except that assembly generally follows a simple and consistent syntax,

... says the man who never programmed in an assembly language for machines 
designed to be programmed in assembly language.

> an "obscure feature" which you don't need to know about. :-P

It *is* outside the C standard, tho, in terms of what it "means".

> I dislike code that's so littered with comments that you can't see the code

Except in assembler.

> That's pretty messed up.

Why is it messed up? Ada even has a type for "one byte of memory" and a 
different type for "one byte of I/O".  You might read 8-bit strings from an 
I/O channel into 9-bit memory.

>> One warning: sizeof() will return the size in char, not bytes.
> Oh, that's fun. Let us hope that char *is* one byte, otherwise... damn!

Nah. There's a header file that tells you how many bits per byte. I'm pretty 
sure C assumes binary computers, tho. :-)

> I guess this is why autoconf exists. :-P

That and amongst many, many, *many* other reasons. Note that C isn't a 
portable language. It just lets you stick many versions of the source code 
into one file.

>> Second warning: the signedness of char is local to the compiler.
>
> Really? The book seems to say that all integer types default to signed,
> unless you request unsigned. (AFAIK, there isn't a way to request signed.)

Except characters. Because PDP-11.

> So much for C and C++ being for system-level programming. :-P

It was never very *good* for it. It was just better than its competitors of 
the time.

> microcontroller, I might be worried. On a desktop PC, I'm not too concerned.

Now, yeah. Note that IEEE standardized floating point *long* after C was 
around. Heck, even after x86 was around IIRC.

>> Usually, float is a 32 bits, double is 64 bits. But it is known that
>> some compiler would perform the computation on 80 bits registers...
>
> Is there a way to explicitly request 80 bits?

No, of course not. C doesn't provide any way to ask for a type based on what 
you need. You can only ask for types based on what the CPU provides, and 
header files to tell you what the CPU provides so you can write code to try 
to compile the right version. In Ada, in contrast, you'd say "give me the 
float with X range and Y precision."

> Right. So if I request a 2GB array, it won't actually sit there trying to
> zero all 2GB of RAM, right before my for-loop rolls over it to initialise it
> /again/.

The OS probably will, tho, if you have a multi-user OS.

> So, it always rounds downwards?

It might depend on the sign. Two positive integers always rounds down.

> Oh that's sick. So comma really /is/ an operator? Wow, that's evil.

Why? It's just an operator. Is it really worse than Haskell's "." or ">==" 
operators, or whatever they're called?

> I was referring more to the fact that it's legal to not specify the return
> type, and if you don't, it defaults to something absurd.

It defaults to integer. Not sure what makes that "absurd".

>>> Next, we learn that function arguments can have default values. But get
>>> this:
>>>
>>> "Any or all of the function's parameters can be assigned default
>>> values. The one restriction is this: If any of the parameters does not
>>> have a default value, no previous parameter may have a default value."
>>>
>>> ...um, what?
>>
>> At one point in the argument list, you must start providing default
>> values, for all argument at the right of that point.
>
> ...which makes infinitely more sense than what the book said. :-P

Really!?  What the book said was clearly and simply a mathematical-type 
statement. No parameter without defaults can be preceeded by one with 
defaults. Hence all defaults must come after all non-defaults.

The previous statement is inaccurate in that it does not take into account 
no-defaults and all-defaults.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/17/2012 3:47, Invisible wrote:
> Now, I'm used to programming languages where the decision to inline
> something or not is down to the compiler. It's not something an application
> programmer would ever have to worry about. And it seems that the inline
> directive is only a "hint" in C++ anyway, so I have to wonder, whether this
> particular directive is now obsolete.

This explains it better.

http://yosefk.com/c++fqa/inline.html

> In other words, yet again, "now you know how this works, you don't need to
> actually use it".

Right. Except in very limited circumstances when you know how deeply you'll 
recurse, because there's no guarantee it'll work and no way to check.

> I'm not sure what's so "unmanageable" about it all. Provided you don't try
> to reach behind the abstraction, there's no particular need to understand
> how it works.

As long as you never make a mistake, yes. If you pass the wrong type, the 
wrong number, or do something with a bad pointer that makes you clobber the 
stack, it's helpful to know how it works. ;-)

> "Registers are a special area of memory built right into the CPU."
> Erm...

What's questionable about that? Heck, on the Sigma 9, the registers 0 thru 
15 were actually addressed as memory locations 0 thru 15, to the point where 
you could store program code in the registers and branch to it.

> "They take care of internal housekeeping."
> ...actually...

Program Status Word.

> So I'm guessing an architecture exists where the instruction pointer /isn't/
> a single register then? :-P

Yep. Anything with memory mapping hardware, segment registers, etc.

> Still, it does answer something I've always wondered about: What *is* the C
> calling convention?

Undefined, generally speaking. Or rather, implementation-specific. And 
depends on pragmas, sometimes.

-
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/17/2012 7:17, Invisible wrote:
> would inlining it "bring its own performance costs"? I don't get that.

If you have several copies inlined different places, it may not be in CPU 
cache (or might even be paged out). I.e., by inlining, if you make it 
bigger, that's possibly a performance hit. Or not. Depends.

> OK, /that/ sounds rather more significant.

Not really.

> 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...

It *has* to be. The reason it's inline if it's in a class definition is the 
class definition gets compiled every time you #include it. Hence you're 
going to have lots of copies of the same function compiled, which therefore 
won't link, *unless* they're inline, because inline functions get merged by 
the compiler, see.

*That* is why it's "significant".

> 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?

Also, again, depends on your computer. I think we have 6 stack levels on the 
credit card terminal available.

> Well, yes. As I understand it, by default C++ doesn't reserve a whole lot of
> stack space,

That's really nothing to do with C++ per se.

> I'm a curious soul. I think to have some idea how things work, even if I
> don't know all of the details... ;-)

It still depends on the compiler, the declaration, etc. "printf" isn't going 
to pass any arguments in registers, most likely. abs() probably will. You 
can declare (with pragmas, for example) different calling conventions for 
different routines. (There is, for example, the Pascal calling convention, 
which means the caller removes the arguments from the stack, because each 
function in Pascal takes only a fixed number of arguments, so "remove them 
from the stack" code logically can be in only one place.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/17/2012 8:06, 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*.

Technically, I think a new copy of the function is generated/compiled for 
each compilation unit that uses it for each type, but the different versions 
for the same type are merged, right?

I.e., if x.c uses myfunc<int>() and y.c uses myfunc<int>() you'd need to 
compile that function twice and toss one at link time, right?

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/17/2012 6:40, Warp wrote:
> and that sizeof(char) = 1 (which does not mean "1 byte", but "1 indexable
> memory unit".)

There are lots of RISC CPUs that only allow word-size transfers. But the C 
compiler generates code to do a load, mask, manipulate, merge, and write.

>> The book casually mentions something which /seems/ to be claiming that
>> variables are not initialised to anything in particular unless you
>> specifically request this. That's interesting; I didn't know that.
>
>    C hackers don't want the extra clock cycle to initialize a variable
> which will be immediately assigned a new value anyways.

Because, of course, the compiler can't reliably figure out if you're using 
it before you assign to it. ;-)

>    The former casts *anything* into a double, while the latter casts only
> compatible types. (Which means that the latter will give you a compiler
> error if you try to cast from an incompatible type by mistake.)

Because, as already explained, C++ is designed to make the compiler complain 
about questionable things you might have done accidentally. Like using a 
variable that you might not have assigned to. ;-)

>    If you define a variable (or function) in the global namespace, it will
> be visible in the entire program. (Yes, you can access it from a different
> compilation unit. You just need to declare it with "extern" in that other
> compilation unit to do that.)

I think you're mixing up scope and lifetime here. The variable is "visible" 
in the scope sense only below where you declared it. You can declare it 
anywhere and get to the same variable, sure. I'd call that "accessible" more 
than "visible" maybe?

>    (Also, from a design point of view, global variables decrease abstraction,
> which is bad.)

Meh. My rule is that a global is OK (especially in languages with actual 
namespaces) if you can define the meaning for the entire lifetime of the 
variable. The problem with most globals is that they usually only have 
meaningful values for a portion of the program's execution. But stdin being 
global? Yeah, no problem with that.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/17/2012 7:04, Invisible wrote:
>> The integral part of the value is assigned to the int.
> So... it always rounds towards zero?

As long as they're both positive.

> Aren't expressions guaranteed to execute left-to-right?

No. That's what the comma operator is for that you dislike so much. ;-)

> always struggle to remember whether zero means true or false. The solution,

You're aware that boolean math matches up with + and * right? So remember it 
that way.

>  From what I'm seeing, just having multiple compilation units is a
> nightmare.

Multiple compilation units is only a nightmare when each can't refer to any 
other compilation units. The problem isn't that there's multiple compilation 
units, which pretty much every modern language above assembler supports. The 
problem is that xyz.c can't refer to abc.c, so it needs to recompile abc.h 
in order to know what's in abc.c, which of course can get out of sync 
because they're separate compilation units.

If you could #include <abc.o> you'd get rid of all the silliness of 
declaring inline functions multiple times, function prototypes, and all that 
kind of BS.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/17/2012 3:16, Invisible wrote:
> It gives you warnings if code is unreachable.

It gives you warnings if it thinks the code is unreachable. It gives you an 
error and won't let it compile if it can prove you have unreachable code.

{ int x = 0; return; x = 1; } // Gives an error.
{ int x = 0; if (true) return; x = 2; } // gives a warning.

> It even complains if you have a void function that uses return just to exit
> early, and there's nothing afterwards...)

I didn't run into that.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

Le 2012/04/17 09:40, Warp a écrit :

>> is a perfectly valid statement in C++. On the other hand, it also means that
>
>>     while (x[i] = y[i--]) ;
>
>> is perfectly valid. You sick, sick people.
>
>    I think that's Undefined Behavior because the same variable is being
> modified and referenced more than once in the same expression.
>

Nothing undefined here.

It's a simple loop that compare the array x[] and y[] untill it find a 
value that is different.
You get the value of x[i] and see if it's the same as the value of y[i] 
then you decrement i by one.
On exit, i will point to the value preceding the first different value.

You must initiate i to the last valid index of your array.
If all elements of both arrays are the same, you can realy screw things, 
so you beter make sure that the elements zero are different.

Post a reply to this message

On 4/17/2012 9:07, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> 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.
>
>    When will we see the Haskell# language?

I'm pretty sure the whole .NET bit is too OO to make that useful.There's way 
too much stateful stuff (like I/O) that you'd want to use from .NET to make 
it reasonable to have a purely function .net language.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/17/2012 12:26, nemesis wrote:
> IDEs are only really useful for OO languages.

I'm pretty sure LISP machines had exceedlingly kick-ass IDEs long before 
there was CLOS.

Plus, the IDE for Smalltalk doesn't really deal too much with the fact that 
it's OO. It didn't do any of the sorts of completion you're talking about.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/19/2012 10:14, nemesis wrote:
> yes. It's easy to rewrite Make from scratch for your every projects.

Maybe your projects. Mine compiles 1934 packages, and it's a pretty trivial 
program by google standards. :-)

> BTW, do your scripts handle automatic compilation of only the parts that
> were last updated?

Even better. Mine doesn't even compile code that *you* compiled previously. 
It also doesn't run unit tests for code that didn't change since last time 
it was tested. It also tells the builders of the libraries I use if they 
change code that breaks my code that depends on them.

It's pretty cool, but still a fair PITA sometimes.

>> (I wonder why nobody has yet thought of making an editor where you can add
>> buttons to the toolbar and kind arbitrary commands to them? You could even
>> give them keyboard shortcuts...)
>
> emacs can do that. And any decent text editor allows you to bind some
> keyboard shortcut to some command.

Yah. We call it an IDE. ;-)

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/19/2012 12:32, nemesis wrote:
> so, all your programs are some monolithic piece of software with all parts
> compiled in one go?

Mine are. But then, they get deployed to google's production machines, where 
you really would like them to run stably even if someone else changes their 
code. :-)

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/17/2012 12:51, Warp wrote:
>      // Execution will *never* reach here
>      // It's valid to omit a 'return'

But the compiler can prove that statically, so I'm not sure the problem.

I'm also not sure what the problem is with preventing use of uninitialized 
values without requiring the compiler to initialize them.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/18/2012 4:13, Warp wrote:>    But the C++ compiler cannot break the 
standard by making the situation
> an error. It can only issue a warning.

You mean, the C++ compiler cannot break the C standard by making this 
illegal. Even tho it makes other valid C programs illegal. :-)

>    (And besides, any kind of detection of this cannot be 100% accurate,
> as the problem "will this line of code ever be reached?" is unsolvable
> in the general case.)

But detecting type errors isn't 100% accurate either.

   int x = 1 ? 5 : "hello";

That's not legal, but it's not a type violation either.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/19/2012 18:38, Alain wrote:
> Le 2012/04/17 09:40, Warp a écrit :
>
>>> is a perfectly valid statement in C++. On the other hand, it also mea
ns that
>>
>>> while (x[i] = y[i--]) ;
>>
>>> is perfectly valid. You sick, sick people.
>>
>> I think that's Undefined Behavior because the same variable is being
>> modified and referenced more than once in the same expression.
>>
>
> Nothing undefined here.

Does it compare x[i] to y[i] or to y[i-1]?  Why do you answer that way?

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

Le 20/04/2012 03:16, Darren New a écrit :
> On 4/17/2012 8:06, 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*.
> 
> Technically, I think a new copy of the function is generated/compiled
> for each compilation unit that uses it for each type, but the different
> versions for the same type are merged, right?
> 
> I.e., if x.c uses myfunc<int>() and y.c uses myfunc<int>() you'd need to
> compile that function twice and toss one at link time, right?
> 

IIRC, If the call to myfunc<int>() is done in the same compilation unit
(same top level cpp file), it will be generated once as "static
function" (jump to local symbol, at best; that does not work if it
become inlined code of course).

If they are in separate compilation units (different top level *.cpp
files), each units will get its own version.

Linker will not remove either. (because it has no way to know if the one
in unit A is identical to the one in unit B: naming is no use, you might
have compiled unit A with the version of Monday, and unit B with the
version of Saturday.
(that's the issue with template: generated code can grow very fast if
you use the template in many *.cpp files)

Post a reply to this message

Le 20/04/2012 03:56, Darren New a écrit :
> On 4/19/2012 18:38, Alain wrote:
>> Le 2012/04/17 09:40, Warp a écrit :
>>
>>>> is a perfectly valid statement in C++. On the other hand, it also
>>>> means that
>>>
>>>> while (x[i] = y[i--]) ;
>>>
>>>> is perfectly valid. You sick, sick people.
>>>
>>> I think that's Undefined Behavior because the same variable is being
>>> modified and referenced more than once in the same expression.
>>>
>>
>> Nothing undefined here.
> 
> Does it compare x[i] to y[i] or to y[i-1]?  Why do you answer that way?
> 
You missed the point: let's name k the initial value of i;

Would you expect the test to be between:
 x[k] & y[k]
 x[k-1] & y[k]

It cannot be x[k] & y[k-1], per the definition of the post-decrement
operator.

-- 
A good Manager will take you
through the forest, no mater what.
A Leader will take time to climb on a
Tree and say 'This is the wrong forest'.

Post a reply to this message

>> No. A new version is created for each used *type*.
>
> Technically, I think a new copy of the function is generated/compiled
> for each compilation unit that uses it for each type, but the different
> versions for the same type are merged, right?

I'm presuming that's why it's implicitly inline - to allow the merging.

Post a reply to this message

>>> The integral part of the value is assigned to the int.
>> So... it always rounds towards zero?
>
> As long as they're both positive.

Does it round towards zero, or towards negative infinity?

>> Aren't expressions guaranteed to execute left-to-right?
>
> No. That's what the comma operator is for that you dislike so much. ;-)

Oh good. The book /insists/ that left-to-right order is guaranteed. Nice 
to know that in addition to being poorly explained, it's also factually 
inaccurate. :-P

>> always struggle to remember whether zero means true or false. The
>> solution,
>
> You're aware that boolean math matches up with + and * right? So
> remember it that way.

A better way might be to think of true and false as 1 and 0. (Although 
of course C allows true to be /anything/ that isn't 0, not just 1.)

>> From what I'm seeing, just having multiple compilation units is a
>> nightmare.
>
> Multiple compilation units is only a nightmare when each can't refer to
> any other compilation units.

I'm currently trying to work out how I can compile a program where 
module 1 refers to module 2, but module 2 also refers to module 1. As 
far as I can figure out, this is impossible...

Post a reply to this message

>>>> while (x[i] = y[i--]) ;
>>>
>>>> is perfectly valid. You sick, sick people.
>>>
>>> I think that's Undefined Behavior because the same variable is being
>>> modified and referenced more than once in the same expression.
>>>
>>
>> Nothing undefined here.
>
> Does it compare x[i] to y[i] or to y[i-1]? Why do you answer that way?

Last time I checked, the /comparison/ operator is ==.

The = operator performs *assignment*. :-P

(Assuming that neither x[] nor y[] contains any zero bytes, presumably 
this is also an infinite loop...)

Post a reply to this message

>> When will we see the Haskell# language?
>
> I'm pretty sure the whole .NET bit is too OO to make that useful.There's
> way too much stateful stuff (like I/O) that you'd want to use from .NET
> to make it reasonable to have a purely function .net language.

Haskell already supports a wide range of I/O operations. That's pretty 
stateful, and it's not a problem.

Yeah, if you wanted to talk to the .NET libraries, it would all end up 
being monadic. (Even the .NET stuff that's actually pure - since it 
isn't /marked/ as pure.) But it would still work fine.

I think it's probably vacuous to try to estimate how "useful" it would 
be without actually trying it...

Post a reply to this message

> The time of monolithic pieces of software is long buried in the past.
> Today it's all composable by hundreds of small libs, perhaps even loaded
> at runtime. Ever even heard of web mashups? Application servers?

Well, unfortunately Haskell does not yet support dynamic linking very 
well. (At least it now has /some/ support for it...)

>> How hard would it be to allow each directory to contain a file saying
>> what commands each key should be bound to?
>
> with a Makefile file in each directory each time you press make on the
> command-line it makes that part. ;)

Yeah, that could work.

>> The whole point of a text editor is for looking at text.
>
> no, the whole point of a text *editor* is for *editing* text.

Well, if that's your attitude, then surely ed is good enough for you?

>> Why make it look awful when you can make it look good? Why make your
>> job harder when you can make it easier?
>
> Nobody is making it look awful. But between spending time making it look
> good and do nothing and looking awful and doing a shitton of stuff, you
> know what open-source developers will do...
>
> plus, looking awful does not your job harder. On the contrary: in my
> experience the most beautiful-looking text editors out there are usually
> the most featureless and useless there are. Why implement features that
> will make it complex and awful-looking? Better just have a simple
> interface and when the user wants to copy the next 5 long paragraphs and
> paste them 5 times they should do it manually by constant repetition of
> the basic, beautiful and simple mechanisms, rather than just typing
> y5}5p... clearly the latter is making your job far harder!

I can't even tell what the hell you're saying now. :-P

Post a reply to this message

>> (And besides, any kind of detection of this cannot be 100% accurate,
>> as the problem "will this line of code ever be reached?" is unsolvable
>> in the general case.)
>
> But detecting type errors isn't 100% accurate either.
>
> int x = 1 ? 5 : "hello";
>
> That's not legal, but it's not a type violation either.

The general problem of determining whether every possible code path is 
well-typed is undecidable. Type systems insert artificial restrictions 
to /make/ the problem decidable. Hence, there are expressions and 
statements which are well-typed, but do not type-check.

Post a reply to this message

>> It even complains if you have a void function that uses return just to
>> exit early, and there's nothing afterwards...)
>
> I didn't run into that.

By "complains" I mean it gives you a warning. It still compiles OK.

Post a reply to this message

On 20/04/2012 01:57 AM, Darren New wrote:
> On 4/17/2012 1:52, Invisible wrote:
>> Except that assembly generally follows a simple and consistent syntax,
>
> ... says the man who never programmed in an assembly language for
> machines designed to be programmed in assembly language.

So what /was/ the Motorola 68000 designed to be programmed in then?

>> an "obscure feature" which you don't need to know about. :-P
>
> It *is* outside the C standard, tho, in terms of what it "means".

Sure. But in terms of writing practical code that runs on common 
hardware under common operating systems - which is the target of this 
book - it's not exactly "obscure". It's not like this is a book about 
how to program microcontrollers. (That would be something else entirely...)

>> I dislike code that's so littered with comments that you can't see the
>> code
>
> Except in assembler.

?

>> I guess this is why autoconf exists. :-P
>
> That and amongst many, many, *many* other reasons.

I found another one:

http://tinyurl.com/32vda9

>>> Second warning: the signedness of char is local to the compiler.
>>
>> Really? The book seems to say that all integer types default to signed,
>> unless you request unsigned. (AFAIK, there isn't a way to request
>> signed.)
>
> Except characters. Because PDP-11.

It worries me that we're still using a language who's fundamental design 
decisions are based on hardware first produced in the 1970s.

But it worries me more that they only stopped manufacturing the PDP-11 
in the 1990s. o_O

>> So much for C and C++ being for system-level programming. :-P
>
> It was never very *good* for it. It was just better than its competitors
> of the time.

Jesus, did it even *have* any competitors?!

>>> Usually, float is a 32 bits, double is 64 bits. But it is known that
>>> some compiler would perform the computation on 80 bits registers...
>>
>> Is there a way to explicitly request 80 bits?
>
> No, of course not. C doesn't provide any way to ask for a type based on
> what you need. You can only ask for types based on what the CPU
> provides

OK, well IA-32 provides 80-bit floats. So... is there a standard way to 
get them?

>> Right. So if I request a 2GB array, it won't actually sit there trying to
>> zero all 2GB of RAM, right before my for-loop rolls over it to
>> initialise it
>> /again/.
>
> The OS probably will, tho, if you have a multi-user OS.

Not much I can do about that. ;-) But yeah, it does make the whole 
design decision seems a be out-dated. (Then again, calling the default 
constructor for each array element might do a lot more work than just 
zeroing some bytes. Presumably the way the OS zeros memory is quite 
efficient.)

>> Oh that's sick. So comma really /is/ an operator? Wow, that's evil.
>
> Why? It's just an operator. Is it really worse than Haskell's "." or
> ">==" operators, or whatever they're called?

You'd expect part of the language's basic syntax to be, you know... part 
of the language's basic syntax. But it isn't. It's just a regular 
operator, which means you can use it in places where you shouldn't be 
putting random commas, and that makes it do strange stuff. (And, being 
C, this isn't checked in any way.)

>> I was referring more to the fact that it's legal to not specify the
>> return
>> type, and if you don't, it defaults to something absurd.
>
> It defaults to integer. Not sure what makes that "absurd".

The /logical/ thing is for a function that doesn't mention a return type 
to default to returning nothing. And yet, it doesn't. It arbitrarily 
defaults to int. Not bool, not void*, not w_char, but int. No reason, it 
just does.

>>> At one point in the argument list, you must start providing default
>>> values, for all argument at the right of that point.
>>
>> ...which makes infinitely more sense than what the book said. :-P
>
> Really!? What the book said was clearly and simply a mathematical-type
> statement. No parameter without defaults can be preceeded by one with
> defaults. Hence all defaults must come after all non-defaults.
>
> The previous statement is inaccurate in that it does not take into
> account no-defaults and all-defaults.

I forget who said it: comprehension = 2 ^ -precision.

Post a reply to this message

>> In other words, yet again, "now you know how this works, you don't
>> need to actually use it".
>
> Right. Except in very limited circumstances when you know how deeply
> you'll recurse, because there's no guarantee it'll work and no way to
> check.

...what?

>> "Registers are a special area of memory built right into the CPU."
>> Erm...
>
> What's questionable about that? Heck, on the Sigma 9, the registers 0
> thru 15 were actually addressed as memory locations 0 thru 15, to the
> point where you could store program code in the registers and branch to it.

Nobody designs hardware like that any more. Haven't done for decades. :-P

>> "They take care of internal housekeeping."
>> ...actually...
>
> Program Status Word.

The /registers/ do not take care of anything. The /processor/ does.

>> So I'm guessing an architecture exists where the instruction pointer
>> /isn't/ a single register then? :-P
>
> Yep. Anything with memory mapping hardware, segment registers, etc.

None of which are relevant in the current day and age, unless you're 
writing an OS. Certainly this technicality has no place in an 
introductory programming text.

>> Still, it does answer something I've always wondered about: What *is*
>> the C calling convention?
>
> Undefined, generally speaking. Or rather, implementation-specific. And
> depends on pragmas, sometimes.

So you're telling me that the de facto calling convention that all 
software always uses is "undefined"?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Technically, I think a new copy of the function is generated/compiled for 
> each compilation unit that uses it for each type, but the different versions 
> for the same type are merged, right?

  Yes. (Except if the function is inlined by the compiler, in which case
there's no need.)

-- 
                                                          - Warp

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> If they are in separate compilation units (different top level *.cpp
> files), each units will get its own version.

  No, they will be merged by the linker (although I'm not completely sure
now if the standard requires it; at the very least it requires for all
static variables inside the function to be merged, IIRC).

  If the context of the template instantiation affects its behavior, then
instantiating it under differing contexts is actually undefined behavior.
(In practice what will usually happen is that only one of them will end up
in the final binary and all the code will call that one; the other contexts
will have no effect on it.)

> (that's the issue with template: generated code can grow very fast if
> you use the template in many *.cpp files)

  Object files might grow, but not the final binary.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> > 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...

> It *has* to be.

  It doesn't *have* to be (any more than any other function defined in a
header file, or anywhere else), but the standard says it is, and so it is.

  The difference can be seen eg. like this:

//-------- Example 1 ----------
class A
{
 public:
    // This function is implicitly 'inline',
    // no need to specify the keyword:
    void foo() { std::cout << "Hello\n"; }
};
//-----------------------------

//-------- Example 2 ----------
class A
{
 public:
    void foo();
};

// This function is *not* implicitly 'inline' and will cause linker
// errors unless the keyword is used:
void A::foo() { std::cout << "Hello\n"; }
//-----------------------------

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> If you could #include <abc.o> you'd get rid of all the silliness of 
> declaring inline functions multiple times, function prototypes, and all that 
> kind of BS.

  So you would be simply changing the dependency to a .h file to dependency
to a .o file. What would be the relevant difference?

  Also, I assume you understand that templated code cannot be precompiled
into an object file? They need to be recompiled each time they are used...
which is kind of the whole idea.

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I'm currently trying to work out how I can compile a program where 
> module 1 refers to module 2, but module 2 also refers to module 1. As 
> far as I can figure out, this is impossible...

  The only thing that's impossible for a class to have another class
as member variable, and that another class having the first class as
member variable. (For obvious reasons. It would be an infinitely large
class.)

  Other than that, any kind of cross-referencing should be possible.

-- 
                                                          - Warp

Post a reply to this message