Larkin, Power BASIC cannot be THAT good:

C++ is most definitely an OO language. The OO features account for most of the differences between C and C++.

OO is a natural fit for GUI toolkits, although it doesn't have to use C++. Both Xt and GTK are written in C but provide OO interfaces.

program,

Given that you don't use OO and don't appear to even understand it, your opinion of OO doesn't really have a great deal of weight.

Of course, it's *possible* to write any application without using an OO language or even OO concepts. But OO can provide very definite benefits in terms of modularity.

The semiconductor people tend to do the same thing, let multiple users find the same bugs over and over. I know of datasheets that are years old that don't hint about very serious problems.

BEWARE THS3062. It's fatally flawed and the latest datasheet is from

John

snipped-for-privacy@puntnl.niks

related thread,

variables.

hood.

Let me up that a bunch. I look at c++ in retrospect in my programming and i conclude that it is a bunch of syntactic heroin. I messes your head and is hellishly addictive, ands degrades your (and mine) ability to write good SW and particularly to write good OO software.

I will some day.

and dead

is;

then of

for

compile here, needed things...

difference here

other 300 MB free disk space,

Sounds interesting. I will have to try it.

What languages, besides Ada, do have constructs that deal with concurency? And it must be a language construct, not a common implementation construct.

Tim

anyways,,,

