Las 5 Consultas más Populares en Stack Overflow – Mes Agosto 2019

Nube Colectiva

hace 5 años

En esta página:

Llegamos a Fines de Agosto de 2019 y en este mes Stack Overflow esta lleno en general de consultas interesantes, algunas geniales y otras con respuestas obvias, pero dentro de ellas hay 5 consultas que se hicieron más populares durante este periodo, destaca en este top la presencia de Rust el Lenguaje de Programación desarrollado por Mozilla, vamos con este Top.

Igual que en artículos anteriores vamos a Colocar la consulta original y la versión traducida al español, el Link de la consulta, el Lenguaje o tecnología de la consulta, una descripción y una imagen de la consulta.

Puesto N° 5

Consulta Original: How does Rust’s 128-bit integer ‘i128’ work on a 64-bit system ?

Consulta Traducida: ¿ Cómo funciona el entero de 128 bits ‘i128’ de Rust en un sistema de 64 bits ?

Link: Visitar

Lenguaje(s): Rust

El usuario ruohola tiene dudas de como los valores de 128 bits funcionen en un Sistema Operativo de 64 bits, menciona que los valores de 128 bits se denotan con el tipo de datos i128 y u128 para ints (integers) sin signo, por ejemplo:


let a: i128 = 170141183460469231731687303715884105727;

let a: i128 = 170141183460469231731687303715884105727;

El usuario phuclv da un respuesta debajo de su consulta la cual tiene lógica, el menciona que exactamente de la misma manera que los tipos de datos de 64 bits se almacenan en computadoras de 32 bits o los tipos de datos de 32 bits se almacenan en computadoras de 16 bits y así sucesivamente. Asimismo comparte una serie de consultas relacionadas al tema que fueron discutidas en Stack Overflow

Luego el usuario trentcl da una respuesta en un hilo aparte, esta respuesta es muy detallada con conceptos geniales, el menciona que todos los tipos de enteros (integers) en Rust se compilan en LLVM (Low Level Virtual Machine o Máquina Virtual de Nivel Bajo traducidos en Español), la cual permite integers de cualquier valor de bit de 1 a 2 elevado a la 23 – 1 es decir 1 a 2 ^ 23 – 1. Descrito esto pues las instrucciones en LLVM generalmente funcionan en integers de cualquier tamaño.

La respuesta del usuario trentcl es mucho más extensa, si deseas más detalles de esta consulta, Por favor visita el Link de esta consulta.

Puesto N° 4

Consulta Original: What’s a good pattern to calculate a variable only when it is used the first time ? [closed]

Consulta Traducida: ¿ Cuál es un buen patrón para calcular una variable solo cuando se usa la primera vez ? [cerrado]

Link: Visitar

Lenguaje(s): C++

En esta consulta el usuario Kelno tiene dudas con el Lenguaje de Programación C++ al parecer está creando algo entorno a los videojuegos, bien el menciona que su código funciona, el problema que presenta es que en la mayoría de casos no existe ningún gamemasters player es decir su código no encuentra un usuario de tipo player y con el poder de gamemaster al cual se le pueda enviar un mensaje.


void PrintToGameMasters()
{
    std::string message = GetComplicatedDebugMessage(); // This will create a big string with various info
    for (Player* player : GetAllPlayers())
       if (player->IsGameMaster())
           player->SendMessage(message);
}

void PrintToGameMasters()

{

std::string message = GetComplicatedDebugMessage(); // This will create a big string with various info

for (Player* player : GetAllPlayers())

if (player->IsGameMaster())

player->SendMessage(message);

}

Entonces como su código no arroja algún gamemaster al pasar el método GetAllPlayers() el quiere dar una solución haciendo que el usuario pueda enviar un mensaje solo cuando se le de un primer uso a esa variable, el no sabe como hacerlo y pide ayuda.

El usuario Jarod42 da una buena respuesta con el código que da la solución a lo que Kelno pretende hacer


void PrintToGameMasters()
{
    std::optional<std::string> message;

    for (Player* player : GetAllPlayers()) {
       if (player->IsGameMaster()) {
           if (!message) {
              message = GetComplicatedDebugMessage();
           }
           player->SendMessage(*message);
       }
    }
}

