f0dder,

it does appear that you are truly ignorant of dialects of basic so I doubt you have much to say of any content there. Private opinions on code design don't means much when a PowerBASIC exe is usually smaller than the language you normaly use and that is with a basic string engine code attached to it.

You can exclude the extra 20k of overhead in VC if you set up a different entry point but then you have nothing like the available power of a PowerBASIC compiler if you do that.

As a language it has too many runs on the board for kiddie level criticism and to boot, it delivers very compact DLLs as well. Perhaps you need to learn a little basic to get the performance that the basic guys are used to having. :tongue:

Regards,

http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-03-25 07:49:22 by hutch--

Private opinions on code design don't means much when a PowerBASIC exe is usually smaller than the language you normaly use and that is with a basic string engine code attached to it.

Private subjective opinion yes, but anybody with half a clue who have skimmed the intel optimization manuals would agree that the generated code sucks. Basic string engine? Yawn. I could code an efficient and string class in C++ that would only take a few kb.


You can exclude the extra 20k of overhead in VC if you set up a different entry point but then you have nothing like the available power of a PowerBASIC compiler if you do that.

And with very little effort I could include the parts of libc I need most without yanking in the rest. Not like I care about 20k of overhead for real-world applications.


As a language it has too many runs on the board for kiddie level criticism and to boot, it delivers very compact DLLs as well. Perhaps you need to learn a little basic to get the performance that the basic guys are used to having. :tongue:

Performance != size. Small size is fine and dandy etc bla bla, too bad the generated code sucks. I have better performance and more control with Microsoft of Intel C++ compilers, so why would I meddle around with a kiddie toy like PowerBasic?
Posted on 2004-03-25 10:37:15 by f0dder
Mmmm,

Sounds like The Crusades would be a better place for this kind of discussion. Though I don't see what PowerBasic or C++ code generation have to do with Win32 Assembly. The question was simple and his choice of language is his own to make.
Posted on 2004-03-25 10:53:28 by donkey
Most languages have their advantages and disadvantages, if you want peak performance, MASM is the toy in 32 bit windows but you must do more work for it.

While a C compiler used to be the standard for high performance programming in all but the most critical cases, with it current dependence on runtime DLLs, bloated output and still suffering from its arbitrary typing, it is a long way off the pace for rapid application development and a long way off the pace in size performance ratio.

Basic is the first language on an IBM PC, (rom basic 1980) and it is still the most written language in the world when accounting for the range of dialects and while there have been some terrible toothless terrors over time, there has also been some very good versions.

Ethan Winers PDQ libraries for QB circa 1990 were excellent and reliably delivered faster and smaller code than the C version 6 that was contemporary.

Since the middle 90s Bob Zale's PowerBASIC has been the performance leader for commercial application development as he is an assembler programmer who writes his compilers in assembler.

What makes me laugh with the criticism is the ignorance to the historical basic standard that has been around as long as IBM PC computers.

Basic by specification provides a dynamic string engine, dynamic array engine, zeros all parameters on the stack at procedure entry and a whole pile of other standardised specifications that identify the language as basic.

PowerBASIC does all of this stuff and still delivers very good performance where it matters with very competitive file sizes that don't start at a minimum of 28k to do a hello world with standard options.

It also has a very good inline assembler that is integrated directly into the language without any

__asm{
; code
}

as it is a lower level language that does not suffer the 1989 ANSI C standard or the later one from 1999.

It is for performance reasons that PowerBASIC has a massive user base of commercial programmers who write commercial application with it on a regular basis.

An opinion from a learner C programmer on the assembler code design of PowerBASIC is about as relevant as an OOP(s) programmer opinion of old style C programming, something that would go down with all the fanfare of a gnat's fart in a crowded room. :tongue:

Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-03-25 17:23:01 by hutch--
PowerBASIC is a low level language? ... I've never heard that before ...
Is there anyone else in the world who agree with you?
I mean who can beleive that PowerBASIC is even a quarter good of C++?

Well, opinions are opinions...

Regards,
Mariano.
Posted on 2004-03-26 01:51:19 by Eternal Idol Birmingham
Idol,