(in

for

now that

BASIC.

I think.

networking

to learn

BYTE

BUFFER CONTENTS

BUFFER

I don't have any, just functional code.

Along the way i built a lot of one off screwball test sets that did the job reliably and accurately. Many contained asm code.

I wrote code in a lot of languages that worked and was not ugly, some of it is hitting the 20 useful years mark, no maintenance required.

Currently i review other engineers work and develop specifications and standards in my PPoE.

Erlang is the current poster child. It uses asynchronous message passing, has awesome performance that scales linearly up to at least hundreds of CPUs, and has been used for more than a decade to build time-critical software (like telephone exchanges for example).

There are many functional languages where parallelism doesn't need to be explicit - they are side-effect free so can be automatically parallelised without the programmer even needing to know.

Both Erlang and FP require a shift of focus for the programmer, but that's a Good Thing ;-).

Clifford Heath.

On a sunny day (Fri, 22 May 2009 02:01:01 +0100) it happened Nobody wrote in :

program,

Strange, as I did program in Visual C++, what according to you is 'OO'. There is nothing to understand in ohoh (Dutch word play), it is just a construct by those who do not know how to program, to cover up for their shortcomings. Just like your argument does not have anything other then 'modularity', I mentioned 'modularity' before, and modularity is something one can achieve in a much simpler and clearer way in C. But as C++ programmers so not really know C, they only know the ++ constructs, so they use those, creating bloat and crap code.

You do not have to take my opinion for it, if you trust MIT, this is what they say: (from

In the academic realm of MIT there is a long tradition of criticizing object-oriented programming as a false annunciation. Usually this claim is founded upon the observation that there are no formal innovations in object-oriented programming -- that the paradigm never brought out a technique or characteristic of programming languages not known to academics by another name. Classes and inheritance are syntactic sugar, whereas polymorphism has long been known to Lisp developers as "dispatching on type." Overall, object-oriented programming, generic programming, and whatever else the designers of static programming languages[clarification needed (see discussion)] add to augment the expressivity of these languages have been formally known to programmers of Lisp for many years[citation needed]. What has been wanting in Lisp is efficiency, and the addition of these techniques to static languages[clarification needed (see discussion)] brings their efficiency to the fore.

So, now MIT can be wrong at times, like that wireless power Tesla-re-invention.... But they got rid of that by selling it to Intel.... But they _do_ have some knowledgeable people. Why not listen to that? I mentioned linked lists, and people should know those. Guess what Lisp is based on?

Before any of that OO crap, one should first learn the basics of programming. Then you likely do not want OO. What we need is programming power, to solve problems in the fastest simplest way, not code castles in the sky.

Hey that is a nice one :-)

In the stone age that was true. But on the latest CPUs with sophisticated branch prediction, out of order and speculative execution the time to compute the immediate compare is invisible. This is particularly true in this case where the loop doesn't contain enough other computational work to absorb the memory access time.

The only way to speed it up is to either vectorise it with SIMD SSE instructions or add judicious prefetch cache hints to the loop code. Branch target alignment to 32 bytes might also help.

Most of these tricks have limited utility on the latest quad cores, but they do help on earlier P4 models.

You have shot yourself in the foot with this cheap jibe. It is now very clear for all to see that you do not have the first clue about how things execute on modern Intel CPUs. BASIC hacker mentality.

It is you who needs to ask an expert. In case you feel inclined to "get a clue" the relevant Intel optimisation manuals are at:

The one you want is right at the bottom titled "Intel® 64 and IA-32 Architectures Optimization Reference Manual"

Regards, Martin Brown

hash tables...

Nice in theory, wrong in practise. Try it.

Try it. I went from 0.225 seconds to 0.207 by counting down.

John

On a sunny day (22 May 2009 11:15:19 GMT) it happened Jasen Betts wrote in :

Exactly.

On May 21, 7:38=A0am, snipped-for-privacy@puntnl.niks (Nico Coesel) wrote: ...

You're right! 0x100000 =3D 1048576; 1048576 x 64 =3D 67,108,864. Good catch!

Michael

Wow a free basic... I feel like a kid again. Thanks.

Michael

I like the Asm Out option (-r).

Compiled with the -lang qb option and ran.

C:\\files\\per\\FREEBA~1\\code>test One pass in 0.006 seconds. C:\\files\\per\\FREEBA~1\\code>test One pass in -0.005 seconds.

-0.005 seconds, huh? That made me smile.

assembly output: .Lt_0009: cmp word ptr [ebp-76], -28673 jle .Lt_000C

-28673, huh?

How to force long integers in qb... ah well. Something to do. Thanks.

Michael

Ah that's better... -lang fblite

C:\\files\\per\\FREEBA~1\\code>..\\fbc -lang fblite test.bas

C:\\files\\per\\FREEBA~1\\code>..\\fbc -r -lang fblite test.bas

C:\\files\\per\\FREEBA~1\\code>test Ten passes in 3.178 seconds. C:\\files\\per\\FREEBA~1\\code>test Ten passes in 3.213 seconds. C:\\files\\per\\FREEBA~1\\code>test Ten passes in 3.221 seconds. C:\\files\\per\\FREEBA~1\\code>

Michael

Will have to learn the SIMD instructions. I didn't think I had an assembler that could handle even MMX, but apparently FreeBASIC can...

DIM i AS long i =3D 0 asm mov eax,1 cpuid and edx,8388608 mov cl,23 shr edx,cl mov [i],edx end asm if i =3D 1 then print "You have MMX" else print "No MMX" end if

Thanks,

Michael

cannot program,

You can write C++ code without using any of the OO features, as it's almost a superset of C.

No, you just don't understand it.

Not really. OO provides a different kind of modularity. E.g. it's possible to derive (extend) a class without knowing anything about the data representation.

You're just projecting your own ignorance of OO onto people who do understand it.

say:

Er, that quote wasn't written by "MIT". The author appears to be citing views he doesn't entirely understand, much like you.

If you want to argue the pros and cons of OO with me, you need to do so on the merits; appeals to "authority" will get you nowhere.

Also, I don't give much credence to academics without much real-world experience. While the academic side has its uses, there's a lot that you can only learn by practical experience. In particular, knowing what works when software is developed and maintained over decades by hundreds of different people, most of whom make relatively minor contributions.

I learned Lisp long before any OO languages (my first was Smalltalk), and it is one of the few languages that I use regularly. But even Lisp has CLOS, which suggests that even Lisp programmers have a use for OO.

way,

OO doesn't really help if you're only solving small problems. But it can be extremely useful when you're dealing with code which needs to be readily extensible, or is so large that "global" knowledge isn't feasible, or which naturally fits the OO paradigm (e.g. component-based systems and simulations).

Java has the "synchronized" method qualifier. The language specification also spells out load/store semantics in some detail to ensure consistent semantics for concurrent code.

Concurrency was fundamental to Occam, but that's ancient history.

Quite a few languages include threading in their standard library (and modern languages tend to put as much as possible into their standard library rather than in the language itself).

On a sunny day (Sat, 23 May 2009 09:22:09 +0100) it happened Nobody wrote in :

way,

OK, so to each his own perhaps. 'Language wars', 'editor wars' I have seen it all happening on Usenet. Before we start throwing the pies, maybe we can agree on some statement... like they do after those failed political meetings of our leaders... "That although not a single POV is the same, we have agreed that the weather will likely change frequently and there is still hope for future progress, and a new meeting will be arranged to discuss the issues further." That said, in a final statement, I declare what they call C++ and you refer to that C++ as OO, sucks.

Now, well, OK, now that I started to write anyways... what the big mistake is, is in my view that Strouskop (or whatever his name is), and maybe others too, seem to think 'big problems' are things that need to be solved by 'one big program'. If you think that, and would actually try that, then you get huge sources that need to somehow be compiled together, and the thing becomes more and more difficult, and likely impossible, for mere humans, to maintain.

This is _not_ how 'big problems' are solved.

As I mentioned before, the architect who does not know about stones and concrete, and dreams up a castle. will be in big trouble once building starts.

In reality something of what _could_ be conceived as a big project, as an example I have here: I want to say 'show ARD' (Ard is a German public broadcaster) and then I want that satellite station to appear on my desktop monitor in full screen, de-interlaced. Now in a way that involves: 1) voice recognition, 2) satellite dish positioning,

