Weird MACRO behavior...

[dedndave]

i think a C-style "\n" is chr$(10)   :P

[dedndave]

ok - according to the wiki page, "ms dos/windows \n" is 13,10
but, for MessageBox, all you need is the 10   :t

[rrr314159]

\n means "newline". On different systems, even different progs on same system, it can mean different chars; sometimes both 13 and 10, sometimes just 10; could be something else if u weren't using ASCII. (Pretty sure) the official C def only specifies "newline". qWord, BTW, translates it to 10 and uses \R for 13. Messagebox, and various other places in Windows, just 10 is enuff for a newline, but I've seen it not work right (forget where) and require the 13 also.

Hey, if it was simple anyone could do it!

But the issue here is the macro behavior ... jj2007, thx for pointing it out, checked my prnt routine and I've got the same problem. If user equ's n (or t, etc) to ebx (or whatever) it doesn't work. Need to suppress the macro expansion for the print escape codes ... clumsy way to do it: remember what n is equ'd to, re-equ it to n, then put it back at the end of the print routine. But, doesn't work if the user goes n equ 3 (a number). Then it's a "permanent constant" and u get error if try to re-define it. And, what if he really wants n to stand for (say) t: wants it to mean tab?

Hmmm ... perhaps the right approach is to take a nice nap, then see what's on the tube ...

[rrr314159]

Seems no sensible way to suppress the macro expansion using SUBSTR. But FORC behaves as it should: gives one unexpanded character, u have to tell it to expand (with %).

Have a short story about this issue ... Microsoft "deprecates" FORC in the Programmer's Guide 6.1:

With versions of MASM earlier than 6.0, FORC is often used for complex
parsing tasks. A long sentence can be examined character by character. Each
character is then either thrown away or pasted onto a token string, depending on
whether it is a separator character. The new predefined macro functions and
string processing directives discussed in the following section are usually more
efficient for these tasks.

The new functions, of course, are SUBSTR, INSTR etc. Now, when I was going thru MASM32 macros.asm a couple months ago, I found that cfm$ uses FORC (not sure, but I think it's written by MichaelW?). So (believing MS) I re-wrote it using SUBSTR. It's shorter, maybe more efficient, and definitely harder to understand (aka clever). Turns out it's no good: seems no way to eliminate this bug (n equ ebx). So, going back to the old cfm$ instead. Learning similar lessons going thru masm32/m32lib, which somehow I never noticed until couple days ago. I've re-invented many wheels, but often mine are square or hexagonal instead of round  ;)

Two lessons to be learned from this:

"Never trust MicroSoft" - jj2007

"Computer software is like wine - the older the better." - iZ!

[jj2007]

clumsy way to do it: remember what n is equ'd to, re-equ it to n, then put it back at the end of the print routine.

Works like a charm for n. For reasons that only Bill Gates may know, it fails miserably for t :(

Re FORC, I swear I had tested that option, and it expanded just like SUBSTR. So I discarded it. Today I retested after reading your last post, and voilà it works! Will try again tomorrow - probably it works on Thursdays only. Mysteries of the 20th century

When people outside the Masm32 scene read this, they must surely think "dear oldies, why don't you go for a modern language?" ;-)

[rrr314159]

I don't think people outside the Masm scene read this, but the answer would be "my prog is smaller and faster than yours, that's why" ... let us know if u find another way to handle the problem, until then I'm assuming "older is better" and reverting to FORC

p.s. don't forget, C++ has its arcane mysteries also, some features work only when the moon is full

[Gunther]

p.s. don't forget, C++ has its arcane mysteries also, some features work only when the moon is full

That's a bit exaggerated, I think. But you're right: C++ comes with a lot of overhead and is sometimes very tricky. An example: Try to establish an external assembly language procedure as a regular class member. That's real fun.

Gunther

[dedndave]

that was the one part i actually understood   :lol:

[Gunther]

Dave,

that was the one part i actually understood   :lol:

that's very interesting. How did you manage the different name mangling and decoration schemes for different compilers? The extern C declaration won't work in that case. Or is it a joke?

Gunther

[dedndave]

i don't use any C compilers (well, not very often)

but, i read about registering assemblies while reading about COM
it didn't seem that bad
haven't really had a need to do it   :P

[Gunther]

Dave,

i don't use any C compilers (well, not very often)

I see it was a joke. rrr314159 did talk about C++. In this case the name mangling for the external assembly language routine is only one big hurdle. In C is that not necessary.

Gunther

[qWord]

But you're right: C++ comes with a lot of overhead

What?

An example: Try to establish an external assembly language procedure as a regular class member. That's real fun.

bad example, because that has nothing to do with the programming language C++.

[Gunther]

Hi qWord,

But you're right: C++ comes with a lot of overhead

What?

Only 2 simple examples:

• If you like it or not: The constructor and the destructor will run in any case. But that's sometimes not necessary (overhead).
• You have to pay a price for your fance overloading features: The complicated name mangling and decoration schemes, which are not standardized and different from compiler to compiler.

bad example, because that has nothing to do with the programming language C++.

It has to do with the language and the name mangling. What helps me a HLL with a bad assembly language interface? Should that be modern design? I think not and we're discussing inside an assembly language board.

By the way qWord, fine to see you again after a break and no offense.

Greatings
Gunther

[qWord]

The constructor and the destructor will run in any case. But that's sometimes not necessary (overhead).

This example is to abstract for me...

You have to pay a price for your fance overloading features: The complicated name mangling and decoration schemes, which are not standardized and different from compiler to compiler.

When programming with c++ you must not mangle names, so no overhead.

What helps me a HLL with a bad assembly language interface?

obviously nothing much 

BTW, I'm curios: why did extern "C" does not work  for your task?

regards

[rrr314159]

@Gunther, sorry I hadn't noticed you were responding to my post. Perhaps I should clarify my opinion.

First, I don't really think C++ has anything to do with the full moon. That's an old joke about mysterious technology that does what you want it to do only sporadically. In the Navy the enlisted men referred to computers (e.g. Combat Control System) as PFM - "Pure Friggin' Magic": same idea. I don't think C++ depends on phases of the moon, but can't be sure, since the latest rev C++11 is tl;dr. For all I know it may mention eyes of newt and cauls of newborns in there somewhere.

Which brings me to my complaint about C++. When I refer to bloat or overhead, I don't mean the build, but the spec. Modern C++ has feature bloat. You'll never win an argument with a C++ maven. You can incur overhead in various ways, but there's always a way to avoid it. In fact, for any problem anyone ever ran into, they added a new feature to get around it. The fix causes new problems, necessitating another feature in the next spec. (I can discuss examples if anyone cares).

It has another problem which I could call "abstraction addiction" - but that's another, more conceptually difficult, story. Briefly, I will say there's only one discipline that really knows how to handle abstraction: mathematics; because that's what math is. Computer languages, and physics, and everybody else, should be very leary of it and stick to their core competency: coding, experimentation, governing, teaching, whatever. But, I digress.

C++ is still, no doubt, the best alternative for some tasks; but that can't last forever. Something like Python will overtake it at the higher level, and (I hope) assembler will render it irrelevant at the lower level. It started out alright; in the late '80's it was good, in fact; but feature bloat (and over-abstraction) is ruining it. BTW this is just my "humble opinion", and as such I don't expect it can really be meaningfully debated. I felt obligated to explain my statements; take it for what it's worth.