It depends on whether you think size, speed and power matter. PowerBASIC outperforms most languages in terms of final compiled size, the speed of the code is as good as you can write it and it has a development cycle that would make a C compiler wet itself.

It also has a very good inline assembler that is properly integrated into the language, not as a tack on with,


__asm{
; code
}

A C compiler used to be the premium programming tool, now they are off the pace to assembler in code speed and off the pace to basic in development cycles speed.

Great if you write multiplatform code and still very powerful when written correctly but the days of patronising bullshit from out of date C programmers is over as the general support for basic makes it the worlds most written language.

Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-03-26 06:01:31 by hutch--
i dunno i think this is the second thread i am seeing today that has veered off subject and standing on the verge of transforming into a nasty bloat thread
i dunno may be iam way off the mark but off late this board has started becoming a place for wars rather than good info it used to have

any way opinions are opinions are opinions and just that only opinions
Posted on 2004-03-26 06:06:03 by bluffer
Originally posted by hutch--
Great if you write multiplatform code and still very powerful when written correctly but the days of patronising bullshit from out of date C programmers is over as the general support for basic makes it the worlds most written language.


If you think that the popularity of a language means something then ... how much of the REAL, professional applications (the ones that are sold) are written in Basic? And how much in C\C++?

I don't want to argue, I just prefer C++, I think you prefer PowerBasic, it's OK with me.

Regards,
Mariano.
Posted on 2004-03-26 06:15:22 by Eternal Idol Birmingham

with it current dependence on runtime DLLs

No modern C++ compilers have dependencies on runtime DLLs. By default they use runtime *static* libraries, but even that can be turned off.


bloated output

Not really. If you use the runtime, then it's not "bloat". If you don't use the runtime, you turn it off. Then you're down to <1kb "Hello world" MessageBox, as if that mattered. What really matters is the generated code, which is leagues better than PowerBasic. And as for the size... it might be slightly larger, but who cares about a few percent code size increase if it performs better?


still suffering from its arbitrary typing

Heh. The standard today is to have even stronger typing than C++, so sorry. Of course people who don't know what types are all about would prefer "everything is a dword" (assembly) or "everything can be everything else, with implicit and often expensive type conversions" (standard basic). Of course C++ is neither of this.


Basic is the first language on an IBM PC, (rom basic 1980)

And for obvious reasons it's not included in ROM anymore. :rolleyes:


Since the middle 90s Bob Zale's PowerBASIC has been the performance leader for commercial application development

Performance as in fastest applications? One short sentence: "as if".


as he is an assembler programmer who writes his compilers in assembler.

As if that had anything to do with anything. Too bad if bob, an OMFG ASSEMBLY!!! coder, knows less about x86 optimization than microsoft and intel engineers.


Basic by specification provides a dynamic string engine, dynamic array engine, zeros all parameters on the stack at procedure entry and a whole pile of other standardised specifications that identify the language as basic.

Yes yes, and yadda yadda. Cute thing is that nothing stops me from outperforming PB in C++, without "bloated code", because the language itself is powerful and flexible enough to do this. Then again, I can just use the powerful C++ standard library (which has nothing whatsoever to do with the ANSI C library). If I care about the 100k overhead libc++ brings, well, I'll just roll my own.


PowerBASIC does all of this stuff and still delivers very good performance where it matters with very competitive file sizes that don't start at a minimum of 28k to do a hello world with standard options.

Once you actually use features, rather than just do a silly "hello, world" statement, your code size will increase anyway. The size of "hello world" is largely irrelevant, anyway... if you don't use any language features, you might as well refrain from using a language in the first place. But if you insist, with /filealign:512, the default "hello world" console app sizes are 28k for a standard printf C++ app, and 2.5 for WriteFile. Of course this can be decreased even further by section merging. I think llama/cynica_l got it down to ~576 bytes just with compiler and linker switches, without anything fancy.


It also has a very good inline assembler that is integrated directly into the language without any

The powerbasic asm stuff requires every line of asm to be prefixed with '!', doesn't it? Seems a bit smarter to wrap a block with "__asm { ... }" - especially since C is a block structured language. Of course it requires some understanding of the language to realize this. It's silly to say PB has assembly more integrated than most C compilers, anyway.


