quote[ A stingray is a controversial[1] electronic surveillance device for remotely capturing data from mobile telephones.[2] It is designed to mimic a cell tower so all the mobile phones in the area communicate with it and provide information, including location data. This can be done even when the phone is not being used to make a call.[2][3] Critics have called the use of the devices by government agencies warrantless cell phone tracking, as they have frequently been used without informing the court system or obtaining a warrant.[1] The Electronic Frontier Foundation has called the devices “an unconstitutional, all-you-can-eat data buffet.”[4] A stingray can be carried by hand or mounted on a vehicle, such as an unmanned aerial vehicle.[3] The devices are also referred to as “cell site simulators” and “IMSI catchers.” ]

from the wiki, first link in the article.

you seem to have missed my point - C is excellent for abstraction if you have taken the time - as i have - to build your own library of such.

these are skilled hands - read the article - the man is a C professional already, looking for alternatives.

what happens if everbody follows your advice?

who will maintain the C code that *inevitably* lies beneath all "higher" level languages?

i realise i'm soapboxing here, but as one on whom the burden of that maintenance has fallen, and surrounded as i am by script kids who take garbage collection for granted, eat memory like it was candy, and stuff buffers as if they were infinite, i am more than a little afraid of what the future will bring.

there is no such thing as a free lunch, and this includes the highler level coding languages - robert a heinlein (not necessarily the heinlein)

sorry, is the air i breathe, forgot the microsofties might not know about it.

agree - sites like this make ikea crap more desireable, not less.

i spent most of my working career in C, and as advised by my early mentors, over the decades, i have build, and have continued to hone my own little collection of useful functions.

i have learned interpreted languages, bash scripts, also postscript and forth along the way, various others...

in the end what remains best is C code, and my own little legacy collection of solutions to the problems i have encountered.

to answer your heads as best as i can:

archaic - C is not - underneath every "other" language you will almost always find C source and a C compiler.

text based - think AJAX if you want instant and easy access to gooey bling stuff. these days almost everything that can do GUI can also do an RPC text based interface of some form or another, and if you don't want the fuss off rolling your own interface, there are plenty of stock C libs out there will do this for you.

not a hotshot - you know C, you are not only hot, you are a rare breed, and an essential part of the future - as i said above, C lies beneath just about everything out there, and large parts of the Original Framework is now inscrutable to the script kids, despite their whole world would collapse, if there were no-one left to maintain it.

update your coding skills - in short please stick with C as much as you can, and think about building bridges - in my opinion your time would be best spent studying the C and text interfaces exported by other languages, and working out for yourself how best to leverage their abilities from within C - as opposed to jumping ships.

help out - get yourself a git account, share your work, if you can.

in all of these except the last i speak from 30 years experience, and in regard to the last - i'm working on it - most of my stuff is still bound in commercial licence, however i continue to hope this will change, eventually, and i continue to prepare for that day.

under a different protocol?

they are a burden on us all, and in my opinion should be lined up against a waill and pissed upon, until cured or dead.

ah no, hmm is a smile, you have me all wrong.

last i heard, freddie thought he was a tricycle..

not odd, therefore - more like one of a kind.

turned out the code i was objecting to works in a thing called a sandbox - so a comparison "statement" is legit in the directly interpreted sense - the ibook just assumes i know what a sandbox is, and does, in order to make sense of it's examples.

your point about obj-c is valid, i think - will stick to providing support at this level, let apple and the swift people build their own bridges, if needed.

odd?
hmm..

most of the best code i've produced has been the stuff i wrote in my head when i could not get near a terminal.

programming in the Visual C IDE was the weirdest of all though, first and only time i tried to write code inside a BUG.

(by god i hate reading documention in iBook form, is the most irritating thing known to man pages)

page 10, line 2 of the sample code - this seems to be a comparison operation with no consumer.

following is my opinion only:

in general the swift documentation is *far* too breathless in it's own praise to be believable, i find.

the hell of it is i now have another language to support in my own "portable" products, and another whole learning curve, sorting out all the personal little differences these precious lisping clowns have implemented, to meet a demand that will certain fizzle in a year or so.

unless swift somehow turns out to be genuinely *better* than existing languages, and therefore a real improvement, apple should be taken out and shot, without trial, for pushing bad drugs, essentially, on an already very unhealthy industry.

so far swift has all the hallmarks of a "vanity" product, and appears entirely constructed of existing concepts, so i do not hold much hope.

i will, unfortunately, be forced to learn this new beast, cover to cover, in my work, and i do promise to correct my impressions, should swift prove me wrong.

is the word you wanted, no?

jokes need to make sense to be funny, i find, but i do realise most others find otherwise.

n/t