Dr Brain wrote: |
Java is all about NOT reinventing the wheel, unlike C. |
Dr Brain wrote: |
Java is all about NOT reinventing the wheel, unlike C. |
Dr Brain wrote: |
Java provides a huge library for programmers to use, so they don't rewrite their linked lists classes from scratch (unlike C). |
lp_street_soldier wrote: |
SuSE, I guess you didn't read this -
Beware: argues for fun. Should be considered armed with facts and dangerous. Do not attempt to draw into any sort of debate. |
lp_street_soldier wrote: |
Imagine him at home... O_O |
Code: Show/Hide void insert(iterator _P, size_type _M, const _Ty& _X)
{if (_End - _Last < _M) {size_type _N = size() + (_M < size() ? size() : _M); iterator _S = allocator.allocate(_N, (void *)0); iterator _Q = _Ucopy(_First, _P, _S); _Ufill(_Q, _M, _X); _Ucopy(_P, _Last, _Q + _M); _Destroy(_First, _Last); allocator.deallocate(_First, _End - _First); _End = _S + _N; _Last = _S + size() + _M; _First = _S; } else if (_Last - _P < _M) {_Ucopy(_P, _Last, _P + _M); _Ufill(_Last, _M - (_Last - _P), _X); fill(_P, _Last, _X); _Last += _M; } else if (0 < _M) {_Ucopy(_Last - _M, _Last, _Last); copy_backward(_P, _Last - _M, _Last); fill(_P, _P + _M, _X); _Last += _M; }} |
Code: Show/Hide template <class _AC>
void SVector <_AC>::insert(_AC *here, const _AC &item) { if (end <= next) { _AC *dest; int new_space = count() + 1 + EXTRA; //allocate a new array and copy up to the reserved spot _AC *new_array = operator new(new_space * sizeof(_AC)); dest = copy(new_array, begin, here - begin); //"insert" the item new (dest++) _AC(item); //copy the rest next = copy(dest, here, next - here); //set the pointers begin = new_array; end = begin + new_space; realloc_flag = true; } else { _AC *dest = next++; _AC *source = dest - 1; while (dest > here) { new (dest++) _AC(*source--); source->~_AC(); } new (dest) _AC(item); //dest = here } } |
Cyan~Fire wrote: |
Writing your own classes is always better than using some pseudo-black-box class like STL (or even worse, Java). I call STL pseudo-black-box because Plauger obviously wrote his code to be REALLY confusing.
|
Mine GO BOOM wrote: |
Java does more to prevent everyone from having to remake linked list and such, but its method of doing isn't as good as it should be, and is abstracted too much. Thus, when using Java's build in supports, it doesn't always act how you need it to. |
Dr Brain wrote: |
If you don't understand why Java was made the way it was |
Dr Brain wrote: |
C is a flat head screwdriver. Java is a phillips head screwdriver. |
SuSE wrote: |
Anyways, all you dumbasses get rid of your stupidass signatures please. |
SuSE wrote: |
Anyways, all you dumbasses get rid of your stupidass signatures please. |
SuSE wrote: |
[..]
Anyways, all you dumbasses get rid of your stupidass signatures please. |
Mine GO BOOM wrote: |
Problem fixed. Everyone now has a new ![]() |
Purge+ wrote: |
He thinks they are "stupid" and useless. ![]() |
Dr Brain wrote: |
How is it ignoring it, exactly? The processor's machine code IS Java bytecode. The same Java bytecode that is interpreted by JVMs into native machine code. |
Dr Brain wrote: |
There are very few fully funtional x86 emulators. There are fully operational Java JVMs for almost every platform. |
Mine GO BOOM wrote: |
[..]
Virtual PC and VMWare. Now on the other hand, both Sun's and Microsoft's JVM for Windows, for lack of a better term, suck. |
Dr Brain wrote: |
someone like me, who studies computer architecture, feel free. I could use a good debate. |
Dr Brain wrote: |
Pure-OO encourages better design from the programmers. |
Dr Brain wrote: |
Um, just store the value in a larger storage location. Although, of course, one cannot create arrays that large. |
Br Brain wrote: |
Making a Util class and then calling Util.SwapBytes() isn't hard. And generally, there is a place to put it that makes more sense (such as the calling class). |
Ekted wrote: |
Good programmers make good design. You can make as many bad choices with either style. |
Cyan~Fire wrote: |
And if I want an array of unsigned datatypes? Do I want to use twice the memory just because Java doesn't support it? |
Cyan~Fire wrote: |
Just making a function called SwapBytes() is easier. And yes, I'll admit that most functions fit nicely within a class, but some most definitely do not (like SwapBytes()). Can you please tell me why global functions are bad? |
Cyan~Fire wrote: |
Indeed. Java tries to enforce good design, but as I said somewhere else in another topic, a language/compiler can never properly enforce good design! And anyway, there are always certain things that are actually cleaner (like swapping bytes) in non-OO. |
Cyan~Fire wrote: |
FFS, leave it up to the programmer! I've seen badly designed C/C++ but have actually seen more of badly designed Java. |
Cyan~Fire wrote: |
Another point: Class instantiations in Java are obviously just constant pointers. So why can't I read straight from a file into memory like I could in C/C++. javac could obviously complain if I try to read to much and cause memory corruption, right? |
Dr Brain wrote: |
Don't be silly, of course not. Make an array of signed ints, then convert them when you take them out. |
Dr Brain wrote: |
Two words: Namespaces. C++ namespaces SUCK. Java it seems didn't want to implement a system like this, so the eliminated all globals. |
Dr Brain wrote: |
They also break Java's OO-ness. |
Dr Brain wrote: |
Um, so? Java is meant to be as clean as it possibly can. I think it achives that goal. Interfaces just make sense, for example. |
Dr Brain wrote: |
I take it you haven't looked at much C++ code, then. |
Dr Brain wrote: |
Sandboxing. Reading pointers in from disk allows one to point to OS memory locations and hack around. Java was designed to never allow some of the nastier computer issues. Notice that you've never heard of a virus/worm written in Java? Trojans are possible, but not as applets. |
Cyan~Fire wrote: |
That is, no to Iraq war, yes to helping Tsunami stuff |
Dr Brain wrote: |
Sandboxing. Reading pointers in from disk allows one to point to OS memory locations and hack around. Java was designed to never allow some of the nastier computer issues. Notice that you've never heard of a virus/worm written in Java? Trojans are possible, but not as applets. |
Dr Brain wrote: |
Yes, JVM bugs can allow viruses. Note, however, the the JVMs are not witten in Java. |
Bak wrote: |
I suggest an alternative: the operating system should limit what different processes can do. |
Dr Brain wrote: |
C is written on the idea that speed is the number one need for a program. Twenty years ago, this may have been the case, but certainly, today it is not so. Reliabilty is now the number one need. I'd rather have a program run a little slower and check for errors than have a program run at lightspeed and blow up in my face. |
myke wrote: |
speed matters to me, i'm impatient |