as it is a lower level language that does not suffer the 1989 ANSI C standard or the later one from 1999.

*giggle*, basic lower level than C? Features of the language itself (declaring variables out of the blue, implicit type conversion, string handling, ...) already makes it (a lot) higher-level than C - it's more like a scripting language than a programming language actually. Additional features of powerbasic (like, integrating sockets in the language) adds it's share of high-levelness too. C - and even C++ - are rather low-level languages, but are flexible enough that they allow very high-level things to be constructed. I don't think neither the basic standard, nor any implementations that I've seen, offer nearly the same level of flexibility (nor performance, for that matter).


An opinion from a learner C programmer on the assembler code design of PowerBASIC is about as relevant as an OOP(s) programmer opinion of old style C programming

You might call me a learner C programmer, and in the context of people like K&R that's true enough. But I think I know C and C++ quite a bit better than you, including the code generation aspects of the microsoft and intel compilers. Ontop of that, I've played around with powerbasic and the generated EXEs, and it's was more of a laugh than anything else.


PowerBASIC outperforms most languages in terms of final compiled size,

EXE size mean nothing compared to code speed, and it's not like MSVC or ICC produces bloated executabels unless you use things like MFC.


the speed of the code is as good as you can write it

You mean you *have* to include inline assembly to get it to perform? That sounds rather like the people who said that "borland pascal performed rather well!", while half of their program was inline or external assembly :grin:

Anyway, who cares. If you want to stay with a kiddie language, do so. If you want to belive it produces better code than most other tools today, be my guest. Everybody else ought to do their own analysis of code speed, and they'd probably come to quite some other conclusions.

I'm outta here, the original question was answered, and I'm too lazy to let hutch make a fool of himself today.
Posted on 2004-03-26 09:12:23 by f0dder
As a matter of interest, I work with someone who uses PB everyday. He's been using it for over 6 years now. About 1 month ago I asked him why he uses it. Actually, he said, when he first started the project, PB's RAD system allowed him to meet his (rather short) deadline. He develops (maintains and enhances) a complete accounting package in PB, connected to an SQL 2000 database. I looked at the IDE for a while and asked why it looked so outdated (on his WinXP laptop), he told me about the various versions of PB, most of which he's bought, used and tested to potentially upgrade his current project. Something to mention, is that when he first upgraded to version 7, it was riddled with bugs, he didn't go into much detail, but he refused to put such large a project (6 years of development) at stake. It's likely that these bugs have been sorted out now by patches and updates, but he has all he needs in his current version. Also, he said, if he could do it again, he would have extended the deadline, and started the development in C (he never learnt C++ so not sure if he would have used that?). To this day, I know he has problems with the buggy PB generated code (perhaps that's just his version?).

http://www.powerbasic.com/support/technote/features.asp

The above link is a keyword comparison of PB7 vs. VB6, QBasic and some others. Interesting to note, the carefully worded "Insert an assembly language statement." next to the ASM keyword. Note "statement", not "statements". PB was never meant to "fully" support assembler, least of all BLOCKS of assember code. As proof of this, PB doesn't support "Call assembler code at a memory address." (next to the CALL ABSOLUTE keyword), this was removed from PB3.5 which supported it, along with QBasic.

Conclusion: My "colleague" wouldn't use PB again (ex C programmer), and I'd say (at least) 6 years is a considerable amount of experience with PB, since he's been programming for over 20 years now.

Toys for boys ;)
Posted on 2004-03-26 12:31:26 by SubEvil
I took f0dder to task for another one of his casual statements that PowerBASIC was a "heap of sh*t" when its clear that f0dder is an illiterate in the area of basic, its history, development speed and internal design.

No-one cares if he never uses basic and does not like it, thats his privilege but noting that Bob Zale is a member of this forum, it is particularly bad manners to slang off another members work on the basic of personal ignorance.

Now I accept that someone of his age does not have the experience with languages developed for more experienced programmers who actually have to deliver reliable working software out the door on a regular basis but its not an excuse for flapping off at the mouth for what he does not understand.

SubEvil,