void PrintToGameMasters()

{

std::optional<std::string> message;

for (Player* player : GetAllPlayers()) {

if (player->IsGameMaster()) {

if (!message) {

message = GetComplicatedDebugMessage();

}

player->SendMessage(*message);

}

Jarod42 explica que la clase std::string tiene un valor vació, es por eso que su lógica en el código no le devuelve algún usuario de tipo gamemaster, entonces debe usar de manera más general la clase std::optional que maneja cadenas vacías y tipos construibles no predeterminados, si deseas más detalles de esta consulta, Por favor visita el Link de esta consulta.

Puesto N° 3

Consulta Original: Why is there a large performance impact when looping over an array with 240 or more elements ?

Consulta Traducida: ¿ Por qué hay un gran impacto en el rendimiento cuando se recorre una matriz con 240 o más elementos ?

Link: Visitar

Lenguaje(s): Rust

El usuario Guy Korland al ejecutar un bucle de suma sobre una matriz en Rust notó una gran bajón de rendimiento mediante CAPACITY> = 240.CAPACITY= 239 en su código


// Compilado con rustc -C opt-level=3 

use std::time::Instant;

const CAPACITY: usize = 240;
const IN_LOOPS: usize = 500000;

fn main() {
    let mut arr = [0; CAPACITY];
    for i in 0..CAPACITY {
        arr[i] = i;
    }
    let mut sum = 0;
    let now = Instant::now();
    for _ in 0..IN_LOOPS {
        let mut s = 0;
        for i in 0..arr.len() {
            s += arr[i];
        }
        sum += s;
    }
    println!("sum:{} time:{:?}", sum, now.elapsed());
}

// Compilado con rustc -C opt-level=3

use std::time::Instant;

const CAPACITY: usize = 240;

const IN_LOOPS: usize = 500000;

fn main() {

let mut arr = [0; CAPACITY];

for i in 0..CAPACITY {

arr[i] = i;

}

let mut sum = 0;

let now = Instant::now();

for _ in 0..IN_LOOPS {

let mut s = 0;

for i in 0..arr.len() {

s += arr[i];

}

sum += s;

}

println!("sum:{} time:{:?}", sum, now.elapsed());

}

Guy Korland desea optimizar esta compilación para evitar este bajón en cuanto a rendimiento de su código. El usuario Lukas Kalbertodt da una extensa respuesta y menciona el proceso que el motor de compilación LLVM LLVM (Low Level Virtual Machine o Máquina Virtual de Nivel Bajo traducidos en Español) el cual es el motor que usa Rust para compilar su código, pues este pasa por un desenrollamiento de bucle que incrementa la variable del bucle, verifica si el bucle a finalizado y salta al inicio del bucle.

La respuesta de Lukas Kalbertodt es extensa y muy buena y explica porque pasa este bajón de rendimiento y otros detalles, si deseas más detalles de esta consulta, Por favor visita el Link de esta consulta.

Puesto N° 2

Consulta Original: Why does glibc’s strlen need to be so complicated to run quickly ?

Consulta Traducida: ¿ Por qué el strlen de glibc necesita ser tan complicado para correr rápidamente ?

Link: Visitar

Librería(s): Glibc

El usuario Shared esta trabajando tiene una duda sobre Glibc el cual es una librería que da soporte a funciones con el Lenguaje de Programación C en el Sistema Operativo del usuario. Shared explica que estuvo viendo el código de este enlace, el cual le genera dudas sobre si las optimizaciones usadas en el código de dicho enlace son realmente necesarias, asimismo expone y pregunta ¿ Porque algo como el siguiente código no funcionaria igual de bien o mejor ?


unsigned long strlen(char s[]) {
    unsigned long i;
    for (i = 0; s[i] != '\0'; i++)
        continue;
    return i;
}

unsigned long strlen(char s[]) {

unsigned long i;

for (i = 0; s[i] != '\0'; i++)

continue;

return i;

}

Luego de exponer el código anterior realiza la pregunta ¿ No es mejor hacer un código simple el cual haga más fácil la optimización para el compilador?, en fin la duda de el es porque hacer un código tan complejo con strlen que al final la compilación se lleve acabo de manera lenta.

El usuario Antti Haapala da una repuesta extensa y menciona que el código utilizado en ese enlace es utilizado para implementar strlen con algunos trucos y suposiciones de velocidad mu cuestionables :

unsigned long es de 4 u 8 bytes
Los bytes son 8 bits
Se puede lanzar un puntero unsigned long long y no uintptr_t
Se puede alinear el puntero simplemente comprobando que los 2 o 3 bits de orden más bajo son cero
Uno puede romper el alias estricto al direccionar la cadena como unsigned long S
Uno puede leer más allá del final de la matriz sin ningún efecto negativo.

Y hace hincapié que un buen compilador podría reemplazar algún código escrito como


size_t stupid_strlen(const char s[]) {
    size_t i;
    for (i=0; s[i] != '\0'; i++)
        ;
    return i;
}

size_t stupid_strlen(const char s[]) {

size_t i;

for (i=0; s[i] != '\0'; i++)

;

return i;

}

En conclusión menciona que el código, aunque se usa para implementar strlen en una biblioteca estándar de C, es un código incorrecto . Tiene varios aspectos definidos por la implementación e indefinidos y no debe usarse en ningún lugar en lugar del sistema provisto strlen.

El usuario Peter Cordes también da una respuesta muy detallada la cual esta en el puesto 2 de respuestas con más puntos en esta consulta de Stack Overflow, si deseas más detalles de esta consulta, Por favor visita el Link de esta consulta.

Puesto N° 1

Consulta Original: Why is the result of (‘b’+’a’+ + ‘a’ + ‘a’).toLowerCase() ‘banana’ ?

Consulta Traducida: ¿ Por qué el resultado de (‘b’+’a’+ + ‘a’ + ‘a’).toLowerCase() da como resultado ‘banana’ ?

Link: Visitar

Lenguaje(s): Javascript

El usuario Harshvardhan Sharma hace una peculiar pregunta que es cierta, cuando el realizo la siguiente operación:


document.write(('b' + 'a' + + 'a' + 'a').toLowerCase());

banana

document.write(('b' + 'a' + + 'a' + 'a').toLowerCase());

banana

El resultado o la salida es la palabra banana, para cerciorarme yo mismo probé en la consola de Chrome Dev tools y fue tal cual lo menciona el usuario

El usuario SOFe da una respuesta muy simple, pero que responde la duda de Harshvardhan Sharma, menciona que en el calculo que esta reealizado el dato +’a’ Javascript lo toma como NaN (Not a Number) o en español No es un número, esto hace que no se pueda analizar ya que a es una letra y no un número.

Asimismo menciona que si se ejecuta en la consola de Chrome Dev tools arroja NaN (Not a Number) o en español No es un número.


console.log(+'a')

NaN

console.log(+'a')

NaN

También expone en su respuesta otros detalles los cuales puedes ver, visitando el Link de esta consulta.

Bien estas son las mejores consultas que se hicieron en Agosto de 2019, nos vemos a finales del siguiente mes de Septiembre con un nuevo Top de consultas que son tendencia en Stack Overflow.

Notas

La cantidad de Respuestas, Vistas, Votos, etc. de las consultas pueden variar en Stack Overflow en el futuro, hasta la fecha de este artículo son las que presentamos en las imágenes.
Si lees con atención las consultas y las respuestas vas aprender sobre el problema que tenia el usuario que realiza la consulta y puede que sea el problema que estas intentando solucionar, esto es importante para tu aprendizaje.
La idea de este artículo es comentar y exponer los temas que son tendencia en el mes determinado, no intentamos dar una respuesta al problema ya que estos son resueltos por los usuarios de la comunidad Stack Overflow, que son grandes Desarrolladores y con mucha experiencia en el área o Lenguaje de Programación determinado.
Algunos enlaces a otras páginas colocados en este artículo pueden dejar de existir o continuar en el futuro, esto no depende de nosotros si no de los usuarios o empresas que son dueños de los servidores en donde se encuentran alojados estos enlaces, hasta la fecha de este artículo estos enlaces aún están disponibles.

Síguenos en nuestras Redes Sociales para que no te pierdas nuestros próximos contenidos.