I''ve playing about with Ruby lately (using it for the kind of stuff I''d normally use Perl for), and it''s pretty good. I''m not used to dynamically typed languages though, so it still feels a bit odd

Everything, including including integers and other datatypes are classes? Aren''t we taking OO a little too far? Why must we attempt to abolish all procedural forms of programming?

Ugh . . . My mind is still mushy from those obsucifated languages . . . Comment more another day, need break . . .


"Whoever performs only his duty is not doing his duty." --Bahya ibn Pakuda

First: get Visual C++ ... it supports all SORTS of wonderful things with project settings and multiple project configurations... mainly, per-configuration symbols (which means you don't have that "#define DEBUG" line, it's done (and removed) automatically by changing the active config from whatever to whatever, usually from "Debug" to "Release"

MadKeith, you make me want to hurl. I can't think of a nice way to say it. "". That WOULD work, only it means you STILL have to worry about that variable, PLUS, it means a ton of excess code in your EXE. WHY would you want to have code that looks like this?:

if(bDebug)
{
...
}
else
{
...
}

You're asking the REAL-TIME proccessor to evaluate that conditional for you, EVERY TIME THE CODE IS RUN, rather than letting the preproccessor do it ONCE. And that stuff you said about "exception handling" didn't sound very elegant...

VC++ even supports integrated ASM, if you know what you're doing, which is another excellent reason to use preproccessor... you have several configs for each processor you want to take specific advantage of (this means speed enhancements ONLY found on that specific, or maybe a handful of, processor(s)), each of which uses preprocessor to compile the appropriate ASM code for that blend of processor.

As for macros... granted they're not type-safe (ideally, you should be a good enoguh programmer that you don't MAKE mistakes, but that's never the case), but they are by FAR my method-of-choice for inlining functions. Macros aside, single-value symbols are, without a doubt, the ultimate way to create and use constants... they work almost exactly the same (and you can typecast them if you need the extra level of safety), and the DON'T REQUIRE ANY MEMORY. "const double cow = 10" works, but it requires memory to store that variable... whay WOULDN'T you use "#define cow 10.0d" which has the same result ("cow" in your code will always mean "10") without the overhead of memory space... and it's just as easy to maintain if the value you need changes.

I'm not even going to touch the things like real-time debugging, step-based execution, dynamic variable and code-pointer modification, etc., MOST (if not all) of which also require a special blend of building that leaves extra information in an executable.

-----

In response to Mithrandir, you said some of what I did... The problem with inlining is that it isn't guaranteed like macros (not to mention taking more space in the source files).

...but I have to agree with the sentiment of C++ being "hacked together". I pretend to use C++, but most of my code uses C libraries... My major gripe is I've noticed a lot of places in C++ that involve several times the number of function calls as the C equivalent, and the code is often much more difficult (and irritating) to write. I never really liked classes, either... I prefer structs, with the occasional accompanying function. Particularly in game programming, it seems far more efficient, and can be easier to manage. This is beside all the nasty things I've heard of hearing about classes (bubt haven't really gotten around to reading myself)

-----

bogdanontanu, I have to agree with MadKeith on one thing... I don't think you read the thread either. Look! I mention ASM! The main reason (in my mind) is that C/C++ are more-or-less the fastests languages about (besides ASM, of course, which is harder to learn). I've played with MUF, which would seem to be a variation on FORTH (MUF = Multi-User Forth), and frankly I'm in LOVE with the language... MUF (and not having seen actual Forth, this may be MUF and only MUF) is a rather elegant, if bizzare-seeming language, with what I would consider an excellent procedure-calling convention. Working purely off a stack can be a debugging nightmare, but it's VERY well suited to not only variable-parameter input, but variable-parameter RETURN as well... and it's probably one of the easiest languages to interperate (other than perhaps ASM), as it consists of no syntax, ony opcodes, variables (implemented in a pretty simple way) and literals (numbers, strings, etc.)

Youch, that was long, wasn't it?

--Tr][aD--

Edited by - TrIaD on October 30, 2000 8:57:04 PM

Edited by - TrIaD on October 30, 2000 9:00:35 PM

I read the thread dont worry...

i was talking more about Forth that is IMHO the best programming language...

after all it had OOP in 1979 on 8bits and its virtual machine is about 10bytes or lower on most modern processors.

and yeah for the Star Trek guy:
i like the movie myself a lot but u see "its made in a Hollywood basement" we (earthlings) never put our foot on another planet...so...

but a language that u ask:
-please do me that thing i was just thinking..

its not a programming language anymore....it can be just a language...but no more a programming language....

and you know somebody has to do the language that will do your so called program...

so my ideea its to keep it simple...because layer after layer we are more and more like advanced users an not programmers anymore...

programming is about knowing how to do things using algorithms and not how to ask for your deeams come true (this lately is the user''s side )

btw OOP is at the edge of programming (the other edge is just graphic design) and i think its more like ease of use in a GUI context then algorithmic side that shines throught OOP...

without GUI and menus we almost never need OOP....

but its a good point: i will try to be more tolerant myself...

Bogdan

PS a am happy somebody else also brings up Forth here because he has also the simplicity to be done on any machine in about 30 days or less by allmost everybody and the power of OOP/functional programming/virtual machine

OOP is the edge of programming?

In a world that revolves around the dollar, in a country where time is money, in a field where time is the primary cost, wouldn''t you want use tools to expedite your work?

I want a language that lets me write highly reuseable code.
I want no loss of efficentcy in the compiled code.
I want an interpretor to make debugging faster & easier.
I want to be able to see the asm code lined up with the code I write.
I want an IDE the helps me design my program not just write code.

quote:
they work almost exactly the same (and you can typecast them if you need the extra level of safety), and the DON'T REQUIRE ANY MEMORY. "const double cow = 10" works, but it requires memory to store that variable...

If you take the address of the double (which you can't do with a macro), then it wont take up any extra space than a macro.

quote:
whay WOULDN'T you use "#define cow 10.0d" which has the same result

The more important reason for me is scope. Unless your working on a tiny project (or have really odd naming methods) it'll be pretty hard to make sure every constant has a different name. If you use const, then it's ok cos scope will take care of it. But if your using macros it all falls down and the compile errors make almost no sense. A macro is just 'find & replace' so it can break functions, class names, as well as other constants and variables. e.g.

// Something.h#define cow (10.0)// Foo.h#include "something.h"class Foo{	const int cow = 15;public:	// rest of class...};  

If the #define was a const double, it would be ok. But it's not so you end up with:

quote:
warning C4091: '' : ignored on left of 'const int' when no variable is declared
error C2143: syntax error : missing ';' before 'constant'
error C2106: '=' : left operand must be l-value

I've seen that enough times to know what it means, but the first couple of times you just think "ugh?". The only hard bit is finding out what file in the include chain has the macro, so you can go change it to a const double like it should have been in the first place.

If you really do need to use #define (I can't think of a reason that you would in C++ code though, can anyone else?), don't put them in header files.

quote:
The problem with inlining is that it isn't guaranteed like macros

If the function wont be inlined by the compiler, and you really do need it to be. Then you've got no choice but to use a macro (assuming a macro will work). But your default method of inlining should be 'inline' not '#define'

quote:
(not to mention taking more space in the source files).

Your joking right? It's a few extra chars. Unless you need to do all your backups to a single 3.5 inch disk there's no reason to care.

- Wilka

Edited by - Wilka on October 31, 2000 2:39:54 PM

In response to Magmai Kai Holmlor: It sounds to me like you want VC++... it has MOST of those features, if not all

quote:
If you take the address of the double (which you can't do with a macro), then it wont take up any extra space than a macro.

You'll have to explain that to me... and tell me if the following statement is false:
An instruction like "MOV eax 5" is faster than "MOV eax [&5]"
(and if that's backwards, I apologize, because I don't program ASM)

quote:
The more important reason for me is scope. Unless your working on a tiny project (or have really odd naming methods) it'll be pretty hard to make sure every constant has a different name. If you use const, then it's ok cos scope will take care of it. But if your using macros it all falls down and the compile errors make almost no sense. A macro is just 'find & replace' so it can break functions, class names, as well as other constants and variables. e.g.

use a name like _somn_cons_Foo... it's a little worse, but not terribly... and like you said, keep it out of .h's

also... look at this... something I use in a library of mine...

#define foo(a,b) a*bdouble (foo)(double a, double b) {return foo(a,b);}   

quote:
I've seen that enough times to know what it means, but the first couple of times you just think "ugh?". The only hard bit is finding out what file in the include chain has the macro, so you can go change it to a const double like it should have been in the first place.

I won't even comment. I hate using const's.

quote:
If you really do need to use #define (I can't think of a reason that you would in C++ code though, can anyone else?), don't put them in header files.

The second half is good advice. If you will recall, though, my style tends toward C, borrowing a LITTLE from C++... I prefer to work with C concepts, so you're comment is irrelevant in this case. If you're going waste all those functions calls by using C++ then you wouldn't care about macros.

quote:
If the function wont be inlined by the compiler, and you really do need it to be. Then you've got no choice but to use a macro (assuming a macro will work). But your default method of inlining should be 'inline' not '#define'

Maybe it's not the greatest example. But, I'll put it this way: I prefer the knowledge that is IS being inlined, rather than leaving it up to the compiler to decide...

quote:
Your joking right? It's a few extra chars. Unless you need to do all your backups to a single 3.5 inch disk there's no reason to care.

No, I'm not. Some of us are... "picky" about our file size. And some of us DO transfer projects from PC to PC using a good old 3.5".




On a totally seperate topic, can someone tell me more about FORTH, or preferably show me a short code sample? I think I sorta know what it's like from using MUF (which, btw, I picked up in a day, maybe two), but I'd like to have a better idea...



(added after a second look at that post)

quote:
If the #define was a const double, it would be ok. But it's not so you end up with:

--------------------------------------------------------------------------------

warning C4091: ' : ignored on left of 'const int' when no variable is declared
error C2143: syntax error : missing ';' before 'constant'
error C2106: '=' : left operand must be l-value

--------------------------------------------------------------------------------

I've seen that enough times to know what it means, but the first couple of times you just think "ugh?". The only hard bit is finding out what file in the include chain has the macro, so you can go change it to a const double like it should have been in the first place.

If you're using VC++, it will tell you (and in fact, jump to) the line with the error on it. From there it's pretty easy to sdetermine what the problem symbol is, which you type into full-project search, which tells you every occurence of it everywhere... it's not hard to find the result line that starts with "#define"

--Tr][aD--

Edited by - TrIaD on October 31, 2000 7:49:12 PM

quote: Original post by Poltras

Just for fun...
Anyone heard about Brainf*ck? It has 8 functions and works with array of integers. It is cool, but

''++++++++[->++++++++<]+.+.+.''
actually print "ABC"... I saw an hello world with this. Really hard to follow.
Here for a brief description of the language
Home page of Brainf*ck

if you think Brainf*ck is weird, here''s Hello World in INTERCAL:

        PLEASE DO ,1 <- #13        DO ,1 SUB #1 <- #584        DO ,1 SUB #2 <- #837        DO ,1 SUB #3 <- #1100        DO ,1 SUB #4 <- #1356        DO ,1 SUB #5 <- #1615        DO ,1 SUB #6 <- #1824        DO ,1 SUB #7 <- #2135        DO ,1 SUB #8 <- #2383        DO ,1 SUB #9 <- #2642        DO ,1 SUB #10 <- #2892        DO ,1 SUB #11 <- #3140        DO ,1 SUB #12 <- #3361        DO ,1 SUB #13 <- #266        PLEASE DO ,2 <- #1        PLEASE DO .5 <- #0        PLEASE DO .4 <- #1        PLEASE COME FROM (1)        DO .6 <- ",1 SUB .4"~#255        DO .6 <- !6~#15''$!6~#240''        DO .6 <- !6~#15''$!6~#240''        DO .6 <- !6~#15''$!6~#240''        DO .1 <- .5        DO .2 <- .6        PLEASE DO (1010) NEXT        DO .3 <- .3~#255        DO .5 <- .6        DO ,2 SUB #1 <- .3        PLEASE READ OUT ,2(1)     PLEASE DO .4 <- ",1 SUB .4"~#3840        PLEASE GIVE UP

Gunnar, who happens to think Common Lisp is the most beautiful Language ever.

quote:
If you take the address of the double (which you can''t do with a macro), then it wont take up any extra space than a macro.

That should have been "If you don''t take the address...". oops

quote:
If you''re using VC++, it will tell you (and in fact, jump to) the line with the error on it. From there it''s pretty easy to sdetermine what the problem symbol is

My point is that when do jump to the error, you''ll see "const int cow = 15;". So if you don''t already know this is what happens when a macro goes bad, you wont know to search for it.

quote:
use a name like _somn_cons_Foo... it''s a little worse, but not terribly... and like you said, keep it out of .h''s

also... look at this... something I use in a library of mine...

quote:
Some of us are... "picky" about our file size. And some of us DO transfer projects from PC to PC using a good old 3.5".

Wont all those icky names for constants (e.g. _somn_cons_Foo), and the extra brackets around functions (e.g. double (foo)(double a, double b) ) take up more space than using const''s and not needing the extra guff?

I use VC & it doesn''t have any of those features ;p
Though I don''t know anything better.

OOD is pretty re-useable, but it comes at a cost...
The compile & continue "feature" of VC is buggy, and takes forever...
You can almost see the asm & the code lined up, but not quite...

The program design part is most lacking...
And I don''t know of any tools to help you design a program...
I did just buy a book today though, Design Patterns...