You are making reference to DOS PowerBASIC which is not even closely related to 32 bit Windows versions. I have used PowerBASIC since version 5 of its 32 bit compilers and it easily handles assembler statements as a natural part of its design.

Vortex,

Among the reason why I support Pelle is his C compiler design has not been compromised with garbage and can still deliver small fast programs. :alright:

Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-03-26 18:20:31 by hutch--
it is particularly bad manners to slang off another members work on the basic of personal ignorance.


You would not tolerate this on your board, would you?
Posted on 2004-03-26 21:16:32 by JimmyClif
SubEvil,

You are making reference to DOS PowerBASIC which is not even closely related to 32 bit Windows versions.

Ahem, I'm afraid you must have misread me, did you read the post properly or go to the link? I referred to PowerBASIC 7, for WINDOWS, the NEWEST version of PowerBASIC (which has less assembler support than previous versions)! I only made a reference to PowerBASIC 3.5 (DOS) that has more assembler support than newer versions (to prove my point). I said, PowerBASIC 3.5 (DOS) supports ...
"Call assembler code at a memory address."
which has been dropped in PowerBASIC 7 (WINDOWS). Have you used PowerBASIC 6 or 7? PowerBASIC 5 is VERY old already! And it's a known fact that, although most versions were buggy, PowerBASIC 7 was very buggy. If you have contact with the developer of this software, please prove or disprove this properly!

PS: Im not trying to "slang" off his work, I'm merely trying to bring fact.

Very fast, very tight code. A feature set unmatched by the others. Create a single EXE, with no run-times nor dependencies.

Point to note here, is that PowerBASIC is only compared to other flavours (check the link) of BASIC (as stated above "unmatched by the others"). Remember, compare apples to apples! Comparing PowerBASIC to "the power and flexibility of C/C++" is an unfair contest (for PowerBASIC ;))
Posted on 2004-03-26 23:37:51 by SubEvil
SubEvil,

I will let you in on a little secret, I worked in the beta team for version 7 for over 18 months until it was released so trust me, I know a LOT about how it works and what capacity it has.

Call assembler code at a memory address.

The direct call you mentioned is standard assembler capacity.

The dialect of assembler in PB is standard Intel traditional notation so YES it can do anything that can be done with assembler instructions. The limitation last I knew was it did not have the latest sse2 instructions available.

I currently use PBWIN70.exe version 7.2 which from memory is current so i am also up to date with the product. This style of folklore means nothing to me when I have worked with the compilers for years.

The DOS version are for legacy code and there is still a market for that type of code with some technical users who use DOS directly for things like process automation and the like. I actually own a copy pof it somewhere but I have never written anything with it as I have not written DOS code for about 7 or 8 years.

Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-03-27 02:29:32 by hutch--
I've dealt enough with basic to know that the language itself is limited, and disallows for quite an amount of things that make other languages more flexible and far more powerful.

I've analysed code generated from PowerBasic v7/win32, as well as various versions of visual C++ (6, net, net2003), borland c++, lcc-win32, ... - so I do have enough background to make comparisons.

PowerBasic might be a cute toy and suit some people well, get the job done and everything - peace be with you. It still generates crap code, though (and yes, that could be stated quite objectively).


Among the reason why I support Pelle is his C compiler design has not been compromised with garbage and can still deliver small fast programs. :alright:

*giggle*. Size doesn't matter compared to speed, and while Pelle is probably a rather decent product for what it is, I have yet to see anyone that comes near the performance of Microsoft or Intel compilers.

And as for size, if it mattered, se attached 1kb exe produced with the latest&greatest vs.net2003. It's standard stuff, once you disable the use of runtime libraries etc. There's a lot more cmdline arguments used that vortex's example, and a lot of them make no difference in this sample - they were taken from a generic batch file though, and can make 'some' difference in larger projects.
Posted on 2004-03-27 02:39:03 by f0dder
The problem with your 1k cutie is that it does not translate to progressive size increase once you have to add any viable code. MASM can maintain the size but its an assembler.

Plug in your MSVCRT DLL and other runtime DLLs, a pile of MFC code along with the default file alignment, add some OOP(S) and you have a bloated pig and that is the difference.

