| /prebuilts/ndk/8/sources/cxx-stl/gnu-libstdc++/4.4.3/include/tr1_impl/ |
| array | 166 front()
170 front() const
|
| /prebuilts/ndk/8/sources/cxx-stl/gnu-libstdc++/4.6/include/ |
| array | 173 front()
177 front() const
|
| /prebuilts/ndk/8/sources/cxx-stl/gnu-libstdc++/4.7/include/ |
| array | 177 front()
181 front() const
|
| /prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.6/include/ |
| array | 173 front()
177 front() const
|
| /prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.7/include/ |
| array | 177 front()
181 front() const
|
| /prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.8/include/ |
| array | 198 front()
202 front() const
|
| /prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.8/include/debug/ |
| array | 183 front()
190 front() const
|
| /prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.8/include/profile/ |
| array | 156 front()
160 front() const
|
| /prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/include/ |
| array | 202 front() noexcept
206 front() const noexcept
|
| /prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/include/debug/ |
| array | 188 front() noexcept
195 front() const noexcept
|
| /prebuilts/ndk/9/sources/cxx-stl/gnu-libstdc++/4.9/include/profile/ |
| array | 161 front() noexcept
165 front() const noexcept
|
| /bionic/libc/upstream-netbsd/common/lib/libc/stdlib/ |
| random.c | 183 * advances the front and rear pointers 10*rand_deg times, and hence the
222 * fptr and rptr are two pointers into the state info, a front and a rear
246 * the last element to see if the front and rear pointers have wrapped.
458 * into the one at the front pointer. Then both pointers are advanced to
462 * Note: the code takes advantage of the fact that both the front and
464 * pointer if the front one has wrapped.
|
| /external/llvm/include/llvm/IR/ |
| Function.h | 386 const BasicBlock &getEntryBlock() const { return front(); }
387 BasicBlock &getEntryBlock() { return front(); }
408 const BasicBlock &front() const { return BasicBlocks.front(); } function in class:llvm::Function
409 BasicBlock &front() { return BasicBlocks.front(); } function in class:llvm::Function
|
| /external/mesa3d/src/mesa/drivers/dri/swrast/ |
| swrast.c | 27 * The front-buffer is allocated by the loader. The loader provides read/write
28 * callbacks for access to the front-buffer. The driver uses a scratch row for
29 * front-buffer rendering to avoid repeated calls to the loader.
321 GLboolean front)
340 if (front) {
481 /* add front renderbuffer */
|
| /frameworks/base/core/java/android/os/ |
| MessageQueue.java | 629 // Remove all messages at front.
638 // Remove all messages after front.
663 // Remove all messages at front.
672 // Remove all messages after front.
697 // Remove all messages at front.
706 // Remove all messages after front.
|
| /frameworks/base/docs/html/guide/practices/ui_guidelines/ |
| icon_design_launcher_archive.jd | 86 <p>Starting with Android 2.0, launcher icons should be front-facing, instead of
386 <li>The base of a launcher icon can face either the top view or the front
443 definition. A light source is placed slightly to the left in front of the icon,
459 <tr><td><em>3.</em></td><td>Front part:</td><td>Use light gradient from color palette</td></tr>
483 <td class="image-caption-c">Light gradient<br><em>1: </em>r 0 | g 0 | b 0<br><em>2: </em>r 217 | g 217 | b 217<br>Used on the front (lit) part of the icon.</td>
516 source placed slightly to the left in front of the icon.</li>
|
| /frameworks/base/docs/html/training/multiple-apks/ |
| api.jd | 284 sake of example, let?s assume that red requires a front-facing camera. In fact, the entire point of
285 the red APK is to combine the front-facing camera with sweet new functionality that was added in API
286 11. But, it turns out, not all devices that support API 11 even HAVE front-facing cameras! The
290 manifest, see that Red lists the front-facing camera as a requirement, and quietly ignore it, having
293 but also doesn?t care whether or not there?s a front-facing camera! The app can still be downloaded
294 from Google Play by the user, because despite the whole front-camera mishap, there was still an
|
| multiple.jd | 334 let?s assume that Purple requires a front-facing camera. In fact, the entire point of Purple is to
335 use entertaining things with the front-facing camera! But, it turns out, not all API 11+ devices
336 even HAVE front-facing cameras! The horror!</p>
339 manifest, see that Purple lists the front-facing camera as a requirement, and quietly ignore it,
342 there?s a front-facing camera! The app can still be downloaded from Google Play by the user,
343 because despite the whole front-camera mishap, there was still an APK that supported that particular
|
| screensize.jd | 232 red requires a front-facing camera. In fact, the entire point of the red APK is to use the extra
233 available screen space to do entertaining things with that front-facing camera. But, it turns out,
234 not all xlarge devices even HAVE front-facing cameras! The horror!</p>
237 manifest, see that Red lists the front-facing camera as a requirement, and quietly ignore it, having
240 front-facing camera! The app can still be downloaded from Google Play by the user, because
241 despite the whole front-camera mishap, there was still an APK that supported that particular screen
|
| /external/llvm/docs/ |
| ExceptionHandling.rst | 14 front-ends or dealing directly with the information. Further, this document
151 exception. In those circumstances, the LLVM C++ front-end replaces the call with
199 - C++ front-ends use this to implement C++ exception specifications, such as
214 - C++ front-ends use this for calling objects' destructors.
298 having more than one cleanup is pointless). The LLVM C++ front-end can generate
436 Uses of this intrinsic are generated by the C++ front-end.
459 Uses of this intrinsic are generated by the C++ front-end. Many targets will
492 Uses of this intrinsic are generated by the C++ front-end. Many targets will
571 context is saved. The front end places the frame pointer in the first word, and
600 function. The SJLJ front-end code stores this address in the exception handlin
[all...] |
| /external/libcxx/include/ |
| deque | 103 reference front();
104 const_reference front() const;
[all...] |
| /ndk/sources/cxx-stl/llvm-libc++/libcxx/include/ |
| deque | 103 reference front();
104 const_reference front() const;
[all...] |
| /prebuilts/ndk/9/sources/cxx-stl/llvm-libc++/libcxx/include/ |
| deque | 103 reference front();
104 const_reference front() const;
[all...] |
| /external/apache-commons-math/src/main/java/org/apache/commons/math/util/ |
| ResizableDoubleArray.java | 443 * @param i the number of elements to discard from the front of the array
472 * depending on the value of <code>front</code>.
482 * @param i the number of elements to discard from the front/end of the array
483 * @param front true if elements are to be discarded from the front
489 private synchronized void discardExtremeElements(int i,boolean front) {
501 if (front) startIndex += i;
[all...] |
| /frameworks/base/core/java/com/android/internal/util/ |
| StateMachine.java | 104 * a message but places it on the front of the queue rather than the back. The
107 * will be put on the front of the state machine queue with the oldest message
108 * at the front. These will then be processed by the new current state before
859 * any deferred messages moved to the front of the message queue
[all...] |