Also here departs *my* view from what you commonly see in Linux, 'video for Linux' (v4l)..... v4l tries to do all thing by itself, and is therefore always one step behind, as it never supports anything new, as that has not been integrated yet, also an ever changing API, now we are at v4l2, and of course not compatible. I decided to use pipes, and pipe the video stream from one application to the other... A much simpler way, and if you wrote some application, say a filter, or some processing, then you just pipe the stream through it.... So what that boils down to is that you do NOT have one big application, but a whole lot of universally applicable small ones, that are each easy to maintain, and can easily interface with other things in the world, other applications, and hell if you are so inclined you can call these small applications 'objects', buy of course they are not objects, they are different programs, possibly written in different languages, working together to get the job done. In the example I gave you speak into the microphone, that is monitored by 'perlbox voice' (written in you guessed it "perl"), perlbox voice calls the voice recognition suite 'Sphinx2' and the Festival speech synthesiser, both rather large university related projects, Once perlbox recognises the 'show ARD' command, it executes a bash script I wrote called 'show'. The bash script will execute a C program I wrote called 'xdipo' that positions the disk, and then tunes the sat card in the PC to the station ARD (frequency and parameters found in the script), by calling the sat card driver, this driver output the transport stream (.ts that holds all the audio, video, text, etc.. stuff) on /dev/dvb/adapter0/demux0 after tuning it via /dev/dvb/adapter0/frontend0 ... this is then piped to a C program called 'jpinfo' that I wrote that extracts the required streams, that is then piped to the 'xvtx' C program I wrote to display Ceefax (teletext) on screen text if required, that is then piped to xine, a media player written in C++ (I think).... or mplayer (written in C), and those then use the Xwindows system to display it on my screen, and the Alsa sound system to play the sound via the sound card, calling the needed decoders for video and sound. those are written in C and partly asm, and all that runs on top of Linux which is written in C. A million lines of code perhaps (if not more) to 'show ARD'. problems? What problems? Modularity? Right there. Object oriented, not if you use mplayer and not xine... So 'syntactic sugar' is a very polite way to refer to the object oriented paradigm, it comes from wanting to do too much at one time perhaps... maybe, and this is my view, from wanting to do all of the above in one program... Not possible, not in the least because you never have all that knowhow..... Nobody does >?> Nobody ;-)