PowerBASIC starts with more overhead than your 1k cutie but it has the technical advantage of being progressive in its size increases, far more so than a VC bloated pig which turns into a balloon very quickly.

I laugh at your assertion that you can produce an equivalent string engine in C++ in a couple of K when you would not even know how to parse the basic code to handle it. Anyone can call the OLE string library but the next step is compiler design which is not in the range of your "couple of k" idea.

There is in fact a way to bloat a PowerBASIC exe up to the size of a VC one, use the #BLOAT metastatement and you can fake the size of a big pig but it really only loads the original exe size.

The idea you have of what constitutes low level code is humerous, in PowerBASIC you can mix assembler line by line with other basic code including high level code and that does make it different to your notion of C being a BLOCK style language.

You may also be aware that the internal optimisation in recent versions of C/C++ behave very badly when mixed with inline assembler. The normal recommendation is to write assembler in seperate modules so that the compiler can do its internal optimisation properly.

The comparitive binary analysis is another point of humour, with someone who simply would not have a clue about how basic internally handles dynamic string and arrays, the opinions are simply nonsense.

Basic in any dialect may not be you cup of tea and that is of course your choice but to slag off someone elses work on the basis of your own ignorance is bad mannered.

The style of code you are asserting as the model is neither the smallest or the fastest, that belongs to assembler, not VC/.net/++ etc ....

Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-03-27 03:34:56 by hutch--
*yawn*


The problem with your 1k cutie is that it does not translate to progressive size increase once you have to add any viable code.

Which is why I argue that "hello world" is a silly way to measure the size of any language. There's a certain size hit from the VC++ runtime libraries, depending on how much you use - start size is ~28kb. You may call this "bloat", but it's not bloat if you actually use the runtimes. If you don't use the RT, you simple don't include it in your exe. The size of the runtime is a one-time hit, and if you don't like it, feel free to write your own. I tend to use the features a language gives me, though.

As for progressive size increase, the quality of the compiler as a whole is more important. VC++ does quite well, and OOP code by itself doesn't bloat up. Use of libc++ and STL does, but that's because of the flexibility and amount of things handled, not the code generator. I've written OOP tools in 4kb, big deal.

As for the whole string thing... you probably can't get a syntax that is fully equivalent to basic, but I can implement dynamically growing strings with pooled allocation, reference counting (if I feel like it), string concatenation (stringout = string1 + string2 + string3 + "hello, world"), trimming, etc yadda yadda in 'a few k' with OOP C++. No big deal when you know your language and tools.

Dynamic arrays are even simpler and smaller, at least as long as you only want to store simple datatypes (ie, everything but an object).

As for inline asm, heh. "__asm mov eax, 2" isn't too different from "!MOV EAX, 2" (or whatever the PB syntax was), apart from the additional typing, is it?

I've seen some of your PB-with-asm stuff, I'm glad that I don't have to resort to inline assembly to get trivial code to perform at decent speed - the compiler does quite well. The use of inline asm isn't really a problem either, the points wrt. the optimizer is mainly restricted to single functions. I tend to do external assembly instead of inline anyway, since when you *need* assembly with VC++, it's more than a few lines to make up for a defunct optimizer.

The cute thing is that C++ allows me much greater power and flexibility than you'll ever have with PB. I'm not stuck with whatever vendors implementation of strings or other dynamic datatypes, the language itself allows me to implement these... and do it as I want. Do I want safe bounds-checking arrays, or max speed? Do I want my strings to be reference-counted and pool-allocated, or would I rather have a small code footprint?
Posted on 2004-03-27 04:08:31 by f0dder

(stringout = string1 + string2 + string3 + "hello, world")

This looks fine until you try and do some serious stuff that is complex in its layout.


' --------------------------------------------------------------
' get parameter byte count, div by 4 and convert back to string
' --------------------------------------------------------------
cnt$ = ltrim$(str$(val(right$(p$,len(p$)-instr(p$,"@")))\4))

proto$ = _
"externdef _imp__"+p$+":PTR "+"pr"+cnt$+chr$(13,10)+_
nm$+" equ <_imp__"+p$+">"+chr$(13,10,13,10)

