Francois Labreque escreveu:

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