This is kiddies stuff, I am on my old internet box and I don't have much current code on it.

Where basic truly shines is in its capacity to handle massive complexity at high speed with very little size increase for the effort.

Want to handle string or binary data in a different way ? Basic string does not use a zero terminator to determine its length and it can routinely handle embedded zeros so it is equally as powerful writing binary data as string.

Need even faster string functions ? PowerBASIC assembler is a perfect tool to roll your own if you have a critical application that does something very different to normal string capacity.

Wanna handle zero terminated string data as native code in basic ? Why bother when its already available in the compiler. Wanna start depending on runtime DLLs in basic ? Sure can by writing your own in PowerBASIC and they are just as small and fast as the EXE files, still no bloat.

I will put it to you that you were talking out of your hat on very limited experience of a compiler that you do not even vaguely understand and certainly cannot write optimised code for.

There IS a reason why basic is the most written language in the world, its because a decent implementation can deliver the application development speed along with the application speed and its all up to whoever writes it like normal.

Your problem is you can't deliver much inbetween 1k cuties and enormous bloated pigs and thats because the compiler design does not take into account a world wide demand for application that will run on existing hardware instead of having to buy a later box just to run the code.

Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-03-27 04:28:50 by hutch--

cnt$ = ltrim$(str$(val(right$(p$,len(p$)-instr(p$,"@")))))

proto$ = _
"externdef _imp__"+p$+":PTR "+"pr"+cnt$+chr$(13,10)+_
nm$+" equ <_imp__"+p$+">"+chr$(13,10,13,10)


Hutch,

Are you working on a new version of L2EXTIA? Have you new ideas?
Posted on 2004-03-27 04:48:30 by Vortex
(This code assumes that you already know the proto string follows the funcname@parmbytes naming convention - otherwise some error checking should be employed. For a protoize style tool, this assumption is fair enough.)



cnt = atoi(strrchr(p, '@') + 1) / 4;

proto << "externdef _imp__" << p << ":PTR pr" << cnt << "\13\10" << nm
<< nm$ << " equ <_imp__" << p << ">\13\10\13\10";


proto is a std::ostringstream (or a more compact custom class with same syntax). I would probably have used a sprintf statement, or a custom "mystringstream.format()" method myself, but taste differs.


Want to handle string or binary data in a different way ? Basic string does not use a zero terminator to determine its length and it can routinely handle embedded zeros so it is equally as powerful writing binary data as string.

That's no problem at all when working with your own string datatype. I tend to use an approach with curlen,maxlen,charbuf[32]. Getting the string length becomes a dword lookup, strings less than 32 chars are stored in-place, and otherwise the first DWORD of charbuf is used to store a pointer to a dynamically allocated string. Notice the "maxlen" member, too - this allows me to grow the dynamic string in chunks, rather than every time some char or tiny string is added.

And of course I'm free to add whatever trim, concat, reverse, ... methods I can think of, and implement them with OMFG-SUPER-HIGH-SPEED-ASM if I want to.


I will put it to you that you were talking out of your hat on very limited experience of a compiler that you do not even vaguely understand and certainly cannot write optimised code for.

It seems that PB requires you to write inline assembly to get any decent performance, so I'd say that I can write optimized code for it ;). It was the same with pascal back in the dos days - it was a reasonable language with an okay runtime library, but it was sort of inflexible, and to get good performance you ended up writing a lot of BASM (Borland's name for inline asm).


Your problem is you can't deliver much inbetween 1k cuties and enormous bloated pigs and thats because the compiler design does not take into account a world wide demand for application that will run on existing hardware instead of having to buy a later box just to run the code.

:rolleyes:
I know the language and the cost of various features (classes, virtual methods, templates, ...) and the runtime library. This means I can write tiny silly stuff like the 1kb hello, and that I can write normal stuff with compact size and good performance. I could also spit out examples of very bad programming style that leads to very bad executables, and I could spit out examples of "I don't really care about exe size here because I wanted to get this project done fast". The nice thing is that the language standard + most implementations of C++ allows you the flexibility to do whatever you want.
Posted on 2004-03-27 04:51:07 